The Infinite Loop Trap: 3 Defenses That Make Your AI Agent Stop Early

An agent that keeps saying “let me check…” but never advances isn’t stuck — it’s in an infinite loop. Three coexisting defenses turn unbounded token burn into predictable convergence, and unattended overnight runs make them non-negotiable.

A real failure case

A real incident from qwen-3.7-plus: while checking kylin_app/apps/CeXia, it kept emitting thinking text like “let me check CeXia directory status” but never actually issued the Glob tool call. No tool ran, no Observation came back, and the context filled with its own monologue; it repeated the same intent until the platform’s Loop detection force-interrupted it:

Loop was detected in the model and the request has been interrupted

The telling detail: every round it concluded “I still need to check the directory” — yet it never actually dispatched the check. And when a task runs overnight, unattended and fully automated, the cost is amplified: during the day a human can interrupt the loop; at night nobody’s watching, so a loop means a whole night of pure token waste — no output, no progress, just a bigger bill by morning.

Model issue, or Agent-framework issue?

Verdict first: mostly an Agent-system (prompt / workflow) problem, not a base-model defect. The base model can call tools; it’s your agent setup — prompt wording, parsing flow, loop backstop — that breaks it.

The framework receives prose it can’t parse into a tool call, so no tool runs and no Observation returns; the model sees nothing changed in history → repeats the same intent → loop. Loop detection then kills the task. “Loop was detected” is just a safety interceptor, not the root cause — it only stops the damage after the loop has already happened.

Two forms of the loop

• Form A — think-without-act (ReAct format violation, highest probability): the model emits only Thought-level natural language and never produces an Action tool-call block. No tool → no Observation → unchanged history → repeats the same intent. This case is Form A.
• Form B — repeat-same-action, same-result, no switch (missing state-change detection): the model does emit a tool call, but re-runs the same check, gets the same result, and never realizes “same result means switch strategy.”

Both originate on the agent side, not in the base model. The defenses below cover both.

Root-cause breakdown

1. 🔴 Prompt / ReAct format violation (highest probability): weak instruction for mandatory tool-call output; context stuffed with duplicate history confusing format-following; stop-sequence cutting output before the tool-call block finishes. Result: the model emits prose the framework can’t parse.
2. 🟡 Agent runtime / framework layer: the loop detector is a safety guardrail, not the source; without dedup logic it won’t block semantically identical thoughts in consecutive steps.
3. 🟢 Pure base-model factor (low probability): occasionally fails tool-call format under long context, but rarely fails every single turn.

Solution overview: three layers of defense

The defense stacks “prompt rules + retry/dedup cap + platform backstop”:

• Defense 1 — prompt dual-constraint: ① format — “if you need to inspect a directory, you MUST output a valid tool-call block immediately after Thought; do NOT only write a natural-language description”; ② anti-repeat — “if you get the same result 2 times in a row, switch strategy immediately.”
• Defense 2 — retry / dedup cap: loop-type actions stop or raise an error after 3 attempts; reject semantically duplicate thoughts in consecutive steps; enforce a max consecutive non-action turns — if N rounds produce no tool call, terminate.
• Defense 3 — platform Loop detection: prefer an IDE/platform that automatically recognizes and interrupts repetitive execution.
• Engineering extras: record the previous result and diff it (detect “no progress”); define what counts as progress (switch paths when there is none); feed parse failures back as Observations instead of appending raw free-text; compress context history; set a timeout/step budget.

Design invariants:

• Any multi-step agent task must define its stop condition and action-format requirement before it runs — no progress triggers a switch or termination.
• One rule is not enough — prompt constraint, retry/dedup cap, and platform detection must coexist.

End-user self-rescue and prevention

No source-code change needed to cut the risk sharply:

1. Already looping: ❌ don’t just click continue (almost always repeats the failure); ✅ abandon the thread, start a brand-new task / fresh window, carrying only your high-level requirement.
2. Preventive prompts: avoid giant “finish the whole Stage 4” prompts. Name the first tool explicitly, force the first-step tool call, add “don’t only describe — execute the tool immediately”; split large multi-stage work into sequential small tasks instead of one 30+ turn autonomous run.
3. Runtime habits: stop manually when turns exceed 20–25 and resume with a summarized progress in a new task; try a more robust model if available; avoid deep nested sub-agent flows.
4. Reuse progress: hand a compact summary to the new task, don’t drag thousands of tokens of broken history.

Outcome

The defense turns “unbounded token-burning waiting” into “predictable convergence”:

• Before: the agent loops, passively killed by platform Loop detection, burning tokens and wall-clock time.
• After: the loop is actively cut at round 2–3, losing only a few rounds of tokens.

For unattended overnight tasks the math is stark: with defenses, early detection and early stopping cost a few rounds; without them, you can burn the whole night and find only an anomalous bill in the morning. True quantified signals are yet to be collected: count loop triggers/interrupts and compare token spend with and without the defenses.

Reproduction checklist

• Write a multi-step check task without action-format and anti-repeat rules; observe whether the agent loops (think-without-act or repeat-same-result).
• Add “emit tool call immediately after Thought + same result 2x in a row → switch strategy” + a retry/dedup cap of 3; re-run and compare.
• Prefer an IDE/platform with built-in Loop detection; confirm the backstop works.
• Run a defended task overnight, unattended; verify the next morning that it converged cleanly with no anomalous token spend.

Conclusion

1. The root cause of infinite loops is mostly an Agent-system (prompt / workflow) problem: the model only emits thinking text and never issues a structured tool call — “Loop was detected” is a safety interceptor, not the source.
2. Two forms: think-without-act (most common) and repeat-same-action-same-result, both solved by explicit agent-side rules.
3. Three layers of defense: prompt dual-constraint, retry/dedup cap, platform Loop detection; end users self-rescue by splitting tasks, forcing the first tool call, and starting a fresh task instead of continuing.

Before writing your next multi-step agent task, ask: “what’s its stop condition, and will it actually emit a tool call on step one?” — write both down and the loop loses its breeding ground. Especially for tasks that will run while you sleep: confirm early detection and early stopping are in place first, then rest easy. Don’t let the bill work the night shift for you.

Note: this is a methodology write-up with qualitative observations; quantitative metrics (loop trigger/interrupt counts, token spend with vs. without defenses) are best measured in your own setup.