Idempotency
The property that repeating the same request produces the same single effect, rather than a second one — usually achieved by attaching a stable key to the logical action.
Updated 15 September 2026
In practice
An agent's payment times out. It retries with the same idempotency key, and the provider returns the status of the original charge instead of creating a second one.
The distinction
Idempotency belongs to the logical effect, not the attempt. A retry that gets a new key is not a retry — it is a second purchase, a second message or a second record.
The highest-risk state is not an error
An explicit failure is easy to handle. The dangerous state is the unknown write: the caller does not know whether the provider completed the request.
A system must be able to say "the final effect of this request is not yet known" without converting that uncertainty into a duplicate action or a false success. Marking the outcome unknown, preserving the original attempt and querying the authoritative system is slower than retrying, and it is the difference between one order and two.
When a retry is safe, and when it is not
Retries suit a bounded class of failures: a lost worker before a durable checkpoint, a rate-limit response with a documented retry rule, a temporary dependency outage.
They are unsafe when the system cannot tell whether the side effect committed, when the request is not idempotent, or when the input has changed underneath the run. In those cases the correct next step is reconciliation, not another attempt.
It has to reach the destination
An orchestrator can execute a workflow step exactly once in its own history while the external request is delivered more than once. Durable infrastructure narrows the window; it does not close it.
The destination system, or the application in front of it, has to recognise the key and return the original result. Without that, "exactly once" describes the runtime's bookkeeping rather than the customer's bank account.
Sources & context
x402 payment identifier extension
x402 · 2026
Gives one logical payment request an identifier that survives retries, so a client can reconcile rather than resubmit.
Source checked 2026-09-13
ADK resumability
Google Agent Development Kit · 2026
Documents resuming completed workflow tasks from an invocation ID, and warns explicitly that side-effecting tools may execute more than once.
Source checked 2026-09-13