Preventing Infinite Loops in LLM Planning Agents
Discover the three root causes of infinite loops in LLM agents and how to stop them.
An Infinite Agentic Loop, or IAL, is a specific failure mode: an execution where a feedback path keeps triggering LLM calls, tool invocations, agent handoffs, or workflow transitions without anything that counts as an effective stop condition. It isn't shorthand for "the agent has a bug." No exception fires, no model call errors out, and nothing in the logs looks broken at a glance. The agent just keeps going, and understanding why means looking past the code and into how planning, tool responses, and termination logic interact with each other.
The three root causes that let feedback paths run without bound
Most IALs trace back to one of three gaps, and the three tend to compound each other.
The first is a missing terminal state. Plenty of agent builds have nothing standing between normal operation and a runaway loop except a step cap: max_iterations set to some round number. A cap is a backstop, not a goal check. It stops the bleeding once the count is hit, but says nothing about whether the task got done at step 4 or step 40. The agent keeps stepping right up to the ceiling even when the work finished long before it got there, because the cap was never built to know what "done" looks like.
The second is ambiguous tool feedback, and it deserves more blame than it usually gets. A response like "more results may be available" or "prices change frequently" reads to a language model as an invitation to try again. There's no SUCCESS or FAILED flag to anchor against, just prose the model has to interpret, and it tends to read hedged language as a reason to retry in hopes of a better answer. Without an explicit terminal signal, the agent has no way to recognize the job is finished, so it keeps asking.
The third is stale or absent progress tracking. If the agent's state never records what it already did, every step looks like a fresh start. The planner re-decides the same action it took three steps ago because nothing tells it the action already happened. A customer-support bot that keeps asking for an order ID the caller already typed in is the clearest version of this: the order ID was given, but nothing in state remembers it, so the request loop repeats, politely, forever.
A fourth factor makes all three worse: retry amplification. Retry logic exists to smooth over transient failures, a flaky API, a dropped connection, and building it is reasonable. The trouble starts when the underlying tool keeps returning the same unhelpful result instead of a genuine error. At that point retry logic stops functioning as resilience engineering and turns into its own unbounded loop, just wearing better clothes.
IAL concentration points: frameworks, feedback paths, and the re-planner pattern
IALs don't spread evenly across the agent-framework landscape, and the concentration tells you where to look first. Findings cluster heavily in LangGraph and AutoGen, which together account for 45 of 68 confirmed IAL findings across 31 projects, or 66.2%. That's a direct consequence of how these frameworks express control flow: feedback runs through APIs and node graphs rather than through a while statement sitting in plain view during code review. A loop hidden inside a graph edge is far easier to miss than a loop spelled out in a for-loop.
Three feedback path types cover most of it: retry feedback with no bound, tool-call iteration with no bound, and multiagent chat with no turn bound. Together they account for 69.1% of findings. What ties them together is that the trigger for re-entering the loop looks like ordinary control flow. Parser errors, validator failures, a repeated tool request, a generated agent message: any of these can route execution back into another model call, tool call, or agent turn, and none of it looks wrong in isolation.
The riskiest spot in the whole architecture is the re-planner node in Plan-then-Execute designs. Anyone triaging a suspected IAL should start there, not somewhere else. After each execution step, the re-planner receives the original objective, the original plan, and the full history of steps taken and their outcomes, then decides what happens next. That mechanism exists so an agent can recover from a bad step and adjust course, and that's a legitimate reason to build it. But without an effective bound on how many times re-planning can happen, the loop takes root in the one place designed to fix things.
Who feels the damage across an organization
The same failure looks completely different depending on who's looking at it, which is part of why it stays invisible until it gets expensive.
Developers see traces full of repeated tool spans and no final answer, with nothing raising an exception to flag it. SREs watch p99 latency and worker utilization climb without a matching rise in completed tasks, a pattern that looks like a capacity problem until someone pulls the traces. Product teams hear about it through drop-offs, thumbs-down ratings, and support tickets that say some version of "the bot is stuck." Finance sees it in token and tool-call spend climbing, because every extra loop iteration is another paid model step landing on someone's invoice.
Per-message quality checks miss this pattern because they evaluate each message in isolation instead of the sequence across nodes. Take two nodes in a multi-agent sales workflow trading the same lead back and forth: one rechecks CRM fields, another re-requests approval, a third re-updates the lead score; each individual draft or message looks fine sitting on its own. The defect appears only when someone examines the whole trajectory instead of any single output inside it.
Red-teaming work described in the Agents of Chaos research (arXiv:2602.20021) makes the point sharply. In a lab environment giving autonomous agents persistent memory, email, Discord, a file system, and shell access over a two-week window, agents readily spun up background processes with no termination condition at all, turning tasks meant to be short-lived into open-ended ones. Left alone with the tools to keep going, agents keep going. That's the default, not the exception, when nothing structurally forces a stop.
The TraceFix study (arXiv:2605.07935) puts a number on the baseline risk before any mitigation: in a paired ablation under a fixed runtime, roughly 31.1% of multi-agent runs hit deadlock or livelock before TLC-verified protocols were applied. Call it one run in three. That's the scale of the problem multi-agent systems carry before anyone builds a single defense against it.
Detection before the loop completes: signals, evaluators, and trajectory-level observability
Treat an IAL as a defect in the trajectory. Look at the sequence of steps a run takes, never a single step pulled out of context.
Detection means comparing adjacent steps for repetition: same tool name, same arguments, same planner reasoning, same piece of state still missing. Exact string matching catches the crude cases and misses the subtler ones, where the model paraphrases its own reasoning each time it repeats an action. Evaluators need to catch semantic near-duplicates, not just identical text, or half the real loops slip past unnoticed.
A handful of habits routinely hide loops from the people trying to find them, and most teams fall into at least one. Counting steps alone doesn't work: a twelve-step run can be entirely legitimate, while a four-step run can still be a loop if every one of those four steps circles back to the same missing piece of state. Leaning on a hard max-step limit stops runaway cost but doesn't tell anyone which planner, tool, or handoff caused the repetition. Mixing loop latency in with plain slow-tool latency muddies root-cause work, since the two need entirely different fixes. And retrying a tool as a fix for a suspected loop usually backfires: a blind retry against a tool that keeps returning the same unhelpful result just deepens the exact loop someone was trying to break.
A few signals are worth instrumenting directly, and none of them require exotic tooling. Loop-rate by workflow tracks the share of traces showing repeated steps past some threshold. Token cost per trace matters because loops raise cost against a flat completion rate. Escalation rate works as a proxy for user frustration, since repeated prompts from the agent tend to correlate with users bailing to a human. A step-efficiency score flags runs burning far more steps than the task warranted, even the ones that eventually got there anyway.
Planning-layer defenses: goal checks, progress contracts, and bounded re-planning
Setting max_iterations, max_turns, or max_iter solves a different problem than the one that actually matters, and treating it as the fix ignores that these caps were never designed to recognize completion. These settings are backstops against runaway cost, not goal checks that recognize when the work is done. An agent that finishes the task on step 3 still burns every remaining step up to the cap if nothing in the system is watching for completion.
What's needed instead is an explicit terminal state, defined at the planning level, before the run even starts, so the system knows what "done" looks like rather than only knowing what action comes next. Goal-check logic should evaluate the accumulated state against that success condition at every re-planning step, handing the re-planner a pass or fail verdict grounded in the actual objective.
Pair that with a progress contract: every planning step has to produce some measurable new state. A new piece of evidence retrieved, a subtask marked complete, or a result written somewhere durable counts; re-asserting the same intent in slightly different words does not. A step that produces no new state is a loop candidate, no matter how convincingly the model narrates its reasoning around it.
The re-planner deserves its own bound, tighter than whatever bound governs ordinary tool calls, because it's the highest-risk site in the whole architecture. It receives the full objective, the full original plan, and the complete step history at every iteration, so that context keeps growing with each pass. A separate cap on re-planning iterations guards against infinite loops, and it also keeps the run from simply running out of context window as the history piles up underneath it.
Tool-call layer defenses: response schemas, clear terminal states, and feedback contracts
An ambiguous tool response and a clear one differ in measurable, countable ways. A tool that answers "Found 2 flights, more may be available" invites another call almost by design. A tool that answers "SUCCESS: Booking HT79265 confirmed" gives the agent nothing left to chase. In one documented demo, switching a tool over to explicit terminal states cut its tool calls from 14 down to 2, a sevenfold drop, just by removing the ambiguity in the wording.
Tool responses work best treated as contracts, not descriptions. Every response should carry a state the planner can act on directly: SUCCESS, FAILED, PARTIAL, or NO_RESULT, not prose the model has to interpret on its own. Phrases like "prices change frequently" or "more results may be available" read as helpful but function as an invitation to loop. PARTIAL and NO_RESULT responses in particular need a machine-readable flag alongside whatever human-readable explanation rides along with them, so the planner routes on the signal instead of guessing at what the sentence means.
Any tool with a real-world side effect, a write, a booking, a message sent, needs to be idempotent or deduplicated at the tool layer itself. The planner can't be the only thing standing between a repeated call and a duplicated booking, because it won't always catch it. This matters more than it sounds like it should: 95.6% of confirmed IAL findings carry both API cost exhaustion and a form of model denial-of-service as direct impacts.
Retrieval tools deserve particular scrutiny, more than they usually get. A high similarity score from a vector search says nothing about whether the retrieved text actually answers the question asked. An agent can pull back content that scores well but is outdated, decide the answer feels incomplete, and re-query with the same question or a lightly rephrased version of it, over and over, each time convinced this pass will land. Retrieval tools should return a freshness signal along with the content itself, so the planner can tell "nothing found" apart from "found something, but it's stale," and treat the second as its own terminal state instead of a cue to try again. The same failure occurs with live web-grounded search: results can look relevant on the surface without containing the specific fact the agent actually needs, and without an explicit NO_ANSWER state to fall back on, the agent just keeps re-querying, indefinitely, on a question that was never going to get a better answer.
Runtime-observation layer defenses: monitors, hard vetos, and cost-aware circuit breakers
Planning-layer and tool-layer defenses catch most IALs before they start, but neither one watches the system while it actually runs. That's the job of the runtime-observation layer, and it matters precisely because the first two layers won't catch everything: a planner can pass its own goal check on faulty logic, and a tool can return a technically valid terminal state that still leads nowhere useful.
A runtime monitor's job is to watch the trajectory unfold and flag repetition the planning and tool layers missed, comparing recent steps against the same signals detection work relies on: repeated tool names, repeated arguments, no new state added despite several steps having passed. When those signals cross a threshold, the monitor needs the authority to issue a hard veto and kill the run outright, rather than logging a warning and letting things continue, because a warning nobody reads in real time does nothing to stop the token meter from spinning.
Cost-aware circuit breakers extend the same idea to spend instead of step count. A run can look well-behaved on a step-by-step basis while quietly burning far more in tokens and tool calls than the task could ever justify, and a breaker tied to cost per trace, rather than to steps alone, catches that pattern no matter how the loop gets dressed up at the reasoning level. None of this replaces the planning-layer or tool-layer work described above. It assumes those defenses will sometimes fail anyway, and builds a stop that doesn't depend on the agent ever recognizing its own mistake.
