A state graph is a network of nodes (steps) and edges (transitions) that defines the possible paths and handoffs a long-running system can take.
Loops decide what to do next; graphs decide what comes next. The interesting long-running systems are graphs of loops — the graph for routing and auditability, the loops for the parts where the model should genuinely be choosing.
When graphs are the right abstraction
Most production agent systems are not purely prompt-driven. They are networks of nodes (decision points, sub-agents, tool calls, queues) and edges (transitions, retries, approvals). The graph is the formal representation of the network: the nodes are the steps, the edges are the transitions, and the graph's state is the current position in the network. The graph is the right abstraction when the system needs to be auditable (the graph is the record of what happened), when the system needs to be replayable (the graph is the sequence of steps), or when the system needs to be branched (the graph can fork for A/B testing or for parallel work).
When loops are the right abstraction
The loop is the right abstraction when the work is open-ended and the termination condition is fuzzy. The loop is what makes the agent agentic: the loop is the thing that lets the agent decide what to do next based on the result of the previous step. The loop is the wrong abstraction when the work is well-defined and the steps are predictable — a graph is cleaner because the graph makes the predictability explicit.
Why production systems are graphs of loops
The interesting long-running systems are graphs of loops. The graph provides the routing and the auditability; the loops provide the decision-making. The graph is the part that is reviewable by a human operator; the loop is the part that is reviewable by the model. The graph is the part that is checkpointed; the loop is the part that is re-runnable. The graph is the part that is versioned; the loop is the part that is parameterized.
Operator implications
The state graph is the right place to start when an operator is debugging a system that is not behaving as expected. Most production issues are not about the model's capabilities — they are about the graph's edges: a transition is incorrect, a retry is missing, an approval is blocking, a queue is stalled. The graph is also the right place to start when an operator is adding capabilities — the canonical question is "which node needs to be added and which edges need to be wired?"
Related terms
The state graph is the routing layer that sits above the agent loop. The graph's state is often persisted through the memory layer or through a checkpointing service. The graph's branching is often orchestrated by HITL approvals. The graph's execution is scheduled by the cron and tracked through the session.
For the full comparison, see Loops vs Graphs.
Why graphs are the operator's friend
The graph is the right abstraction for the operator because the graph makes the agent's behavior visible. The graph is the place where the operator can see what the agent did, what the agent should have done, and what the agent did differently. The graph is the audit trail. The graph is the source of truth for the agent's behavior.