Safe retries: why agent actions must be idempotent

Agents retry. A tool call times out, the network drops, the model loses track of whether it already acted, and it tries again. If the action was a payment or a customer message, the retry can do it twice. Idempotent actions, which have the same effect however many times they are repeated, are what make retries safe.

Why do agents retry more than ordinary systems?

Retries are normal in any distributed system. What is different with agents is who decides to retry and how much they know when they do.

A traditional integration retries under fixed rules written by an engineer: three attempts, with a backoff, then fail. An agent may retry because the framework it runs on retries failed tool calls automatically, because the model saw an error and decided to try again, or because a long task was resumed after an interruption and the model could not tell which steps had completed. Sometimes all three happen to the same call.

The model's view of the world is also less reliable than a program's. It may have seen a timeout and concluded the payment failed, when in fact the payment went through and only the response was lost. From the agent's side, those two situations look the same.

What goes wrong without idempotency?

Take an illustrative case. An agent preparing supplier payments calls the payment service to submit a payment of 2,000. The service accepts it and sends it to the rail, but the response is slow and the agent's call times out. The agent, or the framework under it, retries. The service sees a new request and submits a second payment of 2,000.

Now the firm has paid twice. On many rails, especially instant ones, the second payment cannot simply be recalled. It has to be recovered from the supplier, which takes time and goodwill and may not succeed.

The same pattern applies to anything with an external effect.

The last row is worth noticing. "Set the address to X" is naturally idempotent. "Add 50 to the balance" is not. Designing actions as statements of the desired state, rather than as changes, removes a whole class of retry harm.

How do you make an agent action idempotent?

The core technique is an idempotency key: a unique identifier for the intended action, generated once and sent with every attempt. The receiving system stores the key with the result. If it sees the same key again, it returns the stored result instead of acting again.

For agents, three details matter.

1. Generate the key from the intent, not the attempt. The key should be derived from the task and the specific instruction, so a retry after a restart produces the same key. A key generated fresh on each call defeats the purpose.
2. Enforce at the point of action. The check belongs in the layer that executes the action, not in the agent's reasoning. This is the same principle as why enforcement must happen at the moment of action: the agent can be wrong about what it has done; the execution layer cannot.
3. Record every attempt. Each attempt, including those that returned a stored result, should be filed. An append-only record that shows three attempts and one effect is exactly what you need when someone asks why the supplier was or was not paid twice.

Is a reversible action safe to retry without this?

It is tempting to say that if an action can be undone, duplicates do not matter. That underestimates the cost of undoing. A duplicate credit can be reversed, but the customer may have spent it, and reversing it may cause an overdraft. A duplicate message cannot be recalled at all. The question of whether a reversible action is always safe for an agent to take gets a qualified answer for exactly this reason.

For actions that are hard or impossible to undo, idempotency is not optional. The list of which AI agent actions are irreversible is also the list of actions where a retry must never produce a second effect.

What does this mean for connecting agents to core systems?

Many core systems were built for human users and batch jobs, not for callers that retry unpredictably. Some accept idempotency keys; some do not. Where they do not, the agent platform has to supply the protection: a layer in front of the system that records keys and blocks repeats before they reach it.

This belongs in any plan to give an AI agent safe access to a core banking system. It is easier to build before the first agent goes live than after the first duplicate payment.

Where Pryme fits

In Pryme, every action passes through enforcement at the moment it runs, and every attempt is filed in the append-only record with its verdict. Repeated attempts at the same intended action are visible as such, so a retry cannot quietly become a second payment. See the governed agentic operating system, explained.

What should you do differently?

List every action your agents can take that has an external effect. For each, ask what happens if it runs twice. Where the answer is harmful, add an idempotency key derived from the task, enforce it in the execution layer, and prefer actions that set a state over actions that change one.