How to Stop an LLM Agent From Repeating Failed Steps

If your agent keeps repeating a failed step and burning budget, look at the rule that lets it try again. The evidence points to the orchestration layer, rather than the model, as the place to intervene.

In a 24,000-episode simulation reported this September (arXiv:2609.30662), an agent governed by a separate executive layer used 36.4% fewer tokens than the same architecture under local control without that layer, at essentially identical success rates.

The symptom: spend that scales with failure, not task length

A retry loop has a distinctive cost signature. Two tasks of identical length produce wildly different bills depending on how many times the agent attempts a step that cannot succeed. Long-horizon tasks do not inherently cost more; long-horizon tasks with unbounded failure recovery do. Each repeated attempt re-reads context, re-plans, and re-issues tool calls, so token spend tracks the count of failed attempts rather than the size of the problem.

It is frustrating to pay for persistence that no longer helps the task. If persistence is driving the bill, upgrading the model or extending the context window treats the wrong variable. A smarter model that still decides whether to retry a failed step for the fortieth time has the same structural defect as a weaker one. The useful question shifts from “is the model capable enough” to “who has the authority to stop, and under what contract.”

Why it happens: the dominant loop has no retry contract

The retry loop is not an exotic edge case. A 2026 survey of 70 open-source LLM agent projects (arXiv:2604.11378) found that 60% (42 of 70) adopt the Agent Loop pattern, in which the model observes, thinks, and acts in a single self-conditioned cycle. The same paper identifies the structural defect directly: “failure recovery has no bounded semantics. When a step fails, the LLM autonomously decides whether to retry, skip, or replan—with no explicit contract specifying which recovery actions are available for which failure types, and no bound on how many attempts may be made.”

In the majority pattern, nobody has specified an attempt cap, a failure taxonomy, or a separate decision-maker for replanning versus stopping. Retry loops are the default behavior of an architecture that leaves recovery undefined. Better model weights do not supply that missing contract.

A second preprint, “LLM Parkinsonism”, locates the problem more precisely. Its authors argue that persistence after failure is “not explained by autoregressive next-token prediction alone, but more directly by concentrating proposal generation, scope interpretation, progress assessment, and stopping authority within the same self-conditioned loop.” The component that proposes an action is also the component that judges whether it worked and whether to try again. That is a conflict of interest baked into the control flow, and it parallels what we covered in why production agents fail silently: systems that trust the agent’s own report of progress instead of an independent check keep missing failures that a separate verifier catches.

The Parkinsonism paper names the resulting behavior “token-inefficient persistence”: continued action after the task-level value of further attempts has collapsed. The name is provocative; treat it as the authors’ framing rather than an established diagnosis. It is a single 2026 preprint, and everything quantitative below is a reported claim from that preprint’s simulations, not a replicated result.

Diagnosis checklist: match the behavior to the missing control

Start by identifying what the agent is repeating. A repeated tool call, a drifting plan, and a bad diagnosis need different controls; applying the wrong fix wastes more effort.

Two rows deserve emphasis. The fourth row kills a comforting assumption: “the model will notice it is failing” is not supported by evidence. On the Who&When benchmark, the best step-level attribution accuracy for LLM-judge baselines is about 14%, according to the Causal Agent Replay preprint. Agents, and the LLM judges asked to grade them, cannot reliably identify which step failed. Any control design that depends on the model correctly self-diagnosing its failed step inherits that error rate. This is also why agents derailing mid-run is so hard to catch from per-step logs: the error originates early and the trajectory compounds it while nothing in the output looks broken yet.

Three levels of control, in order of cost

Bounded recovery contracts are the starting point. The Agent Loop survey’s critique implies a practical minimum: for each failure type, declare the available recovery actions, cap the attempts, and define when to replan or stop. This requires no new model calls and no architecture change. It does not catch drift or poor plan selection, but it puts a bound on retry spend instead of letting the agent keep spending.

Candidate-set local control compares possible actions before committing, rather than acting on the first proposal. In the GEC preprint’s matched-candidate benchmark of 24,000 episodes under a 40,000-token ceiling (arXiv:2609.30662), this is where nearly all the success improvement came from: 67.42% hard-goal success for a first-candidate baseline and 96.53% for candidate-set local control.

That gap, about 29 points, makes action selection worth examining before raw model capability. It was the binding constraint in these simulations.

Global executive control (GEC v0.2) adds the layer the Parkinsonism paper proposes: an uncertainty-aware governance process that keeps project-level state (scope, evidence, resource use, and stopping) separate from action generation. Its reported contribution is efficiency, not success: 96.57% versus 96.53% is a rounding-level difference, while mean token use dropped from 19,782 to 12,574 (36.4%) and restricted mean tokens to completion at the ceiling fell from 16,136 to 13,114 (18.7%) (arXiv:2609.30662).

The authors also report eliminating measured pre-completion drift and sharply reducing gross complexity, with favorable overhead sensitivity through an additional 500 synthetic governance tokens per cycle.

The control idea also appears in separate work on a Structured Cognitive Loop, which puts symbolic control around neural reasoning. It reports zero policy violations, prevention of redundant tool calls, and complete decision traceability in multi-step conditional reasoning experiments. The mechanism differs, but the conclusion is similar: structured control outside the generation loop prevents repeated actions. This report is also preprint-stage and self-evaluated. It supports the direction of the recommendation rather than proving it.

What the simulations show, and what they cannot

Keep the GEC figures tied to their test setting. They all come from mechanistic simulations, and the authors say so themselves: “These mechanistic simulations support explicit governance of scope, evidence, resource use, and stopping, while live-model validation remains necessary.” There is no independent replication and no production model run. The preprint offers a mechanistic argument with quantified design guidance: separating stopping authority from action generation can preserve success while cutting token spend, and the savings survive plausible governance overhead in the simulated regime.

A live implementation still has questions to answer. Would a frontier model with its own trained-in self-correction show the same 36.4% saving (arXiv:2609.30662)? Would prompts and state tracking cost more than the synthetic 500-token-per-cycle assumption? The simulations cannot settle either question. Nor do they establish that the near-zero success delta over local control (0.04 points) generalizes.

That small delta is a reason to avoid buying the heaviest architecture first. In the reported results, local candidate control buys success, while global executive control buys token efficiency and auditability. Order adoption around the problem you need to solve.

Two lookalikes that will fool your loop detector

Unreliable self-diagnosis. As noted above, ~14% step-level attribution accuracy (arXiv:2606.08275) means an agent can appear to be “stuck in a loop” when the actual problem is an early, misidentified failure that later steps keep building on. Loop detection that watches for repeated identical calls catches the dumb version of persistence. It misses the version where each retry is plausibly different and equally doomed. This is the same compounding pattern behind fabricated success on long-horizon tasks, where the failure that matters is not any single step but the trajectory-level divergence between reported and actual state.

Infected persistence. The Zombie Agents preprint describes a two-phase attack: during infection, the agent reads a poisoned source while completing a benign task and writes a payload into long-term memory through its normal update process; during trigger, the payload is retrieved or carried forward and causes unauthorized tool behavior. From the outside, this looks exactly like a retry loop or a stubborn agent: the same unauthorized action, attempted persistently, across sessions. No amount of retry capping fixes it, because the behavior is the attack working as designed. If your “loop” survives a fresh context and appears across unrelated tasks, audit the memory writes before you touch the control flow.

Decision: when an executive layer beats a model upgrade

Choose the control that addresses the failure you can identify.

If your agent burns tokens on repeated failed calls, start with the bounded recovery contract: enumerate failure types, cap attempts per type, and define who escalates to replan or stop. This addresses the structural default that 60% of surveyed projects ship with (arXiv:2604.11378), at near-zero cost.

If the agent selects bad actions or never reassesses, add candidate-set local control. In the only quantified comparison available, that is where the success gains were, and it is simpler than a full executive layer.

I would add a GEC-style global executive layer when token economics and auditability justify the extra work: long-horizon tasks where persistence-driven spend dominates, or workflows that need project-level state (scope, evidence, resource use) to survive any single step. Treat the reported 36.4% token saving (arXiv:2609.30662) as simulation-backed design guidance, not a benchmark you will reproduce.

Do not spend the budget on a bigger model or a longer context window to solve this. Neither changes who holds stopping authority. And do not trust the agent to notice its own failure; the attribution evidence says it usually cannot.

The headline architecture still rests on one preprint’s mechanistic simulations, with no live-model validation or independent replication. It evaluates no specific framework, so use it as a control principle rather than a feature recommendation for LangGraph, AutoGen, or the OpenAI Agents SDK. The principle, separating stopping authority from action generation and bounding recovery, stands on the convergence of several 2026 preprints. The specific numbers await a live model.