Law 40 · Architecture & Operations
Retries Demand Idempotency
If an action can run twice, a retry will eventually run it twice.
The principle
Agents retry — on timeouts, rate limits, transient errors — but a failed call that never returned may have already succeeded server-side. Without an idempotency key, the retry that 'fixes' a network blip silently double-charges the card, double-sends the email, or double-books the room. Safe retries require the server to dedupe.
Why it happens
The trap is the ambiguous failure: a side-effecting call can succeed on the server while the response is lost to a timeout or dropped connection, so the client sees failure and retries an operation that already happened. Without server-side deduplication this double-charges the card or double-sends the email, and at scale these ambiguous failures are routine, not rare. The standard fix is an idempotency key: a client-generated unique value sent with the request, against which the server records the outcome of the first attempt and replays that same stored result for any retry carrying the same key, so the effect occurs exactly once. Retries also need exponential backoff with jitter, because synchronized retries against a struggling dependency amplify load and can drive the cascading failure the retry was meant to survive.
Watch for
- A side-effecting tool call is retried on timeout with no key that lets the server recognize a duplicate.
- Retries fire immediately or on a fixed interval rather than with exponential backoff and jitter.
- You have seen duplicate charges, emails, or records traced to a network blip rather than a logic bug.
In practice
Your billing agent calls the charge endpoint, the response times out, and the agent's retry logic dutifully fires again. The first call had already succeeded server-side, so the customer gets charged twice and opens an angry ticket. Network blips are routine, so a retry policy without deduplication will eventually double-charge someone. Generate an idempotency key per logical action and pass it on every side-effecting call so the server collapses the duplicate, and never let an agent blindly re-run a non-idempotent operation.
Apply it
- Generate a unique idempotency key per logical action and send it on every side-effecting call so the server can dedupe.
- Never let the agent blindly retry a non-idempotent operation without that key.
- Retry with exponential backoff and jitter so synchronized retries do not amplify load on a struggling dependency.
The takeaway
Attach a client-generated idempotency key to every side-effecting tool call so the server can deduplicate retries. Never let an agent blindly retry a non-idempotent action.