Which attempts belong to one order?
Consider a fictional wholesale workflow. A staff member asks an agent to submit approved purchase order 37. The supplier creates the order, but its response never reaches the internal server. The employee asks again and the worker retries. The model trace may show three tool calls, although the authorized outcome is one supplier order under purchase order 37.
A tool-call ID identifies an attempt. A conversation ID identifies the exchange that prompted it. Both can change in a new session or plan. The server keeps a business operation ID that links the tenant, purchase order, supplier account, and authorized execution. Give order creation and the confirmation email separate IDs. A missing email response should leave the confirmed supplier order intact.
Using the original sentence as the operation key makes paraphrases look like new work. Matching only the JSON has the opposite risk. Two legitimately approved orders may share their items, quantities, and address. A separately approved order should get a new business operation. A change of supplier account or delivery address can conflict with the original. AWS describes recording a caller-supplied identifier with the initial parameters and rejecting a retry that reuses the key with different parameters. AWS on retrying idempotent APIs[1]
Let a trusted server issue the key so a new model plan cannot change the deduplication rule. Idempotency means repeated requests for one logical operation avoid additional business effects. The identifier also gives users a way to look up the result, so that lookup requires authorization. A user who guesses another department’s purchase order number or finds an ID in an earlier tool response must stay inside their tenant and access scope.
When can an approval be reused?
Bind the approval to the supplier account, delivery target, quantity, price, currency, tool, approver, policy version, and expiration. Normalize the approved parameters on the server and compare them at execution. Formatting or JSON key-order changes should resolve consistently, while a change to the address or amount should remain visible. Document how past approvals are checked if normalization rules change.
With the same operation ID and changed parameters, record a conflict before returning an old result. Route any change through the appropriate approval path. If the first operation is still unresolved, establish its external status before allowing a second execution. A created order may need an amendment instead of a new submission. An expired or revoked approval cannot authorize another write. Separately scoped read access can still support reconciliation. OWASP on high-impact agent actions[2]
Keep approval and execution histories. An approval event without a supplier order ID calls for investigation. Where two workers can read the same record at once, enforce the rules at the executor or database. The conversation alone cannot enforce a uniqueness constraint or validate current permissions.
Where internal records and external effects diverge
Use a uniqueness constraint and a conditional state update so only one worker obtains the claim. Writing the operation and the outbound record in one database transaction can prevent accepted work from losing its delivery record. A recoverable outbound record can be delivered more than once, so reuse the original external operation identifier.
Lease expiry cannot establish that the external call stopped. The previous worker may already have submitted the order or lost the connection immediately afterward. A replacement worker should recover ownership and determine the outcome as separate steps. Check the state version or worker identifier so stale responses cannot overwrite newer state. Preserve late evidence of a real supplier success for reconciliation.
An internal state of ‘sending’ can coexist with an existing supplier order. An empty lookup may reflect propagation lag or the wrong account or environment. Check the supplier’s contract and operations documentation to learn when an empty result establishes absence. Include a business reference in the request and preserve the supplier account and test or production environment for reconciliation.
Retry decisions by operation state
The following labels are illustrative. Start from the last confirmed fact and the next fact needed to act.
| Operation state | External write decision | Next step and evidence |
|---|---|---|
| Approval pending or expired | Hold execution | Check the approval history, expiry, and original request |
| Ready and never sent | Claimed worker may proceed | Check current approval, authorization, inputs, and conditional claim |
| Sending or accepted and processing | Restrict overlapping submissions | Check supplier references and set a reconciliation deadline |
| Success confirmed | Return the existing result | Match the supplier order to the internal operation |
| Confirmed failure with no effect | Retry when the contract and approval permit | Keep the same parameters and reference together with proof of rejection |
| Outcome unknown | Look up first and resend only under the contract | Reconcile lookup, webhook, or supplier evidence and escalate if needed |
| Cancellation or correction required | End retries of the original operation | Approve a separately identified corrective operation and verify its result |
Interpret HTTP 500 and network errors using the execution boundary and supplier contract. Stripe documents that API v1 preserves the response after initial execution begins and can return the same 500 for the same key. Reuse after the key has been pruned can create a new request. API v2 has separate behavior. Record the key lifetime, endpoint, parameter conflicts, in-progress behavior, and error meaning for each integration. Stripe’s idempotent request documentation[3]
Internal deduplication alone cannot resolve a lost response from a service that provides no idempotency key. Check separately whether that service supports lookup by a unique reference and whether it enforces uniqueness for the reference. If neither lookup nor independent reconciliation is available, hold automatic resubmission when the outcome is unknown. Provide an operator route to check the supplier, or restrict automation to drafting and requesting confirmation.
Connect transaction states from order to refund — Integrate payment methods with orders and verify delays, retries, cancellations and refunds.
Six failure-injection scenarios
Run these checks against a mock supplier or an approved test environment. Inspect the user interface, the operation database, and the external ledger. The agent’s claim that it placed the order cannot by itself establish the external result. Anthropic on execution traces and outcomes[4]
| Scenario | Failure boundary | Passing evidence |
|---|---|---|
| 1. Lost response | Cut the response just after the supplier persists the order | One external order, with the internal state reconciled to success |
| 2. New conversation and replanning | Request the same purchase order while the model retries its tool call | Multiple attempts point to one operation and one approved order |
| 3. Concurrent workers and recovery | Stop the first worker after the call and let a second claim the expired lease | The second worker looks up the result and creates no new supplier order |
| 4. Changed inputs | Change the quantity or destination under the same operation ID | A conflict is recorded, with no external call |
| 5. Expired approval and late response | Expire the approval while unresolved, then deliver the first success late | New writes are rejected and the confirmed external result is reconciled |
| 6. Expired or unsupported key | Delay lookup visibility and remove the usable idempotency contract | No write immediately follows an empty lookup, and the operator gets a reference and deadline |
For each test, record the external order count, parameter match, user-facing state, escalations, and access violations. Reopen the operation after success to see whether it creates a new job. Requiring a new approval after every lost response hides the unknown outcome. Include a control case with two legitimate orders so an overly broad key cannot silently suppress one.
When reconciliation does not immediately settle the outcome
Compare internal operations with supplier records using identifiers, account, time window, and expected quantity and amount. If one operation matches two supplier orders or could be associated with a different purchase order, put it in exception review with a way to contact the supplier. Record times in a way the on-call team and the comparing software can both interpret.
Expose the age of unresolved operations, owner, confirmed facts, lookup reliability window, and permission to retry. Protect identifiers needed for recovery and avoid unnecessarily copying sensitive response bodies. If a duplicate order exists, check whether cancellation is still possible and whether items have shipped. Approve compensation as a separate operation with its own identifier and reconciliation rule.
See payment and order state consistency for order, payment, and fulfillment records and partial cancellation and refund amounts for ledger comparisons when only part of an order changes. For the agent, test that retries across these systems preserve the business operation and approved scope.
