From LinkedIn · · 1 min
The integration decides whether it happens
The first booking goes through, but the response never arrives. Whether another tool call means another booking is decided between the tool call and the booking API.
By Olha Shevchenko. Audits production systems on AWS and Node.js.
The AI assistant booked one table. The customer got two reservations.
Suppose a restaurant-booking AI assistant is connected to an external reservation service.
The first booking goes through, but the response never arrives. The AI assistant sees a timeout and asks to retry.
The restaurant now expects four people.
The customer is rather conservative. He's bringing just one date.
If I were reviewing this integration, I wouldn't start with the model. I'd look at what happens between the tool call and the booking API.
Who remembers the first attempt? What happens to that information after a timeout? And does another tool call mean another booking?
My first change would be to give each intended booking a persistent operation ID, created before the first API request.
A timeout would leave that operation unresolved, not mark it as failed.
If the model requests another attempt, the integration first finds the existing operation.
If the booking API supports idempotency keys, the integration can send the operation ID as the key and reuse it on a retry, within the provider's supported retention window.
Without that guarantee or another safe way to reconcile the outcome, I'd stop the automatic retry rather than risk booking another table.
I can't control how an external booking service handles requests.
The model can request another attempt. The integration decides whether it happens.