Skip to content

Day 163: Keep One Booking Intent Through Every Retry

The buyer asked for one booking. The agent sent the request, but the acknowledgement never arrived.

Should it try again?

A timeout cannot answer whether the first request failed. Stripe’s current error-handling documentation says that, after a network error, a client may not know whether the server received the request.[1] AWS describes the same distributed-systems dilemma: simply repeating a resource-creation call can create a second resource if the first call succeeded but its response was lost.[2]

That ambiguity turns one commercial intention into a transaction-design problem. If an authorised agent retries, the service must be able to recognise “this is the same booking attempt” without confusing it with “the buyer wants another booking”.

Walk the same intention down two paths

Consider an explicitly fictional equipment-inspection service. No booking system, payment flow, agent or network was tested for this post. We will stipulate that the service’s booking endpoint implements an idempotent request-identifier contract and that the agent is already authorised to request one appointment.

The buyer asks for one inspection at Site A on Tuesday morning. The agent assigns the intention a request identifier, inspection-7F3, and submits it.

Path one: the response is lost

The service receives the request and creates the reservation. Before the acknowledgement reaches the agent, the connection fails.

The agent still has an unknown outcome, not proof of failure. It resends the same booking details with the same identifier. The service recognises the repeated intention and returns the corresponding result rather than creating another reservation.

This is idempotency in plain language: applying the same operation again does not add another side effect beyond the first application. Stripe documents idempotency keys as a way to retry supported API requests without accidentally performing the same operation twice.[3] AWS describes a caller-provided request identifier as a way for a service to distinguish a retry from a new request.[2]

The useful commercial object is not “a retry”. It is the buyer’s single intended commitment, carried across more than one delivery attempt.

Path two: the buyer wants another inspection

Later, the buyer deliberately requests a second inspection at Site B.

That is a new intention. The agent must assign it a new request identifier. Reusing inspection-7F3 with changed booking details should not be treated as a clever deduplication shortcut. Both Stripe and AWS document parameter-mismatch handling when a previously used identifier arrives with different request parameters.[2][3]

The identifier therefore represents transaction identity, not merely similar input. Two identical bookings may be intentional. Two differently worded requests may refer to the same intended booking. The system needs an explicit contract for which is which.

Specify the boundary before commissioning the route

An idempotent endpoint is not a promise of “exactly once everywhere”. Its scope and retention belong to the implementation contract. Stripe says its API can remove keys after they are at least 24 hours old; AWS says retention requirements vary by service and resource.[2][3] A retry outside the supported window may no longer receive the original treatment.

Nor does one protected booking call automatically protect every downstream effect. A reservation, charge, confirmation email and sales follow-up may be produced by different systems. The service design must state which operation the request identifier covers, how related effects are reconciled and what happens when the outcome remains indeterminate. Stripe, for example, warns that some server-error outcomes can remain indeterminate and may require later reconciliation.[1]

For a founder or Marketing Director commissioning an agent-assisted buying route, the acceptance questions are concrete:

  1. What creates the transaction identity: the buyer’s intended booking or each delivery attempt?
  2. Which retries must reuse that identity, with which unchanged parameters?
  3. When does a changed request require a new identity?
  4. How long and within what scope does the service remember the original request?
  5. Which reservation, payment, message and follow-up effects sit outside that protection?
  6. How can an unknown outcome be checked before anyone creates a fresh commitment?

Human approval remains important, but approval alone cannot make repeated delivery technically idempotent. The transaction contract has to preserve what was approved.

Keep discovery and action as different stages

GEO can help a company make a service, its conditions and its buying route intelligible during research. It does not specify the transaction semantics of an authorised action. No evidence here shows that an answer engine rewards idempotent APIs, books this fictional service or guarantees a commercial outcome.

The agentic-workflow lesson begins after the buyer has chosen to act: one intention may require several attempts to obtain a definite response. Design those attempts around the commitment the buyer meant to make.

Retry the delivery when the contract permits it. Do not multiply the booking.

Sources

[1] Stripe Documentation, “Advanced error handling”: https://docs.stripe.com/error-low-level

[2] AWS Builders’ Library, “Making retries safe with idempotent APIs”: https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/

[3] Stripe API Reference, “Idempotent requests”: https://docs.stripe.com/api/idempotent_requests