How Should AI Agents Retry Safely? Authorization Is Only One Part

Introduction

For a tool-using AI agent, “try again after failure” is not a single, harmless operation. A request may already have reached an external system even though the local process has not recorded the result. By the time recovery begins, the agent’s authority may also have changed. Retrying without distinguishing these conditions can duplicate an action or cross a newly tightened permission boundary.

The arXiv paper Permission to Retry studies execution-time reliability in agent workflows while deliberately separating recovery decisions from language-model behavior. Its central question is not whether a model can produce a valid tool call, but whether the surrounding system can decide when to continue, when to deny, and when to preserve an unresolved obligation after interruption or ambiguous outcomes.

Key findings

• Four obligations should remain distinct. A checkpoint describes what the application retained. Permission to dispatch asks whether a call is authorized now. Evidence of an external effect asks whether the provider acted already. Permission to reconcile or settle is a separate decision and cannot be inferred automatically from either state or effect.
• The campaign varied the execution environment. The prospectively frozen study ran 336 histories across native LangGraph and Temporal hosts, 14 schedules, three provider contracts, and four matched application policies. The 168 paired host cells produced identical checked outcomes, suggesting that the observed differences were not simply framework-specific behavior.
• Retained-ledger reconciliation was the most complete tested pattern. The recovering application did not see the provider’s effect ledger; outcomes were scored against that hidden reference. On each host, this approach passed all 42 histories: 21 checked completions, 15 denials, and six unknown outcomes in which reservations remained retained.
• Simpler retry patterns left gaps. Cached retry passed 30 histories, revalidation before retry passed 36, and stable-key retry passed 31. The results indicate that current authorization matters, but permission checks alone cannot replace durable evidence about what happened externally.
• A separate component check adds context. A 16-case study exercised exported authority, worker, recovery, and settlement code from InfinityOS using repository fakes. It is a focused component examination rather than a full production-platform benchmark.

Why it matters

The study offers a useful division of responsibility for agent infrastructure. Authorization answers “may this action be attempted now?” Effect evidence answers “did the provider already perform it?” Settlement permission answers “may the application complete the resulting workflow?” Collapsing these questions into one Boolean status removes precisely the information needed during ambiguous recovery.

For implementers, the practical direction is to retain verifiable observations, use stable idempotency keys, and reassess authority during recovery. Evaluation should also report safety, completion, and unresolved obligations separately instead of reducing everything to a success rate. The campaign is finite, and the InfinityOS exercise relies on repository fakes, so the findings should be read as conformance evidence and design guidance rather than a universal ranking of agent platforms.

As agents begin sending messages, changing records, initiating transactions, or triggering business workflows, the safer capability may not be more aggressive retrying. It may be the ability to pause when evidence is insufficient and leave a clearly tracked obligation for later resolution.

arXiv