OpenAI Agents SDK vs LangGraph vs Google ADK: Choosing by Constraint

They all wrap the same loop

Every framework here implements the loop from the first post in this series: send messages, check for tool calls, execute, append, repeat. If you are comparing them on "does it support tool calling" you are comparing on the part they all share.

What differs is everything around the loop. Where conversation state lives and whether it survives a restart. What the deployment target looks like. How much of a failed run you can reconstruct afterwards. And how much of your team's existing knowledge transfers.

Those four are the actual decision. Take them in order.

Constraint one: where does state live?

If your agent finishes inside one request — a support answer, a classification, a lookup — state is just the message array and any of these will do. Do not over-engineer this case.

If it does not, this is the whole decision. A task that runs for minutes, pauses for human approval, or must resume after a crash needs durable state with checkpointing, and that is LangGraph's central design commitment rather than a feature bolted on. Its graph model exists precisely so that state is explicit and a run can be resumed from a checkpoint.

ADK gives you a session service with pluggable backends, which covers conversation persistence well. It is not the same thing as mid-run checkpointing of a long task. The OpenAI Agents SDK is deliberately lighter here — sessions and handoffs, not a durable execution engine.

Be honest about which you need. Most teams reach for checkpointing when what they actually have is a conversation that needs to survive a page refresh.

Constraint two: where is it going to run?

This eliminates options faster than anything else, and teams tend to consider it last.

If you are on Google Cloud and want a managed runtime with sessions and no server to write, ADK plus Agent Engine is the path with the least glue. That is a real advantage — the deployment story is the framework's own, not something you assemble.

If you are running your own infrastructure, LangGraph deploys anywhere you can run Python, and its hosted platform is optional rather than assumed. The OpenAI Agents SDK is similarly unopinionated: it is a library, you host it.

The trap is choosing a framework on ergonomics and discovering the deployment story is a bespoke container, a session store you now own, and a scaling problem nobody costed.

Constraint three: what can you see when it breaks?

You will spend more time debugging agents than writing them, and frameworks differ sharply in how much of a bad run you can reconstruct a week later.

The question to ask is not "does it have tracing" — they all emit something. It is: given a complaint about a specific answer, can you retrieve the exact prompt, the tools offered, the arguments chosen, what each returned, and the retry chain? If any of that is missing you are guessing.

LangGraph's graph structure makes state at each node inspectable, which is genuinely useful for multi-step runs. ADK's dev UI is the best local iteration experience of the three — you see tool calls and returns live, which catches selection bugs in seconds. The OpenAI SDK's tracing is clean and integrated if you are already in that ecosystem.

Whatever you pick, budget for adding your own spans. Framework defaults are a starting point, not an observability strategy — the later post in this series on what to put in a span covers what to add.

Constraint four: what does your team already know?

This is the least intellectually satisfying constraint and frequently the deciding one. A team fluent in LangChain will be productive in LangGraph next week. A team already on Vertex AI will find ADK's conventions familiar. A team with a single Python service and no ML platform will move fastest with the lightest option.

Framework migration is not free — the loop transfers but the state model, deployment and observability do not. Choosing the theoretically better framework that nobody knows generally costs more than it returns, and the gap between these three is not large enough to justify it.

How to answer this in an interview

"Which agent framework would you use?" is testing whether you can reason about constraints or only recite features. Naming a favourite is the weak answer.

The strong answer inverts it: ask what the task looks like. Long-running with human approval steps points at durable state. Already on GCP with no appetite for infrastructure points at a managed runtime. Team of two with a deadline points at whatever they already know.

Then be explicit that the loop is the same everywhere and the difference is state, deployment, observability and familiarity. That framing shows you have made this choice before rather than read a comparison post.

Does a single run outlive one request?
  ├─ No ──► Any of them. Choose on what your team knows.
  └─ Yes ─► Does it need to resume mid-task after a crash or a human pause?
              ├─ Yes ──► Durable checkpointing is the requirement.
              └─ No ───► Session persistence is enough.

Then: where does it deploy, and can you reconstruct a bad run a week later?

A note on framework risk

This space consolidates. Frameworks merge, get renamed, or go into maintenance mode, and the one you pick today may not be the one you maintain in two years — the next post covers a live example of exactly that.

The defence is architectural, not predictive. Keep your tools as plain functions with no framework imports. Keep prompts in their own module. Keep the agent definition thin. Do that and the framework becomes a layer you can replace in a week rather than a rewrite, because the parts that carry your actual domain logic never depended on it.

That discipline is worth more than picking correctly.