Your AI Agent Will Retry. Make Its Actions Idempotent.

Reliable AI agents need safe retries, deduplication and compensating actions before they are allowed to change real business systems.

TL;DR

An AI agent that can call tools will eventually repeat an action.

The model may retry after a timeout. A queue may redeliver an event. A worker may restart after completing an API request but before recording the result.

Without idempotency, one logical action can create:

• Two invoices
• Two CRM records
• Two purchase orders
• Repeated emails
• Duplicate approval tasks
• Conflicting status updates

Reliable AI agents therefore need more than accurate reasoning. Every real-world action should have a stable identity, a deduplication strategy and a defined recovery path.

The Dangerous Part Starts After the Model Decides

Most AI agent demos focus on reasoning:

1. Read the input.
2. Understand the request.
3. Decide what to do.
4. Call a tool.

The fourth step is where production failures begin.

Imagine an agent sends a payment reminder through an external API. The external service accepts the request, but the connection times out before the agent receives confirmation.

What should the agent do?

If it retries blindly, the customer may receive the same reminder twice. If it does not retry, the reminder may never be sent.

This is not primarily an AI reasoning problem. It is a distributed-systems problem.

Networks fail. Workers restart. Messages are redelivered. Responses arrive late. Reliable systems assume that retries will happen and make repeated operations safe.

What Is Idempotency?

An operation is idempotent when performing it several times produces the same intended result as performing it once.

Reading a record is normally idempotent. Updating a project status to approved can also be idempotent because repeating the update leaves the record in the same state.

Creating an invoice, sending an email or issuing a purchase order is different. Repeating the request can create another real-world effect.

AWS recommends making mutating operations idempotent so clients can retry requests without processing the same logical operation multiple times.

For AI agents, that means the platform must know whether a tool call represents:

• A new business action
• A retry of an earlier action
• A correction to an earlier action
• A deliberate second action

The language model should not determine this from conversational context alone.

Give Every Action a Stable Identity

Each intended business action needs an action ID that remains unchanged across retries.

The identity should come from the workflow, not from the individual execution attempt.

For example, a reminder action could be identified by:

• Workflow instance
• Action type
• Target record
• Reminder stage
• Relevant date or version

If the agent retries the same reminder, it uses the same action ID. If the process later reaches a new reminder stage, it receives a different ID.

This distinction matters. A random identifier created on every retry does not provide idempotency because the receiving service sees each attempt as a new request.

Stripe applies this principle through idempotency keys: a client can retry a mutating request with the same key, and the API can return the previously stored result rather than performing the mutation again.

Store an Action Ledger

The agent platform should maintain a durable record of external actions.

A useful action ledger contains:

Field	Purpose
Action ID	Stable identity across retries
Workflow ID	Links the action to its business process
Action type	Email, CRM update, invoice or task
Target	The affected customer, record or system
Input hash	Detects changed parameters
Status	Pending, executing, completed or failed
External reference	ID returned by the destination system
Attempts	Number of execution attempts
Result	Stored response or outcome
Timestamp	Audit and debugging history

Before running a tool, the system checks the ledger.

If the action is complete, it returns the saved result. If it is already executing, the duplicate request waits or stops. If it failed with a retryable error, the system retries under the same action identity.

The ledger becomes the source of truth for what the agent actually did—not what its transcript suggests it intended to do.

Separate Decisions From Side Effects

An AI agent should produce a proposed action before the platform performs the side effect.

The proposed action might say:

• Update opportunity status
• Send reminder email
• Create procurement task
• Request approval
• Escalate overdue payment

A deterministic execution layer then validates:

• Is this action allowed?
• Has it already been completed?
• Are its parameters valid?
• Does it require approval?
• Can it be safely retried?
• Is compensation possible if a later step fails?

This creates a clean boundary.

The model interprets the situation. The execution layer protects the business systems.

Use a Transactional Outbox for Reliable Handoffs

Another failure appears when the application must update its own database and notify another system.

Suppose an agent marks a vendor request as approved and then publishes an event that should create a purchasing task.

If the database update succeeds but event publication fails, the request appears approved while purchasing never receives the work.

The transactional outbox pattern addresses this dual-write problem by saving the business update and its outgoing event in the same database transaction. A separate worker publishes the event afterward, making the handoff recoverable.

The outbox does not eliminate duplicates. It normally provides at-least-once delivery, so consumers still need deduplication and idempotent processing.

Think of the responsibilities this way:

• Outbox: Prevents lost events
• Idempotency key: Identifies repeated requests
• Consumer deduplication: Prevents duplicate outcomes
• Action ledger: Records the complete execution history

Not Every Action Can Be Made Naturally Idempotent

Some operations cannot simply be repeated.

An email that was already sent cannot be unsent. A purchase order accepted by a supplier may create a contractual obligation. A customer may act on a notification before the system discovers that it was incorrect.

For these actions, the system needs one of three strategies.

1. Prevent repetition

Use a unique action key and reject duplicate execution.

2. Make the destination idempotent

Pass the same key to the external API and allow it to return the original result.

3. Define a compensating action

When a completed step cannot be rolled back directly, execute a domain-specific correction such as cancelling a reservation, issuing a reversal or creating a correcting record.

Microsoft’s compensating transaction pattern is designed for multi-step workflows where later failures require completed actions to be undone or corrected through business-specific logic.

Compensation is not the same as deleting history. The original action and its correction should both remain visible.

Classify Tool Calls Before Production

Before giving an agent access to a tool, classify every available action.

Read-only

Examples include searching records, retrieving project status and checking inventory.

These are normally safe to retry.

Idempotent mutation

Examples include setting a status to a specific value or assigning a known owner.

These can usually be repeated safely when the desired final state is explicit.

Deduplicated creation

Examples include creating tasks, invoices, notifications or CRM records.

These need stable action identities and duplicate protection.

Reversible action

Examples include reserving capacity or creating a draft.

These require a defined cancellation or compensation path.

Irreversible or high-impact action

Examples include releasing payment, deleting records or issuing binding commitments.

These need stricter policy controls and should not be exposed as ordinary agent tools.

This classification is more useful than asking whether the AI agent is “autonomous.” The important question is what each tool can change and how the system recovers when execution becomes uncertain.

A Reliable AI Agent Execution Flow

A production tool call should follow this sequence:

1. The agent proposes a structured action.
2. The platform validates permissions and policy.
3. The workflow assigns a stable action ID.
4. The action ledger is checked for an existing result.
5. The platform reserves or records the action.
6. The external tool is called with an idempotency key where supported.
7. The result and external reference are stored.
8. Retryable failures use the same action identity.
9. Permanent failures enter an exception path.
10. Partial completion triggers compensation where necessary.

This pattern applies whether the agent is updating a CRM, coordinating procurement, sending project reminders or synchronising an ERP.

Frequently Asked Questions

Why do AI agents repeat tool calls?

Tool calls may repeat because of network timeouts, application retries, queue redelivery, worker restarts or uncertainty about whether an earlier request completed.

What is an idempotency key?

An idempotency key is a stable identifier attached to repeated attempts of the same logical operation. It allows the receiving system to recognise a retry and avoid performing the side effect again.

Is retry logic enough for reliable AI agents?

No. Retries improve availability but can produce duplicate effects. Retry logic should be combined with idempotency, deduplication, limited attempts, backoff and observable failure handling.

What is the difference between rollback and compensation?

A rollback reverses an operation within a transaction. Compensation performs a separate business action that corrects or offsets an earlier completed step.

Reliable Agents Are Built Around Uncertainty

The model does not need to make the same mistake twice for an AI workflow to create duplicate work.

The infrastructure only needs to become uncertain once.

A production agent must therefore assume that requests may be retried and events may be delivered more than once. Stable action IDs, idempotency keys, action ledgers, transactional outboxes and compensating actions turn that uncertainty into a controlled engineering problem.

Before automating a real process, identify what should be automated first. Then classify every possible action by its risk, retry behaviour and recovery path.

If you are designing the system behind those agents, the MVP to Scale SaaS Architecture Guide is a better next step for thinking through reliable, production-ready architecture as the product grows.

An agent is not reliable because it usually chooses the correct action.

It is reliable when the system remains correct even after the action is attempted twice.