LangGraph vs CrewAI vs OpenAI Agents SDK vs Pydantic AI (2026)

Every team building an LLM agent in late 2026 hits the same wall: the demo works, but the framework choice you made in week one is now load-bearing for state management, retries, and cost. Picking wrong means a rewrite six months in. This is a langgraph vs crewai vs openai agents sdk decision guide, and we add Pydantic AI because the four together cover almost every production shape teams actually build: deterministic graphs, role-based crews, handoff-based triage, and type-safe single-agent pipelines. We compare control model, state and memory, streaming, tool and MCP support, structured output, observability, human-in-the-loop, and production maturity — with a decision matrix mapped to real use cases.

What this covers: the control-flow philosophy behind each framework, how state and memory actually work under the hood, streaming and tool/MCP support, a use-case decision matrix, the failure modes teams hit in production, and a straight recommendation by scenario.

Context and Background

Two years ago “agent framework” meant a for-loop around a chat completion with a tools array. By September 2026 the category has split into two philosophies. LangGraph and CrewAI Flows treat an agent system as a program you author explicitly — a graph or a state machine you can read, test, and replay. OpenAI’s Agents SDK and Pydantic AI treat it as a typed function call with delegation attached — closer to how you’d already structure a backend service.

This split matters because it changes what breaks in production. Graph-based systems fail at the seams between nodes — a bad conditional edge, a stale checkpoint. Function-and-handoff systems fail at the boundaries between typed contracts — a schema mismatch, an untyped tool response. Neither failure mode is worse; they require different debugging habits.

We covered the graph-heavy side of this landscape in our agent framework benchmark against LangGraph, OpenAI, and Google ADK, which measured latency and tool-call reliability. This piece is deliberately different: it’s a decision guide, not a benchmark, and it adds CrewAI and Pydantic AI because “which framework” is usually a scoping question before it’s a performance question. For grounding on the frameworks’ own release cadence, LangChain’s engineering changelog and Pydantic’s AI changelog are the two most current external references as of this writing.

The forcing function pushing teams to decide now, rather than keep prototyping, is that all four frameworks shipped major stability milestones within months of each other in 2026 — LangGraph’s 1.0 line, CrewAI’s Flow-first production guidance, OpenAI’s sandboxing and harness update to the Agents SDK, and Pydantic AI’s v2.0 consolidation. A choice that was reasonably deferrable in 2025, when every option still felt experimental, now has real switching costs attached: checkpoints, traces, and tool schemas that don’t port cleanly across frameworks once a system is live. Vendor incentives also diverge in ways worth naming plainly — OpenAI’s SDK is optimized to keep you inside OpenAI’s own model and Responses API surface, while LangGraph, CrewAI, and Pydantic AI are model-agnostic by design and treat provider choice as a configuration detail rather than an architectural commitment.

Choosing a Control Model: Graphs, Crews, Handoffs, and Typed Functions

Direct answer: LangGraph gives you an explicit, inspectable state graph where you author every node and edge; CrewAI gives you role-based agent teams (Crews) plus a separate deterministic orchestration layer (Flows); OpenAI’s Agents SDK gives you a small set of primitives — Agents, Handoffs, Guardrails — built around delegation; Pydantic AI gives you a type-safe function-call model with dependency injection instead of a runtime graph at all.

Figure 1: A LangGraph agent loop — the agent node reasons, a conditional router decides between calling a tool, escalating to a human via interrupt(), or finishing, while a checkpointer persists state after every step.

The diagram above is not simplified for effect — this is close to the median LangGraph agent shipped today. Every arrow is code you write and can unit-test independently. That is the entire pitch: nothing happens that isn’t represented as a node or an edge, and the graph compiles into an object you can visualize, version, and replay from any checkpoint. LangGraph reached a 1.0 milestone in 2026 after roughly a year of production hardening at companies LangChain has cited as reference users, and by mid-2026 had added a new channel type specifically to cut checkpoint overhead on long-running threads — the mechanism we detailed in our piece on the DeltaChannel long-running agent pattern.

LangGraph: the graph is the source of truth

In LangGraph you define a StateGraph, add nodes (each a function that reads and returns partial state), and wire conditional edges that inspect state to decide the next node. Nothing is implicit. If an agent needs to loop — call a tool, re-reason, call another tool — that loop is a real edge back to the same node, not a hidden retry inside a black-box “agent executor.” The trade-off is upfront authoring cost: you’re writing an explicit state machine even for a simple single-tool agent, which is overkill for the 20% of use cases that are genuinely just “call a model, call a tool, return.”

A 2026 update pushed this control further down into individual nodes: finer-grained execution controls now let a node specify its own timeout, its own error-recovery behavior, and a graceful-shutdown path independent of the rest of the graph. That matters operationally — a single flaky tool call no longer has to take the whole run down, and a node can retry with backoff or fail closed without the author hand-rolling a try/except wrapper around every call. Middleware hooks added around the same time let teams attach cross-cutting behavior (PII redaction, rate limiting, logging) once, at the graph level, rather than duplicating it inside every node function.

CrewAI: role-based crews for open-ended work, Flows for the parts that must be deterministic

CrewAI’s original and still-dominant abstraction is the Crew: a set of agents, each with a role, goal, and backstory, collaborating on delegated tasks through a process (sequential or hierarchical, with a manager agent). This is genuinely well-suited to open-ended work — content pipelines, research synthesis, anything where you want agents to negotiate sub-tasks rather than follow a fixed path. The catch, and it’s a real one, is that a pure Crew’s execution path is only as predictable as the manager agent’s delegation decisions, which makes audit trails harder to reason about ahead of time.

CrewAI’s answer to that is Flows — an event-driven orchestration layer with @start and @listen decorators, explicit state, branching, and routing, sitting above one or more Crews. A Flow is CrewAI’s admission that production systems need a deterministic skeleton; a Crew is where you still want agents reasoning autonomously. In practice, teams that outgrow a bare Crew end up writing a Flow that looks a lot like a simplified LangGraph graph — the two frameworks are converging on the same conclusion (deterministic control plane, autonomous execution inside it) from opposite starting points.

The process mode you pick inside a Crew changes the delegation mechanism itself. Sequential process runs tasks in a fixed order with each agent’s output feeding the next — the closest CrewAI gets to LangGraph-style predictability without a Flow. Hierarchical process introduces a manager agent that dynamically decides which specialist handles which sub-task, which is more adaptive but means the delegation path is itself an LLM decision, not a rule. CrewAI’s task-level guardrails — validation checks a task’s output must pass before the crew moves on — and its agent-training feature, which lets you capture human feedback on past runs to steer future ones, are both aimed at making the hierarchical mode’s unpredictability more tractable over time rather than eliminating it.

Handoffs and typed functions: OpenAI Agents SDK and Pydantic AI

The OpenAI Agents SDK deliberately ships a small primitive set: an Agent is an LLM with instructions and tools; a Handoff is one agent delegating to a specialist, implemented under the hood as a transfer_to_X tool call, so it shows up in the trace like any other tool invocation and is selected by the model using the same name/description matching as a real tool; a Guardrail is an input or output check that runs alongside the agent and can trip a tripwire to halt the run before a bad response reaches the user or a bad input reaches a paid tool call. There is no graph object and no explicit state machine — control flow emerges from which agent currently holds the conversation and which handoffs it’s allowed to take. OpenAI’s April 2026 update added native sandboxing (agents can execute code inside a controlled environment rather than shelling out unsafely) and a more capable model harness aimed at document- and file-heavy agentic work, both shipped first in Python with TypeScript following.

Pydantic AI goes further in the “no graph” direction: an agent is close to a typed function. You define an output_type (a Pydantic BaseModel) that the framework validates the model’s response against, self-repairing via ModelRetry if the first attempt doesn’t parse; you define a deps_type dataclass injected into every tool call through RunContext, giving you the same dependency-injection pattern you’d use in FastAPI, including swapping in mocked dependencies for tests. Its June 2026 v2.0 release consolidated this further around a single “capability” primitive — one composable unit bundling an agent’s tools, hooks, instructions, and model settings — which the Pydantic team frames explicitly as a bet on a small, stable core rather than an expanding primitive surface.

Both frameworks’ guardrail concepts are worth distinguishing from each other because they operate at different layers. The Agents SDK’s guardrail is a runtime check tied to a specific agent’s input or output, evaluated on every call, that can halt execution via a tripwire — it’s a safety mechanism. Pydantic AI’s output_validator and ModelRetry are a correctness mechanism: they don’t stop a run so much as give the model a second attempt with feedback about what was wrong the first time, which is a meaningfully different failure-recovery story and one reason the two frameworks are easier to compose than they might first appear — a Pydantic AI agent’s typed output can be exactly what an Agents SDK guardrail checks before allowing a handoff to proceed.

State, Memory, Streaming, and Tool/MCP Support

Control model determines how an agent decides what to do next; this section covers what happens between those decisions — where state lives, what a client sees mid-run, and how each framework reaches external tools.

Figure 2: A CrewAI Flow triggers a Crew of three role-based agents whose tasks converge on a manager agent, which the Flow’s deterministic state machine then routes onward — Flows own the control plane, Crews own the reasoning.

LangGraph’s state model is the most mechanically explicit of the four: every node reads and writes a shared, typed state object, and a checkpointer persists that state after each super-step to a backing store (in-memory for development, Postgres or a managed service for production). This is what makes interrupt()-based human-in-the-loop possible — the graph can pause indefinitely, mid-run, and resume from exact saved state days later, because the state was never implicit in a Python stack frame. Streaming in LangGraph’s current major version exposes a content-block-centric API with typed, per-channel projections, meaning a client can subscribe to just the token stream, just the tool-call events, or both, rather than parsing a single undifferentiated event firehose.

CrewAI’s memory system is layered by design: short-term memory scoped to the current task, long-term memory persisted across runs, and entity memory that tracks specific people, tools, and concepts an agent has encountered — closer to how a human assistant would build context over a working relationship than to a raw vector-store dump. Streaming and step-level tracing are exposed through CrewAI’s execution layer, and tool access leans on a large first-party integration catalog (Gmail, Slack, Salesforce, HubSpot, and 100-plus others as of 2026) rather than requiring every integration to be hand-rolled or reached exclusively through MCP.

The OpenAI Agents SDK leans on Sessions for state: a session gives an agent automatic conversation history so you’re not hand-threading a message list between turns, but it’s conversational memory, not an arbitrary typed state object the way LangGraph’s is — if your workflow needs structured intermediate state beyond “the conversation so far,” you’re building that yourself alongside the SDK. Tracing is on by default and captures generations, tool calls, handoffs, and guardrail evaluations in one timeline, which is genuinely useful for debugging a multi-agent handoff chain after the fact. MCP support lets any MCP server’s tools plug in as agent tools without custom adapter code.

Pydantic AI’s state story is the simplest of the four because it mostly declines to have one: state lives in your deps object and whatever you choose to persist yourself, and the framework’s own opinion stops at making that object type-checked. Streaming works through run_stream, and structured-output streaming — validating partial JSON as it arrives rather than only at the end — is one of the more distinctive capabilities here, useful when a UI wants to render a structured object incrementally. As of the v2.0 line, Pydantic AI’s default OpenTelemetry instrumentation moved to a newer semantic-conventions version, reporting token usage under a gen_ai.aggregated_usage.* namespace, which matters if you’re already piping traces into an existing observability stack and don’t want a schema break.

Multi-agent orchestration across process or organizational boundaries is where MCP and the emerging Agent2Agent (A2A) protocol both apply pressure on all four frameworks simultaneously, a topic we go deeper on in our piece on MCP, A2A, and LangGraph for multi-agent orchestration. The short version: LangGraph and the Agents SDK both ship first-party MCP client support; CrewAI reaches MCP servers as one tool source among its broader integration catalog; Pydantic AI treats an MCP server as just another typed tool provider, consistent with its minimal-primitives philosophy.

Figure 3: A triage agent evaluates an incoming request past an input guardrail, hands off to a specialist agent, and both pass through an output guardrail before a response — every step recorded in one trace.

Decision matrix by use case

Use case	Best fit	Why	Runner-up
Single-agent tool use (support bot, single API)	OpenAI Agents SDK	Minimal primitives, built-in tracing, fastest to a working agent	Pydantic AI
Multi-agent orchestration, open-ended	CrewAI (Crews)	Role/goal/backstory model fits negotiated sub-tasks well	LangGraph
Deterministic, auditable workflows	LangGraph	Explicit graph compiles to an inspectable, replayable object	CrewAI (Flows)
Typed-output pipelines feeding downstream systems	Pydantic AI	output_type validation plus dependency injection, minimal ceremony	OpenAI Agents SDK
Long-running, pausable, human-in-the-loop workflows	LangGraph	Checkpointer + interrupt() persist state indefinitely	CrewAI (Flows)
Rapid prototyping with many pre-built integrations	CrewAI	100+ built-in tool connectors reduce custom glue code	OpenAI Agents SDK

Treat this as a starting point, not a verdict — plenty of production systems combine two of these (a Pydantic AI agent as one node inside a LangGraph graph is a genuinely common pattern by late 2026, since nothing here is mutually exclusive at the code level).

Trade-offs, Gotchas, and What Goes Wrong

LangGraph’s explicitness is also its cost center: teams new to the framework routinely over-model simple agents as five-node graphs when a single function call would do, then wonder why iteration feels slow. The checkpointer, if left on a default in-memory backend, silently loses state on process restart — a production outage waiting to happen for anyone who assumed “checkpointing” meant durability without configuring a real backing store.

CrewAI’s role-based Crew mode can produce delegation loops that are hard to predict before you’ve run them, because the manager agent’s routing decision is itself a model call, not a rule. Teams that skip Flows entirely and ship a bare Crew to production are the ones most likely to hit an audit request they can’t answer cleanly — “why did agent B get involved here?” is a question a Flow’s explicit state machine answers and a raw Crew often can’t.

The OpenAI Agents SDK’s minimalism means anything beyond its three core primitives — durable long-running state, complex branching logic that isn’t a simple handoff — is code you write yourself, and that custom code doesn’t get the SDK’s free tracing integration unless you explicitly instrument it. Its April 2026 sandboxing and harness upgrades landed in Python first, so teams standardized on the TypeScript SDK were, as of that release, waiting on parity.

Pydantic AI’s biggest gotcha is the mirror image of the Agents SDK’s: because it intentionally has no orchestration layer, teams sometimes reach for it on multi-agent problems it wasn’t built to solve, then bolt on ad hoc coordination code that a graph-based framework would have given them for free. Its v2.0 “capability” consolidation is also young enough (mid-2026) that some third-party integration guides in circulation still reference the pre-v2 API surface — check the version pin before copying a tutorial.

Figure 4: Start from what the system needs most — typed output, deterministic control, or open-ended multi-agent collaboration — and the decision collapses to one or two frameworks quickly.

Practical Recommendations

Start from the failure mode you can least afford, not the feature list. If an ungoverned agent decision could mean a compliance problem or an unrecoverable action, default to LangGraph or a CrewAI Flow — you want the explicit graph or state machine, not an emergent handoff chain, however elegant the emergent version looks in a demo. If your system is fundamentally “validate this LLM output against a schema and hand it to another service,” Pydantic AI’s output_type plus dependency injection will get you there with the least code and the fewest moving parts to operate.

If the team is small and the workflow is genuinely open-ended — research, drafting, multi-perspective analysis — CrewAI’s Crew abstraction will get a working multi-agent system running faster than hand-rolling handoffs, and you can graduate specific paths into a Flow once you know which ones need to be deterministic. If you’re building a single customer-facing agent with a handful of specialist escalation paths, the OpenAI Agents SDK’s handoff model maps almost directly onto that shape with the least abstraction overhead of any option here.

Checklist before you commit:
– Can you name the specific failure mode (bad routing, lost state, invalid output) you’re most exposed to, and does the framework address it natively?
– Do you need to pause a run for days and resume from exact state? Only LangGraph’s checkpointing does this cleanly today.
– Do you need type-checked output your downstream service can trust without a validation layer of its own? Pydantic AI removes the most code here.
– Will you need MCP tool access, and does the framework’s MCP client cover your server’s transport?
– What’s your team’s tolerance for authoring an explicit graph versus trusting emergent delegation? Be honest — this is a team-fit question, not just a technical one.

Frequently Asked Questions

Is LangGraph better than CrewAI for multi-agent systems?

Neither is categorically better — they optimize for different things. LangGraph gives you an explicit graph where every transition is code you wrote, which favors auditability and deterministic replay. CrewAI’s Crew model favors natural role-based delegation for open-ended work, with Flows added on top when you need CrewAI’s own deterministic control layer. Choose LangGraph when auditability matters most; choose CrewAI when speed of building an open-ended multi-agent workflow matters most.

Can I use Pydantic AI and LangGraph together?

Yes, and it’s a common late-2026 pattern. Teams use Pydantic AI to define a single, type-safe agent — with validated output_type and injected deps — and then embed that agent as one node inside a larger LangGraph state graph. This gets you Pydantic AI’s output guarantees at the node level and LangGraph’s checkpointing and explicit control flow at the system level, without picking one framework for the entire stack.

Does the OpenAI Agents SDK support open-source or non-OpenAI models?

The Agents SDK was built by OpenAI and is most tightly integrated with OpenAI’s own models and the Responses API, but its model interface is written to be swappable, and community and third-party adapters exist for other providers. If model portability across vendors is a hard requirement, LangGraph’s init_chat_model and Pydantic AI’s multi-provider model classes have broader out-of-the-box provider support as of September 2026.

Which framework has the best observability out of the box?

The OpenAI Agents SDK ships tracing on by default, capturing generations, tool calls, handoffs, and guardrail checks in a single timeline with no extra setup. Pydantic AI’s OpenTelemetry instrumentation (now on a newer semantic-conventions version) integrates cleanly if you already run an OTel-based stack. LangGraph’s graph structure makes state itself inspectable at any checkpoint, which is a different but equally valuable kind of observability. CrewAI provides step-level execution tracing within its own dashboard tooling.

Is CrewAI production-ready in 2026?

Yes, with the caveat that “production-ready” depends on which half of CrewAI you use. Flows, the deterministic event-driven layer, are specifically built for the auditability production deployments need. A bare Crew without a Flow wrapping it is better suited to internal or lower-stakes workflows where occasional unpredictable delegation is an acceptable trade for faster iteration.

What is the simplest framework for a single-agent tool-calling bot?

For a single agent calling a handful of tools with no multi-agent delegation, the OpenAI Agents SDK and Pydantic AI both beat LangGraph and CrewAI on setup overhead — neither requires you to author a graph or a role/crew structure for a linear workflow. Pick the Agents SDK if you’re already on the OpenAI stack and want free tracing; pick Pydantic AI if strict output typing and provider portability matter more than built-in tracing.

Further Reading

• AI Agent Frameworks Benchmark: LangGraph, OpenAI Agents SDK, and Google ADK (2026) — latency and tool-reliability benchmark data for three of the four frameworks covered here.
• Multi-Agent Orchestration with MCP, A2A, and LangGraph (2026) — a deeper look at cross-agent protocols referenced in the state/tooling section above.
• LangGraph DeltaChannel: The Long-Running Agent Pattern (2026) — the checkpoint-overhead mechanism underlying LangGraph’s state model.
• LangChain/LangGraph engineering changelog — official release notes.
• Pydantic AI changelog — official release notes, including the v2.0 harness-first redesign.

By Riju — about