The agent submits a purchase request. The procurement API accepts it, but the response never reaches the agent. The agent tries again. Now finance has two requests for the same purchase.
The model did not need to hallucinate. A normal timeout was enough.
AI agent idempotency means repeated attempts at the same authorized operation do not create additional business effects. Build that protection into the action service and the target-system integration. A prompt asking the model to “avoid duplicates” cannot establish whether an earlier request committed.
Start with the business operation
An agent run, a tool invocation, and a purchase request are different things. A single purchase may involve several agent turns and several network attempts.
Give the authorized purchase operation a stable identifier. Preserve it across retries and worker restarts. A genuine second purchase must receive a new identifier, even if its amount and supplier match the first.
AWS's guidance on idempotent APIs explains the value of caller-provided request identifiers: identical parameters do not necessarily represent duplicate intent. This distinction also matters when an agent repeats an action.
Keep an execution record outside the model
The following is a proposed implementation pattern, rather than a guarantee supplied by every agent framework.
Store the operation ID, tenant, action type, approved input fingerprint, execution state, and downstream reference in a durable record. Useful states include prepared, submitted, succeeded, failed, and outcome-unknown.
| Situation | Action service response |
|---|---|
| New operation with valid authority | Register it and begin execution |
| Same operation and same inputs, already succeeded | Return the recorded result |
| Same operation, different inputs | Reject the conflict and require a new decision |
| Same operation still running | Return pending status; do not launch a second execution |
| Downstream timeout after submission | Mark outcome unknown and reconcile |
Use a uniqueness constraint and atomic state transitions to prevent two workers from both deciding that an operation is new. Keep tenant identity in the lookup boundary.
Pass the identity to the system that commits the action
Where the downstream API supports idempotency keys, use its documented mechanism and confirm its scope, expiry, and payload-matching behavior. Your own database entry cannot make an unrelated external write atomic.
Where the API lacks that feature, investigate a unique external-reference field, a conditional write, or a reconciliation query. If none is reliable, move uncertain outcomes to human review rather than blindly repeating the write.
Also check whether SDKs and queue workers retry independently. Three retry layers can multiply attempts even when each layer looks conservative in isolation.
Bind approvals to the exact operation
An approval for one supplier and amount should not authorize a changed request. Store the approved input fingerprint with the operation. Revalidate authority immediately before execution.
Separate execution retries from a fresh business decision. A network retry may reuse the original identity; a changed purchase should go through the applicable approval path again.
For approval design, read LuMay's guide to human-in-the-loop AI agents.
Illustrative example: a response disappears
A hypothetical service team authorizes operation PO-781. The API creates purchase record P-905, but the connection drops before the agent receives confirmation.
The action service records an unknown outcome. It queries the procurement system using PO-781. When the query returns P-905, it records success and returns that reference. It does not infer failure from silence.
If the query cannot establish what happened, the task stays unresolved. The user sees “submission status is being checked,” rather than an unsupported success message or another purchase attempt.
Test the uncomfortable cases
Inject failures before submission, after the target commits, and before the local success record is saved. Deliver the same queue item twice. Restart a worker mid-operation. Try the same operation ID with changed inputs and from another tenant.
The pass condition is one intended business effect, a recoverable execution record, and an accurate user-visible status. Counting successful HTTP responses is insufficient.
Choose retention for idempotency records around the longest retry and recovery window. Document what happens after keys expire; do not describe finite duplicate suppression as universal exactly-once execution.
Frequently asked questions
Should a second click on Submit reuse the same operation ID?
Reuse it only when the second click is another attempt at the same authorized request. A separate intended purchase needs a new ID, even when its fields match. Define that distinction in the application rather than asking the model to infer it from identical text.
What should happen if a retry arrives after the idempotency key expires?
Do not assume the expired key makes the operation safe to repeat. Reconcile against the target system's business reference or route the uncertain request for review. Set retention around the supported retry and recovery window, and document the behavior beyond it.
Can two workers safely process the same operation at once?
They should compete for one execution record through an atomic claim or equivalent concurrency control. The worker that loses the claim should return the recorded or pending outcome. A separate lookup followed by an unprotected write leaves a race.
What if someone changes the amount while reusing the operation ID?
Reject the mismatch against the approved input fingerprint. Treat the changed amount as a new business decision, with a new identity and any required approval. Silently accepting changed inputs defeats the purpose of binding authorization to a specific operation.
Put retry behavior in the integration contract
Before expanding an agent's write permissions, identify one action that would be expensive to duplicate and document its timeout, retry, and reconciliation behavior.
LuMay's AI agent audit-trail guide provides related guidance on connecting authorization to execution evidence. Use both designs together: one prevents avoidable duplicate actions, and the other helps reviewers establish what occurred.
