LangGraph
Worth it when the conversation has to survive a crash
You are not buying a way to call a model. What you get is state that persists, plus one resume behaviour that bites teams who skip the docs.
The verdict
LangGraph is the right framework when an agent must pause for a human, resume after a failure, or hold a conversation across many turns, and it is overhead you do not need for a single request that answers in one pass.
The graph is not the value. Persistence is. Checkpointers store a thread's state so the run can be resumed, inspected or rewound, and that is the part you would otherwise build yourself and get wrong.
If your agent answers once and forgets, this is machinery with no job to do.
In short
5 things that decide this
- 01Checkpointers persist a thread's state, which the docs tie to conversation continuity, human-in-the-loop, time travel and fault tolerance.
- 02InMemorySaver stores checkpoints in RAM and loses them when the process restarts, so production means a durable store such as PostgresSaver.
- 03On resume, an interrupted node runs again from the start of its function, so any side effect before the pause happens twice.
- 04Durability is configurable, and the trade is performance against how much you can lose in a crash.
- 05For a one-shot request with no pause and no memory, a plain function is the better build.
For someone who has not used it
LangGraph runs agents as a graph. You define nodes that each do a piece of work, edges that decide what happens next, and a shared state object every node reads and writes.
The reason to accept that structure is what comes with it. State is saved at each step under a thread id, so a run can be paused for approval, resumed tomorrow, or replayed from an earlier point.
What we built with it
Cruise Search AI is the build this review draws on. It is a booking assistant for military veterans, and the job is harder than it sounds: turn loose conversation into validated ship, port and date values the client's existing search engine will accept.
We built the agent on FastAPI and LangGraph with Redis holding session state, then embedded it as a widget inside the client's WordPress site. The clarifying-question flow is the product. A user who says something vague gets asked one useful question rather than an empty result page.
What LangGraph earned there was the conversation surviving. A booking chat spans many turns. Users wander off and come back. A framework that treats state as first-class removed a whole category of bug we would otherwise have written ourselves.
- ThreadOne conversation, one id.
- NodeA step that reads and writes state.
- CheckpointSaved after the step.
- InterruptPause for a human.
- ResumeThe node runs again from the top.
That last station is the one people miss. Resume re-enters the function, so anything it did before the pause happens twice.
Where it stands
Good at
- Persistence is designed in. Checkpointers give you conversation continuity, human approval steps, replay and recovery without writing a state store.
- Pausing for a person is a supported pattern rather than something you bolt on, which matters for anything that touches money or records.
- Being able to rewind a thread and inspect earlier state turns a vague bug report into something you can reproduce.
- The graph forces you to name the states, and that alone catches design problems before code.
Weak at
- A node re-runs from the start of its function when execution resumes, so a side effect placed before the pause fires twice unless you make it idempotent.
- The default in-memory saver loses everything on restart, and a team that demos on it and ships on it has an outage waiting.
- The abstraction has a real learning cost, and a simple agent ends up carrying concepts it never uses.
- Debugging means reading state transitions rather than a stack trace, which is a different skill from ordinary application work.
- The surrounding ecosystem moves quickly, so pinning versions matters more here than in most dependencies.
Conversational agents we run
Common questions
01LangGraph or a plain state machine?
Write the state machine when the steps are fixed and you control every branch. Reach for LangGraph when the model chooses the path, when a person has to approve mid-run, or when a conversation must survive a restart. Persistence and human-in-the-loop are the features that justify the dependency.
02Which checkpointer should we use in production?
A durable one, and Postgres is the obvious choice if you already run it. The docs are clear that in-memory savers hold checkpoints in RAM and lose them when the process restarts. Fine for development. Unacceptable for a live conversation.
03How much does the framework lock us in?
Less than the graph diagram suggests, because the work inside each node is ordinary code that calls a model. What does not port is the state and resume machinery, so moving off it means rebuilding the part you adopted it for. Judge the dependency on that, not on the model calls.
04Does LangGraph require LangChain?
The two are related but not the same decision. LangChain's own documentation says its agents are built on top of LangGraph, taking advantage of durable execution, human-in-the-loop support and persistence. You can use the graph runtime without adopting the wider framework, and on Cruise Search AI the surrounding service is plain FastAPI.
