AI Agent Infinite Loop: Fix the Death Spiral — Diagnose It

Your agent is not broken. It’s stuck in a task it has no way to finish, and no rule that tells it to stop. We see this every week. The agent edits the same file, runs the same test, claims “done,” reverts, edits again. Tokens burn. The session ends with the work undone and the codebase worse than before. Forums call it a death spiral. We call it under-finish — a measurable failure mode with a measurable fix. The math is older than AI. Little’s Law from queueing theory says cycle time equals work-in-progress divided by throughput. Two active features at one feature per day means each takes two days. Five active features means five days each, and a five-fold increase in the chance any one lands half-done. Agents inherit the same arithmetic — they just hide it behind confident self-reports. This page gives you the three signs to diagnose a spiral in your own logs, the math behind why it happens, and the four-rule circuit breaker we run on our own production fleet.

The loop isn’t random — it’s an unfinished task pretending to be done

When an agent keeps editing the same file or re-running the same test, the instinct is to blame randomness — bad luck, a flaky model, a hard problem. It isn’t random. A loop is a deterministic symptom of one thing: a task the agent has no executable way to mark complete. With no gate that returns a hard pass/fail, the agent substitutes its own judgment, decides it “looks done,” gets contradicted by reality, and starts over. The same missing gate produces the same loop every time.

You can put a number on it. We diagnose spirals with a single ratio — the Verified Completion Rate (VCR): of the tasks the agent activated (started working), how many reached a state a deterministic check confirms as passing. A healthy agent runs near VCR = 1. A spiraling agent runs well below it: lots of activity, little verified completion. That gap is the loop, quantified.

VCR = verified_passing / activated

# healthy agent
verified_passing = 9 , activated = 10   → VCR = 0.90

# spiraling agent (same task re-activated, never gated green)
verified_passing = 1 , activated = 8    → VCR = 0.13
                                          # 7 activations, 1 real finish = the loop

Three symptoms that tell a death spiral apart from normal iteration

Iteration is healthy: an agent should edit, test, and refine. A spiral looks similar from the outside, which is why it eats a whole session before you notice. These three signals separate productive iteration from a loop. If you see all three together, stop the run — you have a spiral, not progress.

• Same file, 3+ edits, no new test passing. Healthy iteration moves the needle: each edit flips a red check green. A spiral edits the same file three, four, five times and the passing-test count never changes. Edit volume up, verified progress flat.
• “Looks done” then reverts. The agent declares completion, then — on its own next step — undoes or rewrites the same change. A self-report of “done” immediately followed by a revert of that exact work is the spiral’s signature.
• Activated tasks > 1. More than one task in flight at once. The agent juggles, context-switches, and finishes none. WIP above one is the precondition that turns an ordinary hard task into a circling one.
• (Bonus) Token burn outruns diff size. Tokens spent climb steeply while the net diff barely grows. Lots of motion, almost no committed change — the economic shadow of the loop.

Little’s Law: why two active tasks means each takes twice as long

The reason a spiral gets worse with more work-in-progress isn’t psychology — it’s arithmetic, and it predates AI by decades. Little’s Law, from queueing theory, relates three quantities: the average time an item spends in the system (W), the average number of items in the system (L), and the throughput at which the system completes them (λ). Hold throughput fixed and cycle time rises in direct proportion to how much you have in flight.

W = L / λ      # cycle time = work-in-progress / throughput

# throughput fixed at λ = 1 finished feature / day
L = 1 active  →  W = 1 / 1 = 1 day   per feature
L = 2 active  →  W = 2 / 1 = 2 days  per feature   # 2x slower
L = 5 active  →  W = 5 / 1 = 5 days  per feature   # 5x slower

# longer each item stays open = more steps it can be interrupted,
# reverted, or left half-done. doubling WIP ~ doubles loop risk.

Two active tasks at one finish per day means each one stays open for two days instead of one. The longer a task stays open, the more steps exist in which it can be interrupted, reverted, or left half-done — so doubling work-in-progress roughly doubles the chance any single item ends in a loop. Agents inherit this exactly. They don’t escape the math; they just hide it behind confident self-reports that say “almost done” on day four.

The kill switch: a four-step circuit breaker we run on our own fleet

We run 10+ agents with real capital downstream of what they do, so a silent spiral costs us money, not just tokens. This is the circuit breaker we actually run. It isn’t a prompt tweak — it’s four structural rules that make the loop impossible to enter and impossible to hide.

1. Executable proof of completion. “Done” must be produced by a command that returns an exit code — not by the agent’s judgment that work “looks done.” No exit 0, no done. This removes the self-assessment step the spiral feeds on.
2. WIP = 1. One activated task at a time. By Little’s Law, the lowest possible cycle time and the fewest steps in which a task can be reverted. Nothing else may start until the current task is gated green.
3. Block new activations when VCR < 1. If the agent’s verified completion rate has dropped below 1, it has unfinished work pretending to be done. Freeze activations until the open task closes for real. This is the actual circuit breaker — it stops the loop from spawning more loop.
4. Commit per feature. Each verified-green feature is committed before the next begins. A commit is an irreversible “this happened,” so a later step can’t quietly revert finished work — and the diff history makes token-burn-without-progress visible at a glance.

The shape of the fix. Rules 1 and 3 remove the agent’s ability to fake completion; rules 2 and 4 remove its ability to keep half-finished work in motion. Together they convert “loops silently until the session dies” into “blocks loudly the moment a task can’t close” — which is exactly the signal you want.

What WIP=1 alone can’t fix: the gate blindness underneath

The circuit breaker stops a single spiral. It does not tell you why your gate was missing in the first place. If you find one spiral, you almost always have more — because the same hole that let this task loop (no executable definition of done, no verification gate, no goal hierarchy) is present across the whole harness around your agent. WIP=1 caps the blast radius of each loop; it doesn’t close the holes that keep producing them.

Closing the holes is a different job: a systematic map of every layer of the environment around your agent — task spec, conventions, dev environment, verification gate, cross-session context, and the management layer that decides what to work on next. That’s what our audit does. It scores all six layers, points at the thin ones, and anchors each finding to a line in your own logs. The spiral you just stopped is usually finding 1 of N. See the systematic gap-map →