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

When an agent repeats the same failing action, compare what changed between attempts. A retry that tests a new hypothesis can be useful. A retry with no new evidence, no changed condition and no stopping rule can consume a session without moving the task forward.

Missing acceptance checks are one possible cause. Tool failures, contradictory instructions, an unsuitable strategy or a model capability limit can also produce repetition. Diagnose the observed boundary rather than assuming one deterministic cause.

Look for progress, not activity

Review the attempt history with the expected outcome beside it. Repeated edits to one file, a completion claim followed by an undo, or growing token use without a verified result are useful warning signs. None is proof on its own: a difficult debugging task may need several edits before one check changes.

Attempt / time / task revision:
Hypothesis being tested:
Changed input or condition:
Check and observed result:
New evidence / none:
External effect already possible:
Next decision: CONTINUE / CHANGE APPROACH / STOP

Use a defined observation window. If you count verified completions against activated tasks, state whether activations mean distinct tasks or repeated attempts. Do not mix those denominators.

verified_completion_share = verified_completed_tasks / distinct_started_tasks
open_tasks = distinct_started_tasks - closed_tasks

Report blocked, cancelled and unknown tasks separately. A low completion share can reflect long work in progress or a legitimate blocker, not necessarily a retry loop. There is no universal requirement that this ratio remain one at every instant.

Limit work in progress for the actual bottleneck

Queueing relationships can help describe stable workflows. Under Little’s Law, average items in a system equal average throughput multiplied by average time in the system. Holding throughput fixed, more average work in progress means more average elapsed time. This does not imply that doubling work in progress doubles an agent’s probability of looping.

Reducing concurrent work can make dependencies and unfinished tasks easier to see. One active task is a useful policy for a tightly coupled repair or a single shared writer. Independent work may benefit from controlled concurrency. Choose the limit for the resource and risk instead of treating one as a mathematical optimum for every system.

Use a bounded circuit breaker

1. Define completion evidence. Name the artifact or external outcome and the check that observes it. An exit code is useful only when its check covers the promised result.
2. Set an attempt and effect budget. State what can be retried, what new evidence is required and when the operator must stop. Choose limits for the task; repeated external writes need stricter treatment than a local read.
3. Stop or change approach when progress stalls. Preserve logs, the current revision and the failed hypothesis. Escalation can be the correct result when the dependency or authority is missing.
4. Keep verified changes in version history. A commit records a reviewable checkpoint. It can still be reverted or superseded, so a later step must check the current state rather than treating a commit as irreversible proof.

These controls bound attempts and make some failures visible. They do not make loops impossible. Check that the controller actually enforces the stop decision and that the completion summary does not ignore a failed gate.

Reconcile before restarting

A timeout does not always mean nothing happened. Before replaying an action that can send messages, charge an account or write records, inspect prior effects or use the application’s duplicate protection. Do not use a new session to escape an unresolved effect or an exhausted permission boundary.

For local coding, preserve the current diff and identify the specific failed check. Verify that the next hypothesis changes something relevant. If a gate cannot observe the required result, repair that observation rather than accepting repeated green self-reports.

For recurring loops, start with a written brief: the attempts, checks, external-effect uncertainty and stopping rule. An agent audit can use that evidence to distinguish task, environment, verification and capability problems without assuming a single cause.