A retry should not create a second booking

The calendar request times out. The workflow tries again. Two appointments appear.

This is a useful failure to discuss before connecting an AI assistant to anything that changes a customer's records. A timeout tells the caller that it did not receive a usable answer. It does not necessarily tell it whether the other system completed the work.

Give the business action an identity

Suppose a customer asks to book one consultation. Assign that intended action a stable identifier before sending the first request. If the request needs another attempt, reuse the identifier.

AWS describes this approach in Making retries safe with idempotent APIs, published in January 2021. Its contract uses a caller-provided request identifier to recognize repeated intent. It also explains why recording that identifier and performing the associated mutation must be coordinated atomically.

For a booking workflow, the important unit is the requested appointment. It is not the HTTP request, model turn, or webhook delivery. Each of those can happen more than once for the same piece of work.

Do not ask the language model to invent a fresh identifier every time it calls a tool. Generate and retain the action identity in application code.

Distinguish a retry from a changed request

Imagine the first request is for Tuesday at 10am. The customer then asks for Wednesday instead.

That is a change of intent, not a reason to replay Tuesday's action. Give the change its own operation and explicitly reconcile or cancel the earlier booking if necessary.

A useful action record can contain:

• The workspace and customer the action belongs to.
• The stable operation identifier.
• The requested service, calendar, and time.
• A status such as pending, confirmed, failed, or outcome unknown.
• The external booking identifier, when known.

Store enough of the original request to detect an attempt to reuse an identifier with different parameters. An identifier is useful only if its meaning stays stable.

An HTTP method does not solve the whole workflow

RFC 9110, section 9.2.2, published in June 2022, defines HTTP idempotency in terms of the intended effect of repeated identical requests. It cautions against automatically retrying non-idempotent requests without a basis for knowing that this is safe.

Your integration still has to understand the provider's actual contract. A create-booking endpoint might support an idempotency key, a unique client reference, or neither. Verify which protection exists and how long duplicate detection lasts.

A local database transaction cannot atomically include an arbitrary remote calendar API. If the remote system accepts a request and your process crashes before saving its response, you still need a recovery path.

Make uncertainty a real state

When the outcome is unknown, try to retrieve the result using the provider's request reference or another reliable identifier. If you cannot establish whether the booking happened, route it for reconciliation.

Do not immediately tell the customer it failed. Do not claim it succeeded. A useful message says that confirmation is pending and explains how it will arrive.

Separate the booking from downstream side effects. Creating the appointment, updating the CRM, and sending a confirmation are different operations. Retrying a CRM update should not create a new appointment. Retrying a notification should not produce a second confirmation if the first was already accepted.

Test the places where the process can stop

During an integration review, deliberately interrupt the workflow at a few boundaries:

Interruption	Expected recovery
Before the calendar accepts the request	Retry with the original operation identifier
After acceptance, before the response arrives	Find or safely replay the original operation
After confirmation, before the CRM update	Update the CRM without booking again
After a notification is accepted	Reconcile its status before sending another

For each case, inspect the records in both systems. A successful rerun of the workflow is not enough if it leaves duplicate appointments behind.

The acceptance criterion is the customer's intended outcome happening once, with a recoverable explanation when the system cannot yet confirm it.