AI Agent Idempotency: Make Ecommerce Retries Safe
A timeout does not tell an agent whether a write failed or whether the response went missing. Give each intended operation one key so an exact retry cannot create the same business action twice.
An AI employee sends a refund request for a damaged item. The request times out before the agent receives a response. If it submits the refund again as a new action, the customer may receive two refunds for one item.
The agent needs a way to say, "This is another attempt at the same approved operation." Idempotency gives the destination that signal. The first successful request changes the business record. Later requests with the same operation key return or confirm that result instead of applying the change again.
A timeout leaves the result unknown
Connected ecommerce work crosses networks and third-party APIs. The destination may complete a refund, inventory adjustment, or fulfillment hold while the response disappears on its way back. From the agent's side, a completed write and a failed write can look identical: no usable response arrived.
Blind retries turn that uncertainty into customer and financial risk. A second refund moves money twice. A repeated inventory decrement creates false scarcity. A duplicate support message makes the brand look careless. Waiting forever also fails because the operator still needs the job completed or escalated.
Separate the business operation from the network attempt. The operation is the approved intent, such as refund one damaged cleanser on order 1048. The agent may make several attempts to complete that one operation. Every attempt must carry the same identity.
Give every state-changing operation one key
Create an operation key before the first write and store it with the job. The record should include the destination, action, order or resource identifier, approved parameters, creation time, and current status. A random unique identifier works, but the surrounding record gives it business meaning.
Reuse that key only when the agent intends to repeat the exact same operation with the exact same parameters. Shopify defines duplicate requests this way in its idempotency guidance. If the refund amount, line item, quantity, or destination changes, the request expresses a new intent and needs a new key after the appropriate review.
Do not assign one key to an entire multi-step job. A support-resolution job might tag a ticket, refund an item, and add a customer note. Those are three writes with different results and retry rules. Give each write its own operation key, then tie all three back to the shared job ID.
Check the original result before creating another attempt
When a response is missing, mark the operation "result unknown" rather than failed. First query the destination using the order, resource, or operation key. If the intended change already exists and matches the approved parameters, record the destination's result and close the operation.
If the destination supports idempotency, retry the same parameters with the same key. Shopify says supported requests execute once even when the caller retries after a disrupted response. AWS recommends the same caller-provided request identifier so a service can recognize duplicate requests and return a result with the same meaning.
Some systems do not accept idempotency keys. Build a local operation ledger and use a destination-side marker when the API allows one, such as an order note, external reference, or metadata field. Before writing, search for the marker and inspect the current business state. This approach reduces duplicates, but it cannot promise the same protection as an atomic idempotent API.
A damaged-item refund with a lost response
Consider a hypothetical skincare store. A customer reports one damaged serum from order 1048. A support agent verifies the photo and policy, then approves a $32 refund for that line item. The AI employee creates operation key refund-1048-serum-1 and stores the amount, currency, line-item ID, reason, and approval.
The refund request reaches Shopify, but the connection closes before the response returns. The operation moves to "result unknown." The AI employee checks the order and finds a matching $32 refund tied to the damaged serum. It records the refund ID, marks the operation complete, and drafts the customer reply. No second refund request is needed.
If the lookup cannot confirm the result, the employee retries with the same operation key and unchanged parameters. A supported idempotent endpoint recognizes the retry as the original operation. If support later decides to refund shipping too, that decision becomes a separate approved operation with a new key. Reusing the serum key with a different amount would hide two business decisions under one identity.
Set boundaries for delayed retries and concurrent work
Idempotency protection may expire. Shopify currently documents a 24-hour tracking window for supported GraphQL idempotency keys. Keep the provider's retention period in your operation record. A job that wakes after the window should verify the destination again and route uncertain cases to a person instead of assuming the old key still protects the write.
Two workers can also attempt the same operation at once. Lock the local operation record while one attempt is in progress, or use a compare-and-set update so only one worker can move it from pending to running. If the destination reports that a request with the same key is already processing, wait and query the result instead of generating a new key.
Set a retry limit and an owner. Temporary connection failures may justify another attempt. Parameter mismatches, validation errors, changed records, and expired protection need review. The goal is one correct business result, backed by enough evidence for the operator to see what happened.
Build one safe retry rule before the agent writes
Start with a consequential action such as a refund or inventory adjustment. Test a lost response and a concurrent attempt before enabling unattended retries.
Where ShopDucky fits
ShopDucky AI employees keep approvals, tool actions, and run history attached to the ecommerce job they are executing. Teams can use operation keys and result checks to make retries safer across connected tools, then route uncertain outcomes to a person. Book a demo to see approval-gated work run across your existing stack.
AI agent idempotency, answered
What does idempotent mean for an AI agent?+
An idempotent agent action can receive the same request more than once without applying the business change more than once. The agent ties every retry of one intended operation to the same identifier.
Is an idempotency key the same as a job ID?+
They can be related, but they answer different questions. A job ID may cover several actions. Each state-changing action should have its own operation key so the system can distinguish a retry from the next intended write.
Should the agent retry every failed request?+
Retry when the operation supports safe deduplication, the inputs have not changed, and the error may be temporary. Route validation errors, parameter conflicts, and uncertain business states to review.
Do idempotency keys replace rollback plans?+
Idempotency prevents one operation from being applied twice. A rollback or compensation plan handles a multi-step job that completed some different operations before another step failed.
