When you need a graph and when you do not
If your agent does one thing and stops, you do not need LangGraph. A function with a single model call is fine. You reach for a graph when the agent must loop, branch, recover, or hand off to a human.
The mental model
A LangGraph workflow is a state machine. Nodes do work. Edges decide what happens next. The state is a typed object that every node can read from and write to. That is the whole thing.
Why a typed state pays off
Untyped state turns every node into a guessing game. Typed state lets you change one part of the workflow without breaking the rest. Treat the state schema like an API contract.
A simple pattern that scales
For most product agents, three nodes are enough to start: plan, act, and reflect. Plan decides the next step. Act invokes a tool or model. Reflect inspects the result and decides whether to loop, finish, or escalate. Add more nodes only when you can write a sentence about why they exist.
Checkpoints save you
Persist state at every node boundary. When an agent crashes at step seven, you do not want to start at step one. Checkpoints also make human-in-the-loop natural. Pause the graph, send the partial state to a human, resume on approval.
Production checklist
- Typed state schema with explicit nullables.
- Persistent checkpoints in your own database.
- Tracing on every node so a failed run is reproducible.
- Cost and token limits enforced at the graph level, not inside each tool.
- A human approval node for anything destructive.
Related reading
For the larger picture, see The LLM Stack in 2026. For the why-not, see LangChain in Production.
