OpenAI Agents SDK vs CrewAI (2026): Head-to-Head Comparison + Cost Analysis

OpenAI Agents SDK vs CrewAI in 2026: The 30-Second Verdict

In short

OpenAI Agents SDK wins when the workload is committed to GPT-5 / GPT-5.5 / o-series models, native tracing matters, and the April 2026 sandbox is on the requirements list. CrewAI wins when multi-model routing is a first-class requirement, role-playing collaboration between specialists beats deterministic handoffs, and pluggable memory / RAG / knowledge backends are on the buying sheet. Alice Labs ships production agents on both — the choice starts with model commitment.

The OpenAI Agents SDK was open-sourced in March 2025 as the production successor to the experimental Swarm framework and evolved on 16 April 2026 with a model-native harness, configurable memory, and sandbox-aware orchestration across seven infrastructure providers. Under 100 lines of code buys you a handoff-based multi-agent system with first-party tracing already wired in.

CrewAI 1.15.10, released on 31 July 2026, is the multi-agent framework of record for multi-model deployments. 56.5k GitHub stars, MIT-licensed, and — since 1.14.7 (11 June 2026) — pluggable default backends for memory, knowledge, RAG, and flow, with LanceDB as the default vector store. The CrewAI team reports 450M monthly workflow executions across enterprise deployments, with DocuSign, PwC, IBM, and Piracanjuba on the public reference list.

Alice Labs has shipped both across 100+ production implementations. The rule of thumb we use in scoping calls: OpenAI Agents SDK when the workload is OpenAI-committed and observability matters more than model portability. CrewAI when we need Claude or open-weights models alongside GPT, or when role-based collaboration between specialists (analyst plus writer plus reviewer) matters more than deterministic handoffs.

Both frameworks slot inside the broader landscape we cover in our best AI agent frameworks 2026 guide. This article is the head-to-head that guides the two-name shortlist teams arrive at when their choice is OpenAI-vs-multi-vendor rather than any-versus-all.

What Is the OpenAI Agents SDK in 2026?

In short

The OpenAI Agents SDK is a Python-first (TypeScript in flight) framework with five primitives — Agent, Handoff, Guardrails, Sessions, Tracing — and a native harness that gained sandbox execution and configurable memory on 16 April 2026. It supports 100+ non-OpenAI LLMs via a Chat Completions API adapter, but the observability, hosted tools, and sandbox integrations are optimised for the OpenAI stack.

The OpenAI Agents SDK is OpenAI's open-source agent library, first released in March 2025 as the production successor to the experimental Swarm framework and repositioned on 16 April 2026 with what OpenAI called "the next evolution" of the harness. Five primitives sit at the core: Agent (an LLM configured with instructions and tools), Handoff (delegated transfer between agents), Guardrails (input and output validation), Sessions (persistent conversation state), and Tracing (first-party observability).

The April 2026 update added three things production teams had been asking for since the 2025 open-source drop:

• Native harness — model-native orchestration that reduces glue code for long-running tasks
• Configurable memory — SQLAlchemy, SQLite, Redis, MongoDB, and encrypted variants ship out of the box
• Sandbox execution — portable Manifest abstraction with providers Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel

Tracing is the differentiator most teams underestimate. Every step, tool call, handoff, and guardrail check surfaces in the OpenAI dashboard with zero configuration — the same data plane OpenAI uses to debug its own hosted agents. There is nothing else you have to wire up for OpenAI-model workloads.

"OpenAI-only" is a design bias, not a hard lock. The SDK ships a LitellmModel adapter that exposes 100+ providers — Anthropic, AWS Bedrock, Azure, Vertex — through a Chat Completions API extension. The trade-off is that native features (dashboard tracing, hosted tools, sandbox harness) degrade when you swap in a non-OpenAI backend.

Roadmap items OpenAI has publicly named for the next milestones: subagents and Python or TypeScript "code mode" — the same pattern that gave Claude Code the majority of its expressive power.

What Is CrewAI in 2026?

In short

CrewAI is an open-source (MIT) multi-agent framework at v1.15.10, released 31 July 2026, with 56.5k GitHub stars and 100,000+ certified developers. The two-layer model splits Crews (autonomous role-playing agent teams) from Flows (event-driven, state-aware orchestration). Version 1.14.7 (11 June 2026) introduced pluggable default backends for memory, knowledge, RAG, and flow with LanceDB as the default vector store, plus a native Snowflake Cortex provider.

CrewAI is a Python multi-agent framework built around the premise that specialist agents collaborating in defined roles produce better outcomes than a single generalist agent calling tools in a loop. The latest stable is v1.15.10 (31 July 2026); the release cluster that anchored the platform in 2026 was 1.14.x, particularly 1.14.7 on 11 June 2026.

The mental model has two layers:

• Crews — teams of role-playing autonomous agents. Each Agent has a role, goal, backstory, and tools; a Process (sequential or hierarchical) governs how Tasks flow between them.
• Flows — event-driven, state-aware orchestration around one or more Crews. Flows are the outer application-level layer; Crews are the collaborative problem-solving units inside them.

The 1.14.7 release moved CrewAI from "framework with opinions" to "framework with pluggable defaults":

• Pluggable memory, knowledge, RAG, and flow backends via a StorageBackend protocol
• LLM-scored recall combining semantic similarity, recency, and importance in a single unified Memory class (short-term, long-term, entity, external)
• Native Snowflake Cortex LLM provider alongside existing OpenAI, Anthropic, Groq, Ollama, AWS Bedrock, Azure, and Vertex support
• Conversational Flow chat APIs, which closed a gap OpenAI held via the Responses API

Enterprise footprint you can point a CFO at: DocuSign, PwC (reporting 7x code-generation accuracy), IBM, and Piracanjuba (reporting 95% accuracy replacing RPA). The CrewAI team reports 450M monthly workflow executions across its user base — no equivalent published figure exists for the OpenAI Agents SDK.

Architecture Philosophy: Handoffs vs Role-Playing Crews

In short

OpenAI Agents SDK treats agents as lightweight orchestration primitives wired together via handoffs surfaced to the model as tools — the runner switches control on the tool call. CrewAI models teams: each Agent has a role, goal, backstory, and tools, and a Process (sequential or hierarchical) governs how Tasks flow between them. Handoffs give you deterministic transfer; CrewAI's role-playing gives you emergent collaboration but wider variance.

These are two different mental models developers actually program against, and the choice colours every design decision downstream.

OpenAI Agents SDK: Handoffs as Tools

In the OpenAI Agents SDK, agents are lightweight objects wired together via handoffs. The handoff is surfaced to the model as a tool the agent can call — when it does, the Runner transfers control to the target agent, which inherits the conversation history. This is deterministic: you know at design time which agents can hand off to which.

CrewAI: Role-Playing Collaboration

In CrewAI, each Agent is defined by role, goal, and backstory. A Crew groups agents around Tasks, and a Process (sequential or hierarchical) governs how Tasks flow between them. The behaviour is emergent — the analyst agent drafts, the writer agent expands, the reviewer agent critiques — and the pattern rewards teams that treat prompt design as the core engineering discipline.

Minimal OpenAI Agents SDK Handoff

# Python 3.10+
from agents import Agent, Runner, handoff

billing = Agent(
    name="Billing",
    instructions="You handle refunds and invoices.",
)

triage = Agent(
    name="Triage",
    instructions="You route customer questions to specialists.",
    handoffs=[billing],
)

result = Runner.run_sync(triage, "I was charged twice for order #1298.")
print(result.final_output)

Minimal CrewAI Crew

# Python 3.10+
from crewai import Agent, Task, Crew, Process

researcher = Agent(
    role="Senior Research Analyst",
    goal="Surface Q3 churn drivers with citations.",
    backstory="You have 10 years in B2B SaaS analytics.",
)

writer = Agent(
    role="Executive Editor",
    goal="Turn research into a one-page memo for the CFO.",
    backstory="You write for time-poor leadership.",
)

research_task = Task(
    description="Find the top 3 Q3 churn drivers.",
    agent=researcher,
    expected_output="A bullet list with source URLs.",
)

write_task = Task(
    description="Turn findings into a CFO-ready memo.",
    agent=writer,
    context=[research_task],
    expected_output="A 300-word memo.",
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process=Process.sequential,
)

result = crew.kickoff()

Alice Labs pattern: use OpenAI handoffs when the workflow decomposition is known at design time — triage into specialist into resolution. Reach for CrewAI Crews when specialists must negotiate outcomes and the collaboration itself is the value (research plus drafting plus critique).

Multi-Model Support: OpenAI-Native vs Provider-Agnostic

In short

OpenAI Agents SDK is optimised for the Responses API and OpenAI routing; the LitellmModel adapter exposes 100+ providers but inherits LiteLLM's operational surface, and OpenAI-native features degrade when you swap in a non-OpenAI backend. CrewAI is provider-agnostic from day one — 1.14.7 added a native Snowflake Cortex LLM provider on top of existing OpenAI, Anthropic, Groq, Ollama, Bedrock, Azure, and Vertex support.

This is the single most consequential architectural decision on the shortlist, and it deserves an honest framing.

OpenAI Agents SDK: Optimised for OpenAI, Portable Under LiteLLM

The SDK is designed around the Responses API and OpenAI's model catalogue — hosted tools, prompt-cache placement, and the tracing pipeline all assume you are running OpenAI models. The LitellmModel adapter opens the door to Anthropic, AWS Bedrock, Azure OpenAI, Vertex AI, and open-source models via LiteLLM, but you inherit LiteLLM's operational surface (its own proxy, its own retry semantics) and lose the OpenAI-dashboard tracing granularity for those calls.

CrewAI: Provider-Agnostic From Day One

CrewAI treats OpenAI as one provider among many. The LLM class accepts OpenAI, Anthropic, Google Vertex AI, Groq, Ollama, AWS Bedrock, Azure, and the natively integrated Snowflake Cortex added in 1.14.7. You set the LLM per Agent, so a single crew can mix GPT-5.5 for reasoning, Claude Sonnet 4.5 for writing, and GPT-5-mini for classification without a parallel code path.

# CrewAI — three models in one crew
from crewai import Agent, LLM

planner = Agent(
    role="Planner",
    goal="Break the task into steps.",
    llm=LLM(model="gpt-5.5"),
)

writer = Agent(
    role="Writer",
    goal="Draft the deliverable.",
    llm=LLM(model="anthropic/claude-sonnet-4-5"),
)

classifier = Agent(
    role="Classifier",
    goal="Tag output for downstream routing.",
    llm=LLM(model="gpt-5-mini"),
)

Alice Labs rule: if the roadmap includes Claude Sonnet 4.5 for reasoning and GPT-5-mini for cheap classification in the same crew, start on CrewAI, not the OpenAI SDK. If the workload is committed to OpenAI models for the next 12 months, the OpenAI SDK's native features carry their weight.

Cost Analysis: Token Economics for OpenAI Agents SDK vs CrewAI

In short

Same OpenAI list prices apply to both frameworks — GPT-5 at $1.25 / $10.00 per million tokens, GPT-5-mini at $0.25 / $2.00, GPT-5.5 at $5.00 / $30.00, o3 at $2.00 / $8.00 (August 2026). Both are open source with no per-token markup. CrewAI's cost advantage is model arbitrage: routing narrow steps to Claude Haiku 4 or Groq Llama 3.3 70B typically cuts per-workflow cost 40-70% vs an all-GPT-5 pipeline. Batch and Flex processing on OpenAI cut rates 50% and work with the SDK.

Both frameworks are free and open source; the meter runs on tokens. There is no per-token markup on either side.

OpenAI Token Pricing (August 2026)

• GPT-5: $1.25 per million input tokens, $10.00 per million output tokens
• GPT-5-mini: $0.25 per million input tokens, $2.00 per million output tokens
• GPT-5.5: $5.00 per million input tokens, $30.00 per million output tokens
• o3: $2.00 per million input tokens, $8.00 per million output tokens
• Batch / Flex processing: 50% off list, works transparently with the SDK

Where the Cost Delta Lives

Because both frameworks pass through the same OpenAI prices, an OpenAI-only pipeline costs the same on either. The delta shows up when CrewAI routes narrow steps to a different provider:

• Cheap classification and tagging on GPT-5-mini or a Groq-hosted Llama 3.3 70B
• Bulk read-only extraction on Claude Haiku 4
• Reasoning-heavy steps only on GPT-5.5 or Claude Opus 4.8

Table 1: Framework and Platform Cost Comparison (August 2026)

Alice Labs modeling: a mid-volume production workflow (roughly 100k-500k runs / month) runs $180-$720 / month on an all-GPT-5 pipeline on either framework. Routing the cheap 60% of steps to GPT-5-mini or Haiku 4 in a CrewAI crew typically pulls that to $75-$300 / month — a 40-70% saving that compounds monthly.

The framework is almost never the cost driver. Token discipline is — and CrewAI makes token discipline structurally easier when the workload can tolerate mixed providers.

Observability, Tracing, and Debugging

In short

OpenAI Agents SDK ships first-party tracing to the OpenAI dashboard capturing every step, tool call, handoff, and guardrail — zero-config for OpenAI models. CrewAI relies on third-party observability (Langfuse, AgentOps, Arize, Langsmith) and its own AMP dashboard, and 1.14.7 exposed native finish_reason, sampling params, and response.id on LLM events. For non-OpenAI models routed through LitellmModel, the OpenAI trace loses provider-side token accounting.

Observability is where the frameworks diverge most sharply for OpenAI-committed teams.

OpenAI Agents SDK: Zero-Config First-Party Tracing

Every step, tool call, handoff, and guardrail check surfaces in the OpenAI dashboard automatically. Zero configuration. This is the same observability surface OpenAI uses for its own hosted agents, and for OpenAI-only workloads it is genuinely the best free tracing available in 2026.

CrewAI: BYO Backend, Multiple Choices

CrewAI does not ship first-party tracing. Instead, it integrates with Langfuse, AgentOps, Arize, Langsmith, and its own AMP dashboard (part of CrewAI Enterprise). The 1.14.7 release exposed native finish_reason, sampling params, and response.id on LLM events — enough to build the trace you want but not enough to skip the observability wiring entirely.

Alice Labs default: OpenAI Agents SDK plus native tracing for anything user-facing on OpenAI models; CrewAI plus Langfuse for multi-model batch pipelines where a unified provider-agnostic view matters more than the OpenAI-dashboard integration.

Sandboxing and Safe Code Execution

In short

OpenAI Agents SDK now includes native sandbox execution with providers Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel and a portable Manifest abstraction. Sandboxes support S3, GCS, Azure Blob, and Cloudflare R2 mounts plus parallel execution across multiple sandboxes. CrewAI has no first-party sandbox — teams typically add E2B or Modal manually, or use CrewAI Enterprise's containerised execution.

The April 2026 harness update turned sandboxing from a "roll your own" concern into a first-class configuration option on the OpenAI Agents SDK. This matters more than most comparisons acknowledge.

OpenAI Agents SDK: Native Sandbox, Portable Manifest

The SDK's April 2026 update shipped native sandbox execution across seven infrastructure providers — Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel. A portable Manifest abstraction keeps workspaces reproducible across providers. Sandboxes mount local files or connect to S3, Google Cloud Storage, Azure Blob, and Cloudflare R2, and the SDK supports parallel execution across multiple sandboxes for fan-out workloads.

CrewAI: No First-Party Sandbox, Enterprise Containers

CrewAI does not ship a first-party sandbox. Teams that need code execution typically add E2B or Modal manually, or upgrade to CrewAI Enterprise where AMP Suite provides containerised execution. Both approaches work in production, but neither is as configuration-light as the OpenAI SDK's Manifest.

Practical implication: for any workflow where the agent writes and runs code — data cleaning, research automation, code-modification agents — the OpenAI Agents SDK is the safer default in 2026. For workflows where tools are HTTP-only and the agent never needs to execute untrusted code, the sandbox delta is neutral.

Memory and State Management

In short

OpenAI Agents SDK Sessions provides persistent memory with SQLAlchemy, SQLite, Redis, MongoDB, and encrypted variants out of the box. CrewAI 1.14.7 unified short-term, long-term, entity, and external memory into a single Memory class with LLM-scored recall (semantic + recency + importance) and pluggable StorageBackend protocol. CrewAI's default is LanceDB under ./.crewai/memory; OpenAI SDK ships no vector store.

Both frameworks solve memory in 2026, but with different assumptions about what memory is for.

OpenAI Agents SDK: Sessions Over Structured Stores

OpenAI Agents SDK Sessions provides persistent conversation memory with SQLAlchemy, SQLite, Redis, MongoDB, and encrypted variants out of the box. It is optimised for "keep the conversation across turns" rather than "recall the right past fact." No vector store ships in the box; if you need semantic recall, you bring your own.

CrewAI: Unified Memory With LLM-Scored Recall

CrewAI 1.14.7 collapsed short-term, long-term, entity, and external memory into a single Memory class with LLM-scored recall — semantic similarity, recency, and importance combined at query time. The default vector store is LanceDB under ./.crewai/memory, and a StorageBackend protocol lets you swap in Postgres, Qdrant, Pinecone, or a hosted alternative without touching the memory API.

Verdict: CrewAI's memory is more feature-rich out of the box. OpenAI SDK's is simpler and easier to reason about for stateless-per-turn agents where "recall the last few turns" is all you need. For a deeper treatment of the memory system design space, our AI agent memory systems guide covers session, episodic, and semantic memory across the framework landscape.

Learning Curve and Time-to-First-Agent

In short

OpenAI Agents SDK reaches productive use in 2-3 days for teams already fluent in the OpenAI API — a working handoff-based multi-agent system fits in under 100 lines of code. CrewAI takes 3-5 days because there are more concepts (Crew, Flow, Task, Process, Agent), but declarative YAML and Python templates speed up subsequent reuse. Teams coming from LangChain typically feel at home in CrewAI first; teams with OpenAI API fluency reach a first useful agent faster on the SDK.

Onboarding friction is the single most predictable delta between these two frameworks, and it flips depending on where the team comes from.

OpenAI Agents SDK: Fastest for OpenAI-Native Teams

Independent benchmarking in mid-2026 reports 2-3 days to productive use on the OpenAI Agents SDK. A working handoff-based multi-agent system fits in under 100 lines of code. Teams already comfortable with the Chat Completions and Responses APIs slot in without new mental models — Agent is just a configured LLM plus tools plus handoffs.

CrewAI: 3-5 Days, Rewards Template Reuse

Reported 3-5 days to productive on CrewAI. There are simply more concepts — Crew, Flow, Task, Process, Agent — but the declarative YAML and Python patterns speed up template reuse. Once you have one Crew working, subsequent Crews reuse most of the scaffolding.

The volume signal: CrewAI reports 450M+ monthly workflow executions across its user base, versus no equivalent published figure for the OpenAI Agents SDK. Both are widely deployed; only CrewAI has published the number.

Alice Labs observation across 100+ implementations: teams already fluent in the OpenAI API reach "first useful agent" fastest on the Agents SDK; teams coming from LangChain feel at home in CrewAI faster. Team origin is a better predictor than framework merit for time-to-first-agent.

When OpenAI Agents SDK Wins

In short

OpenAI Agents SDK wins when the workload is committed to GPT-5 / GPT-5.5 / o-series with no near-term plan to swap; when you need native tracing, guardrails, and sandbox execution without stitching third-party tools; when handoff-style deterministic orchestration matches the workflow; and when you want the shortest supported path to the Responses API, hosted MCP tools, and OpenAI's hosted evaluators.

The OpenAI Agents SDK is the right default when four things are true:

• OpenAI commitment. The workload runs on GPT-5, GPT-5.5, or o-series models with no near-term plan to swap. Procurement, existing contracts, or model-fit have already settled the question.
• Native tracing matters. You want observability of every step, tool call, handoff, and guardrail check without setting up Langfuse, AgentOps, or Arize. The OpenAI dashboard is the observability surface.
• Deterministic orchestration fits. The workflow decomposes cleanly into triage-into-specialist-into-resolution. Handoffs are the right primitive; you do not need role-playing collaboration between peers.
• Sandbox execution is on the requirements list. The agent writes and runs code, and the April 2026 harness (Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel) removes the "roll your own sandbox" work.

The additional pull factors: hosted MCP tools land here first, hosted evaluators sit adjacent, and the roadmap includes subagents and code mode as next milestones. For a deeper look at how these primitives compose across frameworks, see our guide on AI agent tool-use patterns.

When CrewAI Wins

In short

CrewAI wins when multi-model routing is a first-class requirement (Anthropic + OpenAI + open source in the same crew); when role-playing collaboration between specialists matters more than deterministic handoffs; when you need built-in RAG, knowledge, and memory backends without wiring your own vector store; and when enterprise governance features (AMP Suite, Agent Control Plane, Crew Control Plane) are on the buying list.

CrewAI is the right default when any of four things are true:

• Multi-model routing is a core requirement. Claude Sonnet 4.5 for reasoning, GPT-5-mini for classification, Groq Llama for cheap fan-out — inside the same crew, without a parallel code path.
• Role-playing collaboration is the value. Analyst plus writer plus reviewer, negotiating an outcome through Sequential or Hierarchical Process. The emergent behaviour is the point, not a bug.
• Memory, knowledge, and RAG must be built in. Pluggable backends, LLM-scored recall, LanceDB by default — no vector-store wiring on day one.
• Enterprise governance features are on the buying sheet. AMP Suite, Agent Control Plane, and Crew Control Plane are CrewAI's differentiators for regulated buyers who need SSO, RBAC, and audit hooks out of the box.

The additional pull factor: production references — DocuSign, PwC, IBM, Piracanjuba — plus the reported 450M monthly workflow executions across the user base. For deeper architectural context on multi-agent coordination beyond CrewAI itself, our multi-agent systems explained guide covers supervisor, hierarchical, and peer-to-peer patterns.

Migration and Interop

In short

MCP (Model Context Protocol) support in both frameworks means tool implementations are portable across the two with wrapper adapters. Handoff logic in OpenAI Agents SDK maps roughly to CrewAI hierarchical Process delegation; state migration requires manual replay of Session or Memory records. CrewAI's chat API for conversational flows (1.14.7) closes a gap OpenAI SDK held via the Responses API. Alice Labs approach: prototype in whichever framework the team knows, then port hot paths only when cost or latency justify it.

Framework lock-in is manageable if you migrate incrementally and use the shared surfaces as your escape hatch.

MCP Is the Shared Tool Surface

Both frameworks support MCP (Model Context Protocol) in 2026. Tool implementations written as MCP servers run under both with thin wrappers — the same server that exposes GitHub actions to an OpenAI Agents SDK agent also exposes them to a CrewAI Crew. This is the single most portable investment you can make in your agent stack.

OpenAI SDK to CrewAI

Handoff logic maps roughly to CrewAI hierarchical Process delegation. Each specialist agent in the SDK becomes a CrewAI Agent with a matching role and goal; the manager LLM in the hierarchical Process replaces the SDK's Runner. State migration is manual — you replay Session records into CrewAI Memory. Expect one to two weeks per workflow.

CrewAI to OpenAI SDK

Rarer but doable when the workload consolidates to OpenAI models and native tracing becomes a hard requirement. Collapse each Crew to an Agent-plus-handoff graph, migrate Memory to Sessions, and rewrite Tasks as Agent instructions. The 1.14.7 chat API for conversational Flows makes the shape less foreign in either direction.

Alice Labs approach: prototype in whichever framework the team knows, ship the first useful production version quickly, and port hot paths only when cost or latency justify it. Most projects never migrate — the switching cost only pays back for hot paths at meaningful scale.

Production Checklist: Alice Labs' 8-Point Framework Selection

In short

Model commitment: single vendor points to OpenAI SDK; multi-vendor points to CrewAI. Observability: OpenAI-native tracing needed points to OpenAI SDK; open-source stack preferred points to CrewAI plus Langfuse. Sandbox: code execution required points to OpenAI SDK (April 2026 harness). Memory depth: pluggable backends and LLM-scored recall points to CrewAI; simple session state points to OpenAI SDK. Team fluency, governance layer, MCP tool ecosystem, and EU AI Act audit surface should all appear on the scoring sheet before you commit.

The eight-point scorer we walk buyers through in scoping calls. Score each dimension 0-2 (0 = OpenAI SDK, 1 = neutral, 2 = CrewAI). Higher total points to CrewAI; lower to OpenAI SDK. Anything within two points of neutral means either framework will ship — go with team fluency.

1. Model commitment. Single vendor for 12+ months → OpenAI SDK (0). Multi-vendor already in the roadmap → CrewAI (2).
2. Observability posture. OpenAI dashboard is the observability surface → OpenAI SDK (0). Langfuse / AgentOps / Arize already the standard → CrewAI (2).
3. Sandbox needs. Agent writes and runs code → OpenAI SDK (0). Tools are HTTP-only, no code execution → CrewAI (1-2).
4. Memory depth. Session state is enough → OpenAI SDK (0). LLM-scored recall over long horizons → CrewAI (2).
5. Team fluency. OpenAI API-native team → OpenAI SDK (0). LangChain-native team → CrewAI (2).
6. Governance layer. No SSO / RBAC / audit-hook requirement out of the box → either (1). Requirement is hard → CrewAI Enterprise (2).
7. MCP tool ecosystem. Both support MCP — neutral (1). Slight edge to OpenAI SDK if hosted MCP tools are your standard.
8. EU AI Act audit surface. Handoff-level trace granularity from the OpenAI dashboard is often sufficient (1). Deeper audit needs point to CrewAI + Langfuse for provider-agnostic evidence (2).

Alice Labs finding across 100+ implementations: the top three drivers in real projects are model commitment (question 1), team fluency (question 5), and sandbox needs (question 3). The rest usually confirm rather than overturn the direction those three point to.

For a broader treatment of build-vs-buy economics on production AI agents — including when hiring a partner beats hiring for a framework — see our build vs buy AI guide.