Two agents need one durable purchase intention

Two workers receive the same approved buying task. One starts the purchase and pauses before recording its result. The other takes over, sees no completed purchase and submits another request. Both workers may have followed their local instructions while the business receives two orders.

The system needs a durable identity for the customer's purchase intention across workers. It also needs to protect the transition from that shared record to an external merchant or payment provider. Assigning a new request key to each worker defeats that purpose.

Give the purchase an identity before assigning work

In this fictional case, a customer authorizes one specified desk lamp from one merchant under agreed price and delivery conditions. The purchase-intent record identifies that approved action. Worker A and worker B are attempts to carry it out, not two separate customer purchases.

Preserve the approved terms and parameter version with the intent. A changed quantity, merchant or total may require a new customer decision; it should not be hidden inside a retry. The permission-to-buy article explains that authority boundary. Recognizing a worker's identity does not establish current authority to spend.

AWS's idempotency guidance describes using caller-provided identifiers to distinguish repeated work and checking that repeated parameters remain consistent. Its internal atomic handling of an intent record and a mutation is not a guarantee of atomicity across an external merchant and payment provider. AWS: making retries safe with idempotent APIs

Trace two workers through the same record

The following timeline is a proposed design exercise. It is not a statement that a particular agent platform already implements these controls.

The important record is the business operation, not just a queue message. Two different delivery messages can refer to the same purchase, and one message can be delivered repeatedly.

A lease has a boundary

A lease can help select the current worker, but a paused worker may resume after its lease expires. AWS's leader-election discussion explains why timing and failure behavior require care; holding a lease does not establish that old work has ceased everywhere. AWS: leader election in distributed systems

Use conditional state transitions and, where the receiving resource enforces it, an execution generation or fencing mechanism to reject stale ownership. State exactly which resource performs that check. A local fencing token that the external provider never receives or validates cannot prevent that provider from processing a stale request.

At the external boundary, use the provider's supported duplicate-handling contract for the same logical operation. Keep the key, account, endpoint, version and parameters durable before submission. A lease and a provider key address different failure boundaries; neither alone proves one complete customer purchase across all systems.

Distinguish an in-flight conflict from a saved result

For Stripe API v1, an executing concurrent request can cause a same-key conflict without saving a new idempotent result. After execution begins, the first request's response is saved for replay, including a 500; the retained key can later be pruned. API v2 has different retry behavior. These are version-specific rules, not a universal payment contract. Stripe idempotent requests

A second worker must not interpret conflict or a missing local response as permission to mint a fresh key. It should consult the durable purchase state and use the documented same-operation recovery path. An expired retention window also does not resolve an uncertain external result. The payment idempotency guide covers that provider contract in more detail.

Test the handover at the dangerous moments

Pause A after external submission but before the local result is durable. Let B take recovery ownership, then resume A. Check the actual merchant and provider records, the shared purchase history and the customer message. A test that inspects only the final local row could miss an external duplicate.

Also test simultaneous claims, the same intent delivered under different queue-message IDs, changed parameters, an in-flight provider conflict and recovery after the provider's retention boundary. Preserve an unresolved state when inquiry cannot establish the outcome. Do not switch provider or create another order simply to get a cleaner local status.

Once the original purchase is evidenced, the recovery path should lead to reporting and fulfillment under the appropriate policy. It should not loop back through purchase submission. The customer's instruction was to buy one lamp; adding more workers should not change that instruction.

The lamp purchase and worker timeline are illustrative. Primary technical sources were checked on 25 October 2026; this article makes no end-to-end exactly-once guarantee.