Most agent frameworks hide the control flow: you declare agents and tasks, and the framework decides how they execute. LangGraph does the opposite. You draw the graph, so every state transition is visible, every decision point is traceable, and every branch is testable. That is a real advantage and it has a real price, and the honest version of this article has to cover both.
What LangGraph actually is
LangGraph is a library for building stateful, multi-actor applications with language models. Four concepts carry the whole mental model:
- Nodes — functions that take state, do something (call a model, run a tool, make a decision) and return updated state.
- Edges — transitions between nodes, either unconditional or driven by a condition evaluated against state.
- State — one shared data structure flowing through the graph, which is what makes the data flow inspectable.
- Checkpoints — saved state at a point in the run, so a workflow can pause, resume, or be replayed.
It is a state machine whose states are model calls and tool executions and whose transitions are your business rules.
Why explicit control flow matters
- Debugging: when behaviour surprises you, the path is recorded rather than inferred from the framework's internals.
- Testing: a node with a typed state in and out is a unit test. Implicit control flow forces you to test through the whole system.
- Auditing: “the framework decided” is not an audit trail. A recorded path through named nodes is.
- Recovery: resuming from the failed node is only possible if you know which node failed.
When LangGraph is the right choice
- Regulated work — finance, healthcare, legal, where every decision has to be explained to someone external.
- Genuinely branching logic — several decision points whose outcomes matter, not one if-statement.
- Long-running processes — runs measured in hours or days that must survive a restart.
- Sequenced multi-agent handoffs — where control passes in a defined order with a clear state at each boundary.
When LangGraph is the wrong choice
- Single-task agents — one trigger, one judgement, one action has no branches worth drawing.
- Rapid prototyping — explicitness slows the loop while you are still learning what the workflow is.
- Non-technical ownership — someone has to read and maintain the graph. If nobody on the team can, the maintenance burden lands somewhere it will not be paid.
- Agents that should improve over time — checkpointing is durability, not memory. That has to be built separately.
What we run instead, and why
We run nineteen specialist Hermes agents on a single Fedora host with 4 vCPU and 15 GiB of RAM. There is no container runtime, no Kubernetes, and no graph framework in the stack: agents are native systemd units, scheduling is cron, state lives in PostgreSQL and Valkey, and a Caddy proxy fronts the lot. At survey time the five gateway services had accumulated zero restarts.
The reason is the shape of the workload rather than a view about LangGraph. Our fleet is scheduled, per-agent work — 47 jobs on cadences from continuous to weekly — with separation of duties enforced between agents rather than inside one graph: research gathers, an operator agent gates, a coder builds, an independent QA agent verifies, a publisher ships. The control flow lives in which agent is allowed to do what, and that is documented in the19-agent operating system case study.
The second reason is what actually broke. Of six jobs in an error state at survey time, not one failed because a model produced a poor answer. Three were a provider revoking free-tier access to a model slug mid-flight, others were delivery targets that were never configured, and the rest were upstream 500s. An explicit state graph would have recorded those failures more precisely. It would not have prevented a single one of them — that needs a fallback cascade and a delivery check.
LangGraph against the alternatives
| Framework | Control flow | Memory across runs | Best fit |
|---|---|---|---|
| LangGraph | Explicit graph you write | Checkpoints only | Auditable, long-running, branching workflows |
| Hermes | Single agent, per-agent mandate | Persistent | One agent that learns a job and keeps it |
| OpenClaw | Orchestrated handoffs | Persistent | Many agents across many business systems |
| CrewAI | Roles and tasks, implicit | None | Fast prototypes of role-based workflows |
The comparison is about coupling and visibility, not quality. A fuller breakdown of the field, including AutoGen, is in ourCrewAI alternatives comparison.
Testing a graph-based workflow
- Unit tests — state in, state out, one node at a time, no mocking framework required.
- Path tests — assert that a given input follows the expected route through the graph.
- Replay tests — save a checkpoint, change a node, replay, and diff the outcome.
- Failure tests — inject bad data, timeouts and provider errors, and assert the graph degrades the way you intended.
The fourth one is the one to write first, because it is the class that actually shows up. The same discipline applied at the data layer is what keeps a research agent honest — seethe claims ledger case study for the structural version of that argument.
The bottom line
LangGraph is the right tool when the workflow is long, branching, and has to be explained to someone who was not there. It trades speed of iteration for control, and for a regulated process that is a good trade. For a scheduled fleet of narrow agents it is a layer that does not remove one, which is why our own stack is the shape it is.
Whichever way that goes, the framework decision is smaller than it looks next to the tool contracts and the guardrails around it. If you are sizing a build,how long it takes to build a production AI agentis the more useful read, andModel Context Protocol covers the tool layer that sits underneath every option in the table.