Your prototype works. One model, a few tools, a loop you wrote yourself in an afternoon. Then someone asks what happens when the third tool call fails at 2am, and whether the run can resume, and who approves the refund the agent just decided to issue.
That is the moment the framework question stops being academic.
Three stacks come up in almost every one of these conversations: Anthropic's Claude Agent SDK, LangChain's LangGraph, and the OpenAI Agents SDK. Most comparisons of them are listicles that describe features nobody disputes. This one is about the tradeoffs you actually feel six months in.

What is the difference between these three frameworks?
The Claude Agent SDK gives you a batteries-included agent loop with built-in file and shell tools. LangGraph gives you a graph you define yourself, with durable state and checkpoints. The OpenAI Agents SDK gives you a small typed layer over agents, handoffs and guardrails. The first two differ in how much you build. The third differs in how much it assumes.
That is the whole comparison in four sentences. The rest of this post is why each of those choices costs you something later.
Claude Agent SDK
The Claude Agent SDK is the agent loop, built-in tools and context management that power Claude Code, packaged as a Python or TypeScript library. Agents get Read, Write, Edit, Bash, Glob, Grep, WebSearch and WebFetch without you implementing any of them (Anthropic docs).
Two things make it distinct. Subagents are child agents with their own context windows, their own tools, and optionally their own models, so a cheap model can do the reading while an expensive one does the reasoning. And context compaction is automatic, which is the part teams usually discover they need only after their first long run dies.
LangGraph
LangGraph reached 1.0 general availability on 22 October 2025 (LangChain changelog). It models an agent as a directed graph you define: nodes are steps, edges are transitions, and state flows between them.
The payoff is durability. Execution state persists automatically, so a server restart mid-run does not lose the conversation. Human-in-the-loop pauses are first class rather than something you bolt on. LangChain reports 90 million monthly downloads and production use at Uber, JP Morgan, BlackRock, Cisco, LinkedIn and Klarna (LangChain blog).
OpenAI Agents SDK
The OpenAI Agents SDK shipped in March 2025 as the production successor to the experimental Swarm project, which now redirects to it. It is deliberately small, built on three primitives: agents, handoffs and guardrails (OpenAI docs).
Handoffs are the interesting one. Instead of a supervisor routing work, one agent transfers the conversation to another with context intact. Guardrails run validation in parallel with execution and fail fast. Tracing is built in and lands in the OpenAI Traces dashboard.
How do the three compare on the things that matter?
| Claude Agent SDK | LangGraph | OpenAI Agents SDK | |
|---|---|---|---|
| Mental model | Agent loop with tools | Graph you define | Agents that hand off |
| Built-in tools | File, shell, search, fetch | None, you supply them | None, you supply them |
| Durable state | Sessions and compaction | Checkpointed, resumable | Not built in |
| Human in the loop | Via hooks | First class | Via guardrails |
| Observability | Hooks and your own tracing | LangSmith | OpenAI Traces, built in |
| Model portability | Anthropic models | Any provider | LiteLLM adapter, beta |
| Learning curve | Low | High | Low |
| Best for | Coding and file-heavy agents | Long-running stateful workflows | Multi-agent routing |
Read that table as three different bets rather than three scores. Anthropic bet on the loop being solved. LangChain bet on you needing control. OpenAI bet on small surface area.
When is a lightweight SDK enough?
For most teams, longer than they expect. If your agent runs inside a single request, calls a handful of tools, and can safely start over on failure, a graph framework is machinery you will maintain without using.
Reach for the lightweight option when:
- A run finishes in one session and restarting is acceptable
- The tool set is stable and small
- Nobody needs to approve anything mid-run
- The work is mostly reading, editing and searching
That last case is where the Claude Agent SDK is hard to beat, because the file and shell tools are already written and already handle the edge cases you would spend two weeks rediscovering.
Most teams pick a graph framework for a workflow that never needed a graph. The complexity arrives on day one. The benefit arrives on day two hundred, if at all.
When does LangGraph earn its complexity?
LangGraph pays for itself when a run outlives the request that started it. Multi-day approval flows, background jobs that resume after a deploy, anything where losing state means losing real work. Durable checkpoints and first-class human-in-the-loop are the two features you cannot cheaply rebuild yourself.
The honest cost is the learning curve. You are defining state schemas, nodes and edges before your agent does anything useful. On a two-week project that is most of the budget. On a two-year system it is the reason the thing still runs.
A practical test: if you cannot describe what happens when your agent is interrupted halfway, you need durability more than you need speed.
The lock-in question nobody answers honestly
Every comparison says LangGraph is model agnostic and the vendor SDKs are not. That is roughly true and completely useless, because it skips the part that costs money.
Here is the accurate version.
Claude Agent SDK ties you to Anthropic models. That is the design, not an oversight. The built-in tools and the compaction behaviour are tuned for them.
The OpenAI Agents SDK supports 100+ providers through a LiteLLM extension, which the documentation describes as a best-effort beta integration (OpenAI docs). Portability exists. It is not a first-class guarantee, and "beta" is doing real work in that sentence.
LangGraph is genuinely provider neutral, because orchestration lives in your graph rather than in a vendor's loop.
But model lock-in is the cheap kind. Swapping a model is usually a config change and an eval run. The expensive lock-in is orchestration lock-in: the state machine, the retries, the checkpoints, the human approval steps. That logic is yours in LangGraph and largely the framework's in the other two.
So the question is not "can I change models later." It is "how much of my system is written in someone else's abstractions."

Which has the best observability?
The OpenAI Agents SDK is the only one where useful tracing works with no setup. Every LLM generation, tool call, handoff and guardrail check is captured and viewable in the Traces dashboard. For a team that has never instrumented an agent, that head start is worth more than most feature differences.
LangGraph pairs with LangSmith, which is more capable and a separate product decision. You get step-level replay of a graph run, which is the right shape for debugging a state machine. You also get another vendor in your stack.
The Claude Agent SDK gives you hooks at each step and expects you to route them somewhere. More work, and the only option of the three that leaves your traces entirely in your own infrastructure. If you work in a regulated environment, that is not a small detail.
Common mistakes teams make choosing
Choosing for the demo instead of the failure. The framework you pick should be judged on what it does when a tool call times out, not on how fast you got a hello world running.
Treating multi-agent as the default. Every delegation costs a round trip and a re-briefing. Two agents that share a context are usually one agent with better prompts. Reach for handoffs and subagents when the work genuinely splits, not because the framework has the feature.
Underestimating the cost of a graph. Nodes, edges and state schemas are real code with real bugs. If nobody on the team can explain the graph in a whiteboard sketch, it will rot.
Assuming portability you have not tested. A beta adapter is not a migration plan. If switching providers matters commercially, run one real workload through the alternative before you promise anyone it is easy.
Skipping evals entirely. Every framework here will happily run a broken agent forever. None of them tell you the output got worse. That is your job, and it is the one thing that does not come in any box. If you are wiring an agent into a process people depend on, the workflow automation around it needs the same error handling and run log you would give any other pipeline.
What we would pick
At Kraftzen we build these for small teams, and the honest default is the smallest thing that survives the failure mode you actually have.
Most client work starts on a lightweight SDK, because most client work is a bounded task with a stable tool set. We move to LangGraph when a run has to survive a restart or wait on a human, which is a real requirement roughly one project in four. We have never regretted starting small and migrating. We have regretted the reverse.
Key takeaways
- The Claude Agent SDK is the fastest path when the work is files, shell and search, because those tools are already written.
- LangGraph reached 1.0 GA on 22 October 2025 and is the only one of the three with durable, resumable state as a core feature.
- The OpenAI Agents SDK is the smallest surface area and the only one with useful tracing out of the box.
- Model lock-in is cheap to escape. Orchestration lock-in is not, so judge frameworks on how much of your control flow they own.
- The OpenAI SDK's non-OpenAI model support runs through a LiteLLM adapter that its own docs call best-effort beta. Test it before relying on it.
- Choose on your failure mode, not your demo. If you cannot say what happens when a run is interrupted, that is the question to answer first.
- None of the three give you evals. Whichever you pick, that work is still yours.




