Two requests, one booking: idempotency for AI agents without the jargon

A customer says on the phone, “Yes, Tuesday at two works.” The agent sends the booking request. The calendar API does not respond before the timeout.

Did the booking happen?

The agent cannot tell, so it tries again. The second request returns success. Later the calendar contains two appointments because the first write had also completed even though its response never made it back.

The AI understood the customer correctly. The selected slot was correct. Retrying was even reasonable. The business result was still wrong.

Idempotency is the control that lets the same intended operation be submitted again without creating a second real-world effect.

Idempotency for AI agents starts with the business operation

Many workflows think in API requests. The business thinks in outcomes.

“Book customer 4711 for tyre service on 17 August at 14:00” is one business operation. If the network causes the request to be submitted three times, those should not become three appointments.

Stripe documents idempotency keys for this exact family of API problems: the client attaches a stable key to an operation so a repeated request can return or preserve the earlier result rather than creating another one. AWS’s guidance on saga workflows similarly notes the importance of idempotent participants because steps may be repeated after failures.

Confirmed fact: idempotent operations and idempotency keys are established patterns for safe retries.

Recommendation: give an identity to the intended business operation, not merely to each network request.

Duplicates come from more than timeouts

Users double-click. Webhooks are redelivered. A queue worker completes a write and crashes before marking the job done. Staff handle an item manually while the workflow is paused, then an old queue entry runs after recovery.

Agents add another variation: different language can represent the same intent. “Take Tuesday at two” and “Yes, that Tuesday slot is fine” should not be treated as two separate bookings simply because the model generated two action candidates.

A new random UUID on every attempt is therefore not enough. If each retry receives a fresh key, the target sees every request as new.

Tie the operation key to stable business context where possible: case ID plus action, booking request plus customer and slot, invoice plus payment step, ticket plus transition.

The exact key design depends on the workflow. What matters is that the same logical operation can be recognised across retries.

A practical idempotency flow

A small workflow can implement the pattern without turning into a distributed-systems research project.

1. Define the one-time business operation. What outcome must not occur twice?
2. Create a stable operation key. Preserve it across model retries, transport retries and queue retries.
3. Check before execution. Has this key already reached processing or success, or is there already a matching target object?
4. Persist the result. Store the target object ID and status against the operation.
5. Treat timeout as unknown, not failed. Query status where possible before re-executing.
6. Route ambiguity to an exception queue. If you cannot establish whether the first call committed, verify instead of blindly creating another.

Native idempotency support in the target API is ideal because it protects closest to the effect. When the API lacks it, the orchestration layer can provide a deduplication store — but it must handle concurrency and crashes carefully.

Cross-channel duplicates need business-level deduplication

A caller gets no immediate confirmation and sends a WhatsApp message two minutes later. Voice and chat agents each see a new conversation and each try to book.

Technically they are different sessions. Commercially they may be the same request.

This is beyond a single API idempotency key. Use deduplication signals such as authenticated customer, service, location and requested slot within a short period. But do not over-merge.

Example, not a universal threshold: two matching appointment requests from the same customer within three minutes can be marked as a possible duplicate. The second is linked or held for review, not silently deleted.

A garage customer may genuinely be booking two vehicles. A hotel guest may need two rooms. False deduplication can be as damaging as duplication, so uncertain cases deserve human review.

The minimum pilot should deliberately break acknowledgement

Do not only test “call API → receive success”. Create the ambiguous cases.

Make the target complete the write while your test client receives a timeout. Deliver the same webhook twice. Run two workers with the same job. Complete a queued item manually before replay.

Track duplicate outcomes per 1,000 operations, retries preserving the original operation key, transactions with unknown commit state, time to resolve duplicate exceptions, false-deduplication rate, and external actions whose result ID is linked back to the originating case.

Zero duplicate outcomes is a sensible operational target, not a claim that the architecture can never race. Repeat these tests when integrations or workflow logic change.

The practical conclusion is that agents need idempotency because real systems repeat things. Networks retry, humans click twice, channels overlap and workers crash. If one customer intent is allowed to create one business effect, that identity has to survive all the way through execution.

An API outage and degraded mode makes this protection essential. Reconciliation then checks whether source and destination agree.

Sources

• Stripe — Idempotent requests
• AWS — Saga patterns
• Microsoft — Retry pattern

---