LangGraph vs Claude Agent SDK
One is a graph engine you design yourself. The other is a working agent loop you adopt. They solve different problems that look similar from a distance.
The short answer
Pick LangGraph when you need to engineer the control flow yourself, with explicit state and deterministic edges between steps. Reach for the Claude Agent SDK when you want the harness done for you: tools, context management and autonomy, and you are committed to Claude as the model.
LangGraph models an agent as a graph: nodes are steps, edges decide what runs next, and a checkpointer saves state after each one. You write the nodes and the routing logic. The framework's job is running that graph reliably, resuming it after a crash and pausing it for a human when a node asks it to.
The Claude Agent SDK skips the graph entirely. It gives you the same tool loop, file access and context management that runs Claude Code, as a library for Python or TypeScript. There is no state machine to design. Anthropic already decided how the loop runs. You configure permissions and tools, not edges.
Side by side
Both frameworks remove work you would otherwise write by hand. They disagree about how much control you keep.
| Dimension | LangGraph | Claude Agent SDK |
|---|---|---|
| Core model | A graph you design: nodes, edges and shared state | One packaged agent loop, given tools and a workspace |
| Control flow | Explicit. You write the routing logic between steps | Implicit. The agent decides its own next action inside the loop |
| Model provider | Any LLM provider, swappable per node | Built around Claude; not designed to run other model families |
| Persistence | Checkpointers save graph state, so a run resumes or rewinds | Sessions resume or fork, scoped to one agent's history |
| Human in the loop | Interrupts pause a node and wait for approval before continuing | Permission gates decide which tool calls run unattended |
| Built-in tools | None. You wire in whatever tools the graph's nodes need | File read, write, edit, command execution and web search, out of the box |
| Multi-agent shape | Native: agents are just nodes, wired however you route them | Subagents delegate a task, but the design centres on one primary agent |
| Languages | Python and JavaScript/TypeScript | Python and TypeScript as a library; other languages drive the CLI as a subprocess |
| Natural fit | A workflow with branches, retries and a human checkpoint you have to control | A single agent that needs to act on real files, commands or a codebase |
- Task arrivesA request or a user turn.
- LangGraph: edge function decidesYour code picks the next node.
- LangGraph: checkpoint savedState persists after each step.
- Claude SDK: agent picks the next toolThe loop decides, not your code.
- Claude SDK: permission gateAuto-run, or a human approves.
- ResultA graph trace, or one agent's tool-call history.
LangGraph puts the routing decision in code you wrote and can inspect edge by edge. The Claude Agent SDK puts that decision inside the model's own loop, and gives you a permission gate instead of a routing table.
LangGraph
Where it wins
- You see and control every routing decision, which matters when a workflow has real branches: approvals, retries, or a step that only runs under specific conditions.
- Checkpointed state means a long-running process survives a crash or a deploy, and you can inspect exactly what happened at each node afterward.
- Works with any model provider, so a change in which LLM powers a given node does not mean rebuilding the workflow around it.
- Multi-agent systems are a natural fit. Agents are nodes, and the graph is how they hand work to each other.
Where it hurts
- You design and maintain the graph yourself. There is no built-in tool loop or file access; every capability the agent needs, you wire in.
- More moving parts to reason about than a single agent loop. A graph with many nodes and conditional edges is its own thing to debug.
- No permission system out of the box. If an agent node can run commands or touch files, you build the safety layer around it.
- The persistence and graph-building concepts have a learning curve before a team ships its first production graph.
Claude Agent SDK
Where it wins
- File and command access, context management and the tool loop are built in, so an agent that has to change something in a codebase needs no custom scaffolding for that.
- Permissions are first-class: you decide which tool calls run unattended and which stop for a person, which is what makes an agent with real system access defensible.
- You adopt a runtime that already powers Claude Code in production, rather than assembling the equivalent yourself from smaller pieces.
- Sessions resume or fork, turning a long task into something recoverable instead of something restarted from zero.
Where it hurts
- Built around Claude. Swapping in a different model family means leaving the SDK, not reconfiguring it.
- The loop's control flow is the model's own reasoning, not a routing table you wrote, so a step that must always happen in a fixed order needs your own guardrails around the agent.
- Coordinating several distinct specialists is not what the primitives are shaped for; subagents delegate a task but the design centres on one primary agent.
- Library support stops at Python and TypeScript. Other languages mean driving the CLI as a subprocess.
How to choose
- Pick LangGraph if the workflow has real branches, needs a human approval step, or has to run against more than one model provider over its lifetime.
- Pick the Claude Agent SDK if the job is one agent with deep, permissioned access to files and commands, and Claude is already the model you have committed to.
- Pick neither if the task is a single request that returns one answer. Both frameworks solve multi-step, stateful problems, and add overhead a single API call does not need.
- Combine them if you have to. A LangGraph node can call the Claude Agent SDK for the step that needs deep tool access, while the graph still owns the overall routing and checkpointing. That is two systems to operate, not one, so do it only where each earns its place.
- Wait on either one if the workflow is not written down yet. Neither framework fixes an undefined process; both just make the loop that runs a defined one faster to build.
Questions teams ask before picking one
01Can LangGraph and the Claude Agent SDK be used together?
Yes. A common pattern is a LangGraph node that calls into the Claude Agent SDK for a step needing deep file or command access. The graph keeps ownership of routing, retries and checkpointed state around it. That is two systems to run rather than one, so reserve this for graphs where a specific node genuinely needs the SDK's tool loop.
02Does the Claude Agent SDK support other models besides Claude?
No. It is built around Claude's tool-calling behaviour, context management and permission model. A project that needs several model providers, or a swap per step, fits LangGraph's provider-agnostic design instead. The Claude Agent SDK does not offer that.
03Which one is easier to debug when a run goes wrong?
LangGraph gives you a graph trace: which node ran, in what order, with what state at each checkpoint. That is explicit because you wrote the routing. A Claude Agent SDK run gives you one agent's tool-call history instead. It is simpler to read, but there is no routing decision to inspect outside the model's own reasoning.
04Do I need LangGraph if I am only building one agent?
Usually not. LangGraph earns its complexity when a workflow has branches, needs a human checkpoint, or coordinates several agents. A single agent acting on files and commands is closer to what the Claude Agent SDK is built for directly, with less to assemble.
Related
- LangGraph review →Where checkpointed state earns its overhead, and where it does not.
- Claude Agent SDK review →Our production notes on the tool loop and the permission layer.
- Hire Claude Agent SDK developers →Engineers who have shipped permission-gated agents on this stack.
- AI agent frameworks, ranked →Where these two sit against the rest of the field.
