The State Machine Pattern Nobody’s Using for AI Agents.

LangGraph, a framework by LangChain, models AI agents as directed cyclic graphs rather than linear chains, enabling conditional branching, loops, and state persistence for robust error recovery in multi-step tasks. The approach addresses structural blind spots in chain-based agents, which fail to handle mid-task exceptions, dynamic retries, or iterative refinement, as demonstrated by a minimal Python example using StateGraph with nodes for planning, tool execution, validation, and repair.

Picture an agent three steps into a five-step task. It has already called an API, parsed a response, and written a partial file to disk. Then step four throws an exception — a rate limit, a malformed JSON blob, a tool that just doesn’t respond. What happens next? If your agent is built as a linear chain — prompt in, tool call, prompt in, tool call, repeat — the honest answer is: nothing good. The chain doesn’t know it failed halfway. It doesn’t know what “halfway” even means. It just breaks, and someone has to clean up the mess by hand. That fragility isn’t a bug in any one implementation. It’s a structural property of chains themselves, and it’s the reason serious agent frameworks have quietly moved on to something else: graphs and state machines. Early LLM pipelines borrowed their shape from Unix pipes: A feeds B feeds C. It’s an elegant model for a fixed sequence of transformations, and it works beautifully when every step succeeds. The trouble is that agentic work is not a fixed sequence. It’s a search process — try something, observe the result, decide what to try next — and a chain has no vocabulary for “decide what to try next.” A pure chain has three structural blind spots: None of this shows up in a demo, because demos are the happy path by construction. It shows up in production, at 2 a.m., when a downstream API returns a 500 and your “autonomous” agent has quietly been retrying the same broken step for twenty minutes, burning tokens and doing nothing. The fix is conceptually old and practically underused: model the agent as a finite state machine, or more generally as a graph of states and transitions, rather than a script. Each node represents a well-defined state of the task — “planning,” “awaiting tool result,” “validating output,” “needs human input,” “done.” Each edge represents a transition that’s taken only when a specific condition holds. This reframing sounds academic until you notice what it buys you for free: This isn’t a new idea in software engineering generally — it’s how robust workflow engines, telecom protocol stacks, and game AI have worked for decades. What’s new is applying it to LLM-driven control flow, where the “transition conditions” are often themselves the output of a model call. There’s one more piece a plain finite state machine doesn’t fully capture: agents often need to loop. Draft an answer, critique it, revise it, critique it again — that’s a cycle, not a straight line, and it needs to terminate based on a dynamic condition a quality threshold, a retry budget, a satisfied user rather than a fixed number of steps. This is exactly the gap frameworks like LangGraph are built to fill. Instead of a directed acyclic graph DAG , which is the right shape for a one-pass pipeline, LangGraph models the agent as a directed cyclic graph: nodes are units of work an LLM call, a tool call, a human-in-the-loop checkpoint , and edges — including edges that loop back on earlier nodes — are conditional functions evaluated against the current shared state. The core insight: a cycle is what lets an agent revise its own work. Without it, you can approximate iteration only by unrolling loops into ever-longer chains — which is brittle in exactly the way we started with. A minimal shape looks like this in practice: python from langgraph.graph import StateGraph, ENDgraph = StateGraph AgentState graph.add node "plan", plan step graph.add node "execute tool", execute tool step graph.add node "validate", validate step graph.add node "repair", repair step graph.set entry point "plan" graph.add edge "plan", "execute tool" graph.add edge "execute tool", "validate" graph.add conditional edges lambda state: "repair" if state "errors" else "done",{"repair": "repair", "done": END},graph.add edge "repair", "execute tool" the cycleapp = graph.compile checkpointer=my checkpointer Notice the pieces a linear chain simply has no place to put: a conditional branch decided by the state itself, an explicit repair node instead of a bare exception, and a cycle back to execute tool that lets the agent retry with new information instead of restarting from scratch. The checkpointer argument matters just as much — it’s what turns “the graph knows its state” into “the graph can be paused, persisted, and resumed exactly where it left off,” including across process restarts. It’s tempting to think of the graph structure as the main event, but the more important design decision is usually the shape of the state object that flows through it. In LangGraph and comparable frameworks, that state is typically a typed, append-friendly structure — message history, intermediate results, error counters, retry budgets — that every node reads from and writes back to. Getting this right is mostly an exercise in restraint. Two failure modes show up constantly: A useful habit is to design the state schema before the graph topology — decide what a node needs to know to make a correct decision, and only then wire up the nodes and edges that pass that information along. A few patterns recur across production agent systems, regardless of framework: None of these require exotic infrastructure. They require treating failure as a first-class, anticipated state of the system rather than an interruption to it. Linear chains fail in agentic environments for a simple, structural reason: they have no concept of “where am I and what do I do if this doesn’t work.” State machines and directed cyclic graphs fix that by making state explicit, transitions conditional, and cycles a normal part of execution rather than a workaround. That’s the real shift LangGraph and its peers represent — not a cleverer prompt, but a more honest model of what agentic work actually looks like: iterative, fallible, and in need of a memory of its own progress. The next time an agent you’re building does something inexplicable mid-task, it’s worth asking not “what prompt caused this” but “what state was it in, and did the graph even have a name for it?” Often, that’s where the real bug — and the real fix — lives. The State Machine Pattern Nobody’s Using for AI Agents. https://pub.towardsai.net/why-your-ai-agent-keeps-falling-over-and-how-state-machines-fix-it-64136543e507 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.