LangGraph vs CrewAI vs OpenAI Agents SDK vs Google ADK: Pick the State Model

At a glance

Four frameworks that dominate production agent work in 2026, sorted by the thing that actually differs.

Why the state model is the load-bearing choice

Agents are not requests. A meaningful agent run is minutes to hours, calls tools with side effects, and will be interrupted — by a crash, a deploy, a rate limit, a human who wants to look at it before it sends the email. Every one of those events asks the same question: what is the durable representation of this run, and can the framework rebuild the loop from it?

That question is answered differently by each of these four, and the answer propagates upward through everything you write. If the framework externalises state, then resume, fork, replay and human approval are properties you inherit. If it keeps state in the process, they are yours to build, and building them means introducing a persistence boundary the control flow above was not written to cross. That is why the migration hurts: not because the prompts are hard to port, but because "where do we pick up from" has no answer in the code you already have.

This is also why the frameworks look more similar than they are on a tutorial. Every one of them will build you a tool-calling loop with a few agents in an afternoon. The divergence appears the first time something needs to survive the afternoon.

LangGraph — durability as the primitive

What it actually does

LangGraph models the agent as a directed graph: nodes are steps, edges are explicit transitions, and conditional edges encode where control goes when a step produces one outcome rather than another. State is a typed object threaded through the graph, and a checkpointer writes it to an external store at every superstep, organised by thread. Durability is configurable — persist synchronously before each step, asynchronously alongside the next one, or only on exit — which is a real trade of write amplification against how much you are willing to lose in a crash.

What that buys you

Three things that are otherwise projects. Resume: a run picks up from its last checkpoint rather than restarting. Time travel: invoke the graph with a specific checkpoint ID to replay from a prior state or fork an alternate branch, which is as useful for debugging as it is for product features. And interrupt(), a durable pause that stops mid-graph, waits for a human decision, and continues — the primitive that makes approval flows a few lines instead of a queue, a webhook and a state machine.

The cost

You write the graph. Explicit edges mean explicit thinking about failure paths and control flow, which is precisely what you want in production and precisely what makes the first week slower than a framework where you describe roles and let the model route. If your agent genuinely is a short conversation with three tools, that structure is overhead you are paying for nothing.

Google ADK — the workflow agents are the point

What it actually does

ADK's fundamental unit is an agent, and its distinctive move is that some agents are not model-driven at all. SequentialAgent runs its children in a fixed order, ParallelAgent runs them concurrently, and LoopAgent repeats until a stopping condition or a maximum iteration count. These compose into a hierarchical tree, and the whole tree shares one session state — including a temp: namespace scoped to a single turn — carried by a session service whose storage backend you choose.

What that buys you

Determinism where you want it and model judgement where you need it, in the same tree, without writing an orchestrator. A pipeline of "fetch, then analyse three ways in parallel, then synthesise, then loop until the critic is satisfied" is four built-in constructs, and the parts that must happen in order actually happen in order rather than being requested politely in a prompt. Java support alongside Python is unusual in this space and matters more than it sounds if your platform team is a JVM shop.

The cost

Shared session state across a ParallelAgent is exactly the concurrency hazard it looks like — sub-agents run in separate threads over one state object, so each has to write to a distinct key or they clobber each other. That is a documented, avoidable footgun, and it is a footgun. The gravity toward Gemini and Vertex is real: everything works better inside Google Cloud, which is a feature if you are there and a tax if you are not.

CrewAI — role modelling, with the real engine one layer down

What it actually does

A Crew is a set of role-defined agents collaborating on a shared goal — the abstraction that made CrewAI popular, because "researcher, writer, editor" is a description a product manager can write. What the popularity obscures is that Crews deliberately do not give you sequential control, and the answer to that is Flows: a Python class wrapping crews and direct LLM calls in an event-driven engine, with methods decorated @start, @listen and @router. State is a dict or, better, a Pydantic model, and @persist() saves it so a run can resume.

What that buys you

The fastest path from "here is our process, described as people" to something running. For workflows that genuinely are a team of specialists producing a document, the metaphor is not a toy — it maps, and the code reads like the process. Flows then give you back the determinism the crew metaphor gave away, which is why the honest recommendation is Flows-with-Crews-inside rather than Crews alone.

The cost

Persistence is opt-in and placement-sensitive; the community guidance is to persist at a terminal step rather than decorating the whole class, which tells you this is a layer you are managing rather than a runtime guarantee you inherit. There is no equivalent of a durable interrupt, so human-in-the-loop is something you construct. And the role metaphor invites more agents than a task needs — a crew of five where a graph would have had two nodes is a cost paid every run, in tokens and in the failure modes that multi-agent systems catalogue.

OpenAI Agents SDK — the thinnest thing that works

What it actually does

Four primitives and almost no ceremony: agents with instructions and tools, handoffs that transfer control between agents, guardrails that check inputs and outputs, and a runner that drives the tool loop, switches agents on a handoff, and stops when the run finishes or pauses for approval. Sessions carry conversation history; tracing is built in and collects LLM generations, tool calls, handoffs and guardrail events, uploaded to the OpenAI platform by default. A TypeScript SDK mirrors the same primitives.

What that buys you

Speed, and a debugging story you did not have to instrument. The tracing in particular is the best out-of-the-box observability of the four — for a small team, "I can replay exactly what happened" on day one is worth more than most architectural elegance. Handoffs are the right abstraction for triage-and-delegate shapes, which is a large fraction of real support and routing agents.

The cost

Run context is in the process, so durability across a crash is your problem, and handoffs get awkward when the pattern is genuine parallel collaboration rather than delegation. The SDK is designed around OpenAI's own API surface; other providers are reachable but off the golden path, so this is the framework where model portability costs you the most, and the one whose default tracing destination is a decision your security review will have an opinion about.

What actually transfers, and what does not

Prompts and tool definitions are close to free to move. A function schema is a function schema, and if your tools are behind MCP servers they are not framework-coupled at all — which is the strongest argument for putting them there regardless of what you pick. Evals move too, provided they were written against outcomes rather than against the framework's internals.

Orchestration shape is a rewrite, but a mechanical one. Converting a crew to a graph or a graph to an agent tree is tedious and predictable; you know what it costs before you start.

The state contract does not move. If you built on in-process context and now need to resume a four-hour run after a deploy, there is no incremental path — the control flow above the persistence boundary was written assuming the boundary was not there. This is the same lesson durable state and resumability reaches from the operations side, and it is why the pairing of an orchestration framework with a durable execution engine keeps recurring in production architectures.

When to pick which

One caveat worth stating plainly: none of these choices is as consequential as the shape of the problem. A well-scoped agent with three good tools works on all four. A badly scoped one fails on all four, and the framework will get the blame.

Further reading

On this wiki:

• Agent frameworks — the ground floor, and what a framework is actually for.
• Durable state and resumability — the operations view of the argument this post makes.
• Durable execution: LangGraph plus Temporal — the pairing when one framework is not enough.
• Single vs multi-agent — before you let a role metaphor add four agents.
• Multi-agent topologies — graphs, trees, crews and handoffs as shapes rather than brands.
• Human in the loop — what a durable pause has to guarantee.

Project sources:

• LangGraph — durable execution
• Google Agent Development Kit documentation
• CrewAI — mastering flow state
• OpenAI Agents SDK documentation