Retry

What is a retry?

A retry is another attempt to perform an operation after an earlier attempt failed or returned a result classified as retryable. Agent systems use retries for temporary failures such as rate limits, short network interruptions, unavailable services, or transient model errors.

A retry usually repeats the same intended operation. It may wait, refresh credentials, or adjust transport details, but it does not necessarily change the task strategy.

How it works

A safe retry policy defines:

• which errors are retryable;
• the maximum number of attempts;
• delay and backoff between attempts;
• total time or cost budget;
• whether the operation is idempotent;
• what happens after retries are exhausted.

Exponential backoff and jitter can reduce pressure on an overloaded service. Observability should record each attempt under the same logical operation so teams do not mistake retries for separate user requests.

Simple example

An agent calls a weather API and receives a temporary 503 error. It waits briefly and retries twice. If the service still fails, the agent uses a fallback provider or tells the user that current data is unavailable.

Repeating a “charge credit card” request is different. Without an idempotency key, the second attempt could create a duplicate charge even if the first response was lost.

Retry versus reflection

[Reflection](/glossary/reflection/) evaluates what happened and may revise an answer or approach. A retry re-attempts an operation. Reflection may decide that retrying is appropriate, but the concepts are not the same.

Retry versus replanning

[Replanning](/glossary/replanning/) changes the plan because the current route is blocked or no longer suitable. A retry stays on the same route. If repeated calls fail because a capability is unavailable, continuing to retry is less useful than choosing a different tool or plan.

Why it matters

Retries make agents resilient to temporary faults, but uncontrolled retries increase latency, token cost, load, and duplicate-action risk. They can also hide persistent defects.

Builders should retry narrow operations, not blindly restart an entire agent loop. Pair retries with timeouts, idempotency, error classification, attempt limits, and a clear failure-recovery path. See [Reflection in AI Agents](/reflection-in-ai-agents/) for how agents evaluate unsuccessful results.