A retry loop occurs when an AI agent repeatedly attempts the same action — usually because a tool returned an ambiguous result, an error the agent cannot resolve, or a task without a clear completion condition. Each iteration costs the full input token price of the accumulated context plus output tokens for another response that does not advance the task. Left unchecked, a single loop can consume tens of thousands of dollars before anyone notices.
Why do retry loops happen?
Retry loops occur when an agent lacks one or more of three exit mechanisms:
No iteration cap. Without a hard limit on the number of steps, the agent runs indefinitely. The LLM cannot reliably decide when it is done — it requires a deterministic external guardrail to stop.
Ambiguous tool results. When a tool returns an empty string, None, an exception message, or a response that could mean either success or partial completion, the agent treats it as incomplete and retries. The tool succeeds technically but provides no signal that tells the model to stop.
No completion check. Open-ended system prompts like "keep trying until it works" give the agent no definition of done. The model may produce coherent-looking reasoning through dozens of iterations simply because nothing marks the task as finished.
How do I detect a retry loop?
Check for repeated tool calls in session traces. The clearest retry loop signature is the same tool name appearing five or more consecutive times with identical input arguments. If your observability tool shows the call tree of a session, this pattern is immediately visible. If you are logging raw tool calls, query for sessions where the same tool-argument pair appears three or more times within a single session.
Monitor session length and token counts together. A session that runs for 30 or more steps with rising token counts but no completed output is likely looping. The cost escalation is rapid because each new turn pays for the full accumulated context from all prior turns.
Watch for missing final-answer signals. In ReAct-style agents, the expected pattern is alternating thought, action, and observation steps, terminating with a final answer. Traces that show the thought-action-observation cycle continuing past a reasonable step count without a terminal step are a strong loop indicator.
Set a token spend alert at a per-session threshold. A session exceeding a cost threshold calibrated to your application's normal range — for example, five times the average session cost — should trigger an alert. This surfaces runaway loops before they compound to significant amounts.
How do I prevent retry loops?
Hard iteration caps. Every agent deployment should enforce a maximum step count. When the cap is reached, the agent should surface what it accomplished and what it could not complete, rather than running indefinitely.
Repeated action detection. Before executing a new action, compare it against recent actions in the same session. If the proposed action is identical to one already taken, trigger a loop detection flag rather than executing again.
Clear tool success states. Tool responses that unambiguously indicate success — rather than ambiguous partial results — give the model a signal to stop. One documented case showed that clear success states reduced tool calls from 14 to 2 for equivalent outcomes.
Separate completion checks. For complex workflows, a secondary check — either a separate model call or a deterministic condition — evaluates whether the task is complete rather than leaving that judgment to the same model running the loop.
What are common mistakes to avoid?
- Deploying agents without a hard maximum step count
- Tool functions that return ambiguous results on both success and failure
- System prompts with open-ended completion language
- No session-level cost alerting to catch loops before they run long
- Relying on the agent itself to determine when it is done
