AI agent retry loops: distinguish recovery from repetition

A repeated tool call is not automatically a failure. Retrying a transient error can be the right behavior. A loop becomes operationally concerning when the agent repeats work without resolving the obstacle, exceeds a justified budget, or claims success without evidence that the intended action completed.

Detecting that distinction requires more than counting identical calls. Inspect the action being attempted, what changed between attempts, and whether the final outcome resolves the original request. The examples here are synthetic design cases, not measured detector results.

Define progress in terms of the task

Suppose an agent tries to reserve a meeting room. The first attempt fails because the room is unavailable. A second attempt requests a different available room after checking the user’s constraints. That is a meaningful change. Repeating the original request five times without changing the time, room, or availability evidence probably is not.

Now consider a rate-limited service. Retrying the same request after an appropriate delay may be useful even though the arguments are unchanged. Conversely, an agent can change irrelevant wording on every attempt while making no real progress. Argument differences are signals to inspect, not a complete definition of recovery.

Track the action across attempts

Give each business operation a stable identity and each attempt its own identity. Record the target object, intended effect, observed error, and any new evidence used to justify another attempt. Where the downstream service supports idempotent writes, preserve the relevant application semantics across retries.

A timeout creates special ambiguity. The caller may not know whether the write happened. Retrying blindly can duplicate an action; treating the timeout as a definitive failure can also be wrong. Resolve the operation through an authoritative status check when the application supports one.

A successful later call does not necessarily recover the original action. Reading a record successfully after a failed update is not evidence that the update committed. Completing a different action is also not recovery unless it satisfies the original request or an explicitly accepted alternative.

Use a policy with explicit stop conditions

A retry policy should consider error class, elapsed time, attempt count, idempotency, and available alternatives. The following is conceptual pseudocode, not executable integration code:

if authoritative_outcome == completed:
    stop_with_confirmed_result
elif outcome_is_ambiguous:
    reconcile_operation_before_another_write
elif error_is_retryable and budget_remains:
    retry_under_the_service_policy
elif supported_alternative_exists:
    verify_constraints_before_switching
else:
    stop_and_explain_the_unresolved_action

The ordering matters conceptually: first establish what is already known, then decide whether another action is justified. Your implementation must handle concurrency, cancellations, and service-specific semantics. A generic rule cannot guarantee safety for every downstream operation.

Evaluate behavior and communication separately

An agent may make a reasonable retry and still describe the outcome incorrectly. It may also stop after a failed attempt and communicate that failure accurately. Those are different dimensions: action outcome, retry-policy adherence, and final-claim accuracy.

For example, an agent receives three transient errors, stops within its budget, and tells the user the booking could not be confirmed. The task remains incomplete, but the agent did not falsely claim success. Labeling the whole session simply “bad” loses the information needed to improve it.

Conversely, a retry might eventually succeed after the agent already claimed completion. The business task recovered, but the earlier statement was premature. Preserve timestamps and evidence availability when assessing the communication.

Create paired regression cases

Test repeated calls with and without meaningful new evidence. Pair a transient error followed by confirmed success with the same error followed by an unrelated successful read. Pair a pending operation with an honest pending response and with an unsupported completion claim.

Include a wrong-object case, a cancelled user request, an exhausted retry budget, and a delayed terminal event. Ask reviewers to explain which event resolves the original action. If the expected label depends on a hidden assumption, make that assumption part of the test fixture or revise the completion contract.

Measure useful outcomes

Track unresolved operations, unnecessary attempts, duplicate effects, and unsupported completion claims separately. A falling average retry count can mean better first-attempt success, but it can also mean agents give up too early. Inspect task outcomes before treating fewer calls as an improvement.

Use trace-to-outcome instrumentation to preserve the necessary evidence and random production audits to find patterns your alert rules miss. The aim is not to eliminate retries; it is to make every retry and every completion claim defensible.