Retries are essential for reliable AI agents because networks fail, APIs time out and tools return transient errors. But retries can also create dangerous duplicates. An agent that is unsure whether a payment, email or database write succeeded may repeat the action and create a second side effect. Safe recovery depends on idempotency: the ability to repeat a request without producing an unintended duplicate result.

Separate read retries from write retries

Reads are usually safer to repeat. Writes may create external effects and need stronger protection. Agent runtimes should classify tools by side-effect level rather than applying one retry policy to everything. A failed search and an uncertain bank transfer are not equivalent.

Use idempotency keys for external actions. Generate a stable operation ID before the first attempt and send it with every retry. Supporting services can recognize that the same logical action has already been processed. This is common in payment APIs and should become normal for agent-facing tools.

Persist state before execution

Record the intended action and operation ID before calling the external tool. If the process crashes, the agent can recover the existing operation rather than inventing a new one. Durable state is especially important for long-running workflows.

Check status before repeating uncertain actions. A timeout does not necessarily mean failure. The remote service may have completed the request but the response was lost. Before retrying, query operation status when the provider supports it. This turns uncertainty into a deterministic state check.

Make tool responses include durable identifiers

Creation tools should return record IDs, message IDs, transaction hashes or job IDs. The agent can store these identifiers and use them for later verification. Without a stable ID, recovery becomes guesswork.

Retry only errors that are likely transient. Network failure, temporary rate limits and service unavailability may justify retry. Invalid parameters, permission denial and missing resources usually require repair or user input. Error classification prevents endless loops.

Use exponential backoff and limits

Retries should become less frequent over time and stop after a defined number of attempts. Aggressive retry storms can make an outage worse. Add jitter when many agents may retry the same provider simultaneously.

Human approval should not be duplicated. If a user approved one logical action, a retry should reference that same approval rather than asking again or creating a second approval object. The approval should be bound to the operation ID and parameters. If parameters change, new approval may be required.

Design compensating actions for irreversible mistakes

Some systems cannot guarantee perfect idempotency. For those cases, define compensation such as refunding a duplicate payment or deleting an accidentally duplicated record. Compensation is a last resort, not a substitute for prevention.

Trace retries as part of the workflow. Logs should show original attempt, retry reason, operation ID and final state. This makes incidents understandable and supports debugging. Our article on AI agent state machines explains how explicit workflow state supports safe recovery.

Design idempotency across multi-step workflows

One operation ID is sometimes not enough. A workflow may create a customer record, send an email and charge a card. Each external side effect should have its own stable idempotency key linked to the parent task, so recovery can repeat only the steps whose final state is uncertain. The state machine can record each step as planned, executing, succeeded, failed or unknown. After a crash, the agent checks the status of unknown steps before continuing. This avoids the common mistake of restarting the entire workflow from the beginning. Fine-grained idempotency is especially important when tools belong to different providers and cannot participate in one atomic transaction.

Expose retry state to operators and users. Long-running automation is easier to trust when the interface shows whether an action is waiting, retrying, confirmed or uncertain. Hiding retry logic behind a spinner makes it difficult to know whether a duplicate side effect is still possible. For higher-risk workflows, keep an audit view with the operation ID and last verified state. Operators can then distinguish a request that failed before execution from one that may have succeeded but lost its confirmation, which requires a different recovery path.

Reliable agents must be safe to repeat

Autonomous systems will encounter uncertainty. Idempotency keys, durable operation state, status checks and bounded retries make that uncertainty survivable without turning one user instruction into multiple real-world actions.