Four multi-agent frameworks, four incompatible answers to the same question: when one agent hands work to another, what happens to the context? The choice determines what breaks in production.
Every multi-agent framework has to answer one unglamorous question: when Agent A finishes its part and Agent B needs to pick up, what does B actually see? Does it get A's full transcript, a summary, a clean slate, or a shared mutable state object it can read and write? That single design decision — more than any feature list — determines what a framework is good at and where it quietly falls apart once you're past the demo.
Four frameworks currently dominate this conversation, and each made a different bet:
| LangGraph | CrewAI | OpenAI Agents SDK | Claude Agent SDK | |
|---|---|---|---|---|
| Core abstraction | Explicit state graph (nodes + edges) | Role-based crew (agents + tasks) | Handoffs between peer agents | Subagents with isolated context |
| Context passed on handoff | Whatever the graph state schema defines | Task inputs/outputs, configurable memory | Full conversation history by default | Nothing — subagent starts fresh, returns a summary |
| State model | Persistent, checkpointed, inspectable | Crew-level shared memory | Session object, thread-scoped | No shared state; parent orchestrates via tool calls |
| Human-in-the-loop | First-class interrupt() primitive | Manual, via callbacks | Manual, via guardrails/tool gating | Manual, via hooks (e.g. SubagentStop) |
| Time-travel / replay debugging | Yes, built on checkpointing | No | No | No (transcript inspection only) |
| Best fit | Long-running, stateful, must-survive-a-restart workflows | Role-mapped workflows (researcher/writer/reviewer) prototyped fast | Thin, GPT-native handoff chains | Context-hungry tasks that need to stay out of the main thread |
| Where it breaks | Boilerplate scales with graph complexity | Control flow ceiling — can't cleanly express branching/rollback | Token cost grows with handoff chain length | Subagent sprawl — cost and memory multiply per agent |
The table is a reasonable starting point for picking a framework. It is a bad guide to what actually goes wrong once the workflow leaves the demo notebook — that requires looking at what each of these abstractions does to context over time.
LangGraph treats an agent system as a state machine. You define nodes (units of work, often an LLM call or a tool call) and edges (the conditions under which control moves from one node to another), and the framework persists the graph's state at every step. This is the same mental model as a workflow engine like Temporal, applied to LLM calls — which is exactly the point. If a node fails, or the process restarts, or a human needs to approve a step before it continues, the graph's checkpointed state means execution can resume from exactly where it left off. LangGraph's interrupt() primitive pauses a run mid-graph, waits for external input, and resumes — genuinely hard to build correctly from scratch, and the reason regulated or long-running workflows (approval chains, multi-day agentic pipelines) tend to land here.
The cost is that you're writing a state machine. Every new capability means touching the graph schema, adding nodes, and reasoning about which edges are now reachable. Simple workflows carry disproportionate boilerplate.
CrewAI goes the other direction: describe your problem as a team. You define agents with roles ("senior researcher", "technical writer", "fact-checker"), give each a goal and backstory that steers its system prompt, and assign tasks with expected outputs. The framework figures out sequencing and manages a crew-level memory that agents can read from. This maps naturally onto how people already describe workflows to each other — "have someone research it, someone write it up, someone check it" — which is why CrewAI is consistently the fastest framework to get a working multi-agent prototype out of.
The ceiling shows up when the workflow needs real conditional logic: "if the fact-checker rejects the draft twice, escalate to a human instead of retrying a third time" is awkward to express in role-and-task terms because the paradigm doesn't have a native concept of branching or state rollback. CrewAI added Flows — a more explicit, code-first control layer — specifically to paper over this gap, which is itself evidence of where the pure role-based model runs out of road.
OpenAI Agents SDK takes the opposite bet from LangGraph: minimal ceremony. An agent is instructions, a model, a tool list, and a list of other agents it's allowed to hand off to. A handoff transfers control explicitly and — critically — carries the full conversation history to the next agent. There's no separate state object to design; the conversation is the state. This is why you can write a working two-agent handoff system in under twenty lines: there's almost nothing to configure.
The tradeoff is baked into that same design choice. Because each handoff passes the entire accumulated transcript forward, a chain of five or six handoffs means the sixth agent is reasoning over the full history of everything the first five did — including irrelevant back-and-forth, failed tool calls, and context nobody downstream actually needs. Short chains are cheap and fast. Long chains get expensive and, worse, start degrading quality as irrelevant context crowds out what the current agent actually needs to focus on.
Claude Agent SDK — the same agent loop that powers Claude Code, exposed for building custom applications — takes a stance that's almost the inverse of the OpenAI SDK's: a subagent gets none of the parent's context by default. It sees a task description, a tool list, and whatever it reads during its own execution. It does not see the parent's conversation history, the parent's other tool calls, or any sibling subagent's work. When it finishes, only its final, structured summary returns to the parent — not its intermediate reasoning, not its tool call log.
The bet here is that isolation beats sharing for agentic quality: a subagent digging through fifty files for a code review does that digging in a context window that isn't polluted by the parent's unrelated work, and the parent's context stays small because it only ever sees clean summaries, not raw transcripts. This is the direct opposite failure mode from the OpenAI SDK's handoff chains — instead of context bloat, the risk is subagent sprawl: every additional subagent type is its own context window, its own token budget, and its own cost line, and teams that spin up a dozen loosely-scoped subagents for every task see that multiply into real memory and cost pressure. The SDK also lets you pin a cheaper model (e.g. Haiku-class) to narrow triage subagents and reserve a larger model for the ones doing real synthesis — a lever that's easy to ignore and expensive to ignore for long.
The comparison table above tells you the primitives. It doesn't tell you what happens to a 40-turn conversation once it's been through three of these systems.
In a LangGraph run, context lives in the state object you designed, so it's exactly as large as your schema makes it — this is a strength for control and a liability if you didn't design the schema carefully, because unused fields still get checkpointed and replayed on every resume.
In a CrewAI crew, context flows through task inputs and outputs plus whatever's written to shared memory — bounded by design, but that also means information an agent didn't explicitly write to memory is invisible to the next agent, a common source of "why didn't it use the thing we found three steps ago" bugs.
In the OpenAI Agents SDK, context is the conversation, full stop — nothing is lost, but nothing is pruned either, so cost and latency degrade monotonically with chain length unless you're actively trimming.
In the Claude Agent SDK, context is deliberately thrown away between subagent boundaries — nothing carries over except what the subagent chooses to report, which is efficient but means a subagent literally cannot use information it wasn't told, even if a sibling subagent discovered it thirty seconds earlier.
None of these is strictly better. They're four different answers to a tradeoff that has no framework-agnostic solution: more shared context makes an agent smarter about the whole task and more expensive per call; less shared context makes each call cheap and focused but risks agents working with an incomplete picture.
Pick based on what your workflow actually needs to survive, not on which framework has the most GitHub activity this quarter:
interrupt() support are purpose-built for this and hard to replicate elsewhere.All four are also converging on the same interoperability layer: MCP (Model Context Protocol) support is now table stakes across LangGraph, CrewAI, and the Claude Agent SDK, which means the tools an agent calls increasingly don't care which orchestration framework is driving it. A well-designed MCP server — Utilix exposes one over its API, for instance — is callable identically whether the caller is a LangGraph node, a CrewAI agent, or a Claude subagent, which is a reasonable argument for pushing tool logic into MCP servers rather than framework-specific tool definitions in the first place.
Don't ask "which framework is best" — ask "what does this workflow need to survive: a crash, a long handoff chain, an unpredictable branch, or a context-hungry subtask?" The answer to that question, not a feature checklist, is what actually predicts which of these four bets pays off for your system.
Sources: Comparative framework descriptions and design-philosophy framing draw on public documentation and analysis from sources including morphllm.com and codebridge.tech, cross-checked against each project's own documentation for architectural claims.