Retry Loops Without Grind: How Agents Should Recover From Failure
Agent retry loops should use diagnosis, changed strategy, bounded attempts, and escalation so recovery improves the plan instead of turning repeated failure into invisible computational grind.
A retry is useful only when something changes
Anthropic’s agent patterns include evaluator-optimizer loops where feedback guides the next attempt, which is fundamentally different from repeating the same call. [1] A good retry loop asks why the previous attempt failed and what new information or strategy justifies another try. Tool timeout, invalid arguments, insufficient evidence, and policy rejection require different responses. Blind repetition wastes cost and can amplify side effects. In motivational terms, a retry should feel like learning from a mistake, not grinding the same level with no new tactic.
Change before repeating
Every retry should have a stated reason the next attempt is more likely to succeed.
Feedback can turn iteration into improvement
Self-Refine showed that model outputs can improve through cycles of feedback and revision when the feedback is meaningful. [2] Agent recovery can use the same pattern for drafts, plans, and structured reasoning. The key is to keep the loop bounded and to preserve what improved. If the evaluator identifies two specific defects, the next attempt should target those defects rather than regenerate everything from scratch. This makes progress cumulative.
Failure thresholds should trigger human intervention
OpenAI’s practical agent guide recommends escalation after repeated failures and human oversight for sensitive actions. [3] Retry budgets operationalize that advice. A low-cost read might get several attempts with exponential backoff. A write with uncertain side effects may get none until state is verified. After the budget is exhausted, the agent should stop, summarize what was tried, and ask for help or choose a safe fallback.
A retry budget is a stopping rule
It prevents the agent from converting uncertainty into an unbounded loop of increasingly expensive guesses.
Runtime failures and expected pauses need different handling
OpenAI’s running-agent guidance distinguishes runtime or validation failures from intentional pauses such as approvals. [4] Recovery logic should preserve that distinction. A pending approval is not something to retry around. A policy denial should not trigger a tool substitution designed to achieve the same forbidden outcome. A transient network error may justify another attempt. The retry controller needs error semantics, not merely a boolean success flag.
Trace evaluation can reveal pathological loops
Workflow-level traces let teams see tool choices, handoffs, and repeated actions across a run. [5] This makes retry behavior directly evaluable. Teams can measure average attempts per task, repeated identical calls, escalation timing, duplicate side effects, and recovery success. Synthetic failure tests should deliberately inject rate limits, malformed responses, missing credentials, and partial writes. Reliability improves when retry logic is treated as a first-class behavior to test.
Loops leave fingerprints
A trace with ten near-identical calls is evidence of a control problem even if the eleventh call eventually succeeds.
Preserve user progress across failed attempts
If a research agent has already gathered five useful sources, a failure on the sixth should not wipe the set. If a scheduling agent cannot create an event, it should preserve the proposed time. Recovery should be incremental. In a gamified system, this matters because progress feedback should correspond to durable accomplishments rather than to the current attempt number. Users should lose as little verified state as possible when one mechanism fails.
Fallbacks should reduce ambition before increasing authority
When the preferred tool or strategy fails, the next move should often be a smaller safe action: produce a draft instead of sending, create a checklist instead of editing the project, or ask for one missing field instead of broadening permissions. This is analogous to lowering difficulty without changing the goal. Recovery should not silently grant the agent a larger action space just because the first route was blocked.
Degrade capability gracefully
A smaller successful step can preserve momentum better than a larger speculative recovery.
Good recovery ends with an understandable story
After a retry sequence, the user should know what failed, what changed, what ultimately succeeded, and whether any side effects occurred. If the system escalates, it should package the evidence so the human does not repeat diagnosis from zero. This turns failure from hidden machine churn into a transparent learning event. The agent demonstrates resilience not by refusing to fail, but by failing in ways that are bounded, informative, and recoverable.
Retry policy should also distinguish deterministic failures from uncertain failures. If a schema validator says a required field is missing, the system can repair that field directly. If an external service returns an ambiguous result after a timeout, repeating the write may create a duplicate side effect, so the agent should verify remote state before retrying. If a model-generated answer fails a quality check, a revised prompt or different strategy may be justified. These categories deserve different backoff, verification, and escalation rules. Treating every failure as identical turns recovery into guesswork. A resilient agent classifies the failure first, then chooses the least costly recovery that can change the outcome without increasing risk.
Works Cited
- 01Anthropic — Building Effective AI Agents anthropic.com
- 02
- 03
- 04OpenAI Developers — Running Agents developers.openai.com
- 05OpenAI Developers — Evaluate Agent Workflows developers.openai.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.