LangGraph: when your agent needs a real state machine
LangGraph models an agent as a graph of nodes and edges with shared state — giving you explicit, durable control over the multi-step and cyclic flows a linear chain can't express.
A linear chain of LLM calls is fine until your agent needs to loop, branch, remember, or pause for a human. That's the gap LangGraph fills: it models an agent as a graph — nodes, edges, and a shared state — so complex, stateful control flow becomes something you can express, inspect, and trust.
The model: nodes, edges, state
- Nodes — the steps: an LLM call, a tool, or a bit of plain logic.
- Edges — the transitions between nodes, including conditional branches and loops back to an earlier node.
- State — a shared object threaded through the graph, so each node reads and updates a common memory.
Why a graph and not a chain
Real agents cycle — they retry, reflect, and re-plan — and they branch on what they find. Those loops are awkward to bolt onto a straight-line chain but natural in a graph. Because the control flow is explicit, you can reason about it, test it, and see exactly why the agent did what it did (which the anatomy-of-an-agent-framework post argues is the whole game).
What it gives you
- Cycles and loops — the retry-and-reflect patterns agents actually need.
- Conditional routing — send the flow down different paths based on state.
- Persistence and checkpoints — durable, resumable runs you can pause and continue.
- Human-in-the-loop — pause for approval, then resume, which is essential for anything irreversible.
When to reach for it
Use LangGraph when your agent is more than a straight line — multi-step, stateful, and where reliability matters. For a single prompt or a simple sequence, it's overkill; the raw SDK or a light chain is clearer. LangGraph earns its complexity exactly when the workflow gets complex.
A chain runs start to finish. An agent loops, branches, and waits — and for that you want a graph, not a to-do list.