AI Agent State Graph: How It Stops Infinite Loops and Runaway Bills

An AI agent state graph is a fixed map of the steps an AI agent may take, with the allowed moves between them written in ordinary code. The language model works inside each step, but plain code decides which step comes next and when the whole run must stop. That design is the most common answer to a real and expensive failure: agents that repeat the same action forever.

A developer's post-mortem on DEV Community says that four agents ran for eleven days in November 2025 and produced a bill of about $47,000. According to the author, two of the agents kept handing work back and forth with no termination condition and no budget cap. The account is self-reported and not independently verified, but the mechanism it describes is well documented elsewhere.

What is an AI agent state graph?

A state graph has three parts: state, nodes and edges. The state is a shared record of the task so far, such as the user's request, results already collected and a count of attempts. Nodes are the steps. Edges are the arrows that say which node runs next.

The LangGraph documentation describes it this way. Each node is a function that reads the state and returns an update, and it can call a language model or run normal code. Some edges are fixed. Others are conditional: a routing function looks at the state and returns the name of the next node.

The routing function is regular code, so given the same state it always makes the same choice. That is what "deterministic" means here: the path between steps is predictable, even though the text the model writes inside a step is not.

A graph must also be compiled before use. According to the docs, compiling checks that the structure is valid and lets you attach options such as a checkpointer, which saves progress.

Why do AI agents get stuck in infinite loops?

An agent loop is a cycle: the model picks an action, a tool runs it, the result goes back to the model, and the model picks again. The loop ends only when something says it should.

If the model never decides it is done, or a tool keeps returning an error the model cannot fix, the cycle continues. LangChain's own page on the graph recursion limit error says that error is often caused by an infinite loop, for example two nodes whose edges point back at each other.

Each pass through the loop sends the model another request, and providers bill for those requests. A loop that nobody stops therefore turns directly into spend.

The DEV Community author draws a further lesson. In the post-mortem's words, the team "had logging" and "had monitoring" but "did not have a hard limit." The author argues that monitoring only reports a problem, and that a token limit on each call does not cap the total across a run.

How does a state graph stop a loop?

A state graph gives the developer places to put limits that the model cannot talk its way around. Several mechanisms are common.

The first is a step ceiling. LangGraph counts "super-steps", its unit for one round of node execution, and the docs say the recursion limit sets the maximum number the graph can run in a single execution. Going over raises a GraphRecursionError. The docs state the default is 1000 steps from version 1.0.6, and that the limit is passed as a top-level config key when the graph is run.

The second is a graceful exit before the ceiling. The docs describe a RemainingSteps value that a node can read, so the graph can route to a wrap-up step instead of crashing.

The third is a counter held in state. A routing function can check "has this step failed three times?" and send the run to a human-review node.

The fourth is a budget check on money and time. The DEV Community author argues that such a stop should be deterministic (no model in the decision), run before each call and apply to the whole run across dollars, iterations and elapsed time.

Is a high step limit enough to prevent runaway agents?

A step limit is a backstop. A limit of 1000 super-steps is generous, so a loop that makes a paid model call on every step can do a lot of damage before reaching it.

LangChain's error page notes that complex graphs can hit a limit without any bug, and suggests raising the limit through config if the workflow is legitimately long. Raising the number silences the error and leaves a cycle that should not exist in place.

A tighter approach sets the ceiling near the number of steps the task normally needs, and adds counters and budgets for the cases a raw step count misses. A graph that takes 8 steps for a typical task but is allowed 1000 has no practical protection.

The ceiling counts steps only. Ten steps with a very large prompt can cost more than a hundred small ones. That is why the budget check on dollars matters as a separate control.

Can you undo an agent's mistakes with checkpoints?

LangGraph supports checkpointers, which save the graph's state during a run. The docs say checkpoints are written at super-step boundaries, not in the middle of a node.

This helps in two ways. A run that stopped can resume from the last saved point instead of starting over, and the DEV Community author makes the same argument for checkpointing so a crash does not force a repeat of paid work.

It also comes with a warning in the docs. After an interrupt or a retry, the affected node runs again from the start of its function. A node that sends an email or charges a card will do it twice unless it is written to be safe to repeat. A checkpoint saves the state of the graph. It does not reverse actions that already happened in the outside world.

Internal state can be restored, but a payment already made or a record already overwritten needs its own undo logic, or a human check before the risky step.

What are the limits of a deterministic graph?

A fixed graph trades flexibility for control. An agent free to choose its own path can handle tasks nobody planned for. A graph can only follow the routes its authors drew.

Teams therefore tend to mix the two. Predictable parts of a workflow, such as validation, approval and payment, sit in fixed steps. Open-ended parts, such as research or drafting, stay flexible inside a step with their own caps.

A graph also does not make the model correct. If a step produces a wrong answer and the route onward checks nothing, the wrong answer moves along the track. Gates only help if they test something real, such as a schema check or a comparison against a trusted source.

The numbers circulating in vendor and blog material, including percentages for cost savings, usually come from the authors' own setups, and no method or data is published for them.

What to watch next

Framework defaults are worth checking before any agent touches real money. The recursion limit in LangGraph moved to 1000 in version 1.0.6 according to the current docs, and other frameworks set their own caps, so reading the version you actually run matters.

Per-run budgets are another control. The DEV Community post argues for hard dollar and time limits enforced outside the model, and that idea is spreading into proxies and gateways that sit between an agent and its provider.

Human approval steps for irreversible actions are a further control. Teams building agents that book, buy or write to databases are increasingly placing a person at those points.

For related reading on agent systems, see how multi-agent workflows are being adopted and how sandboxes limit what agent-run code can do.