Keeping the AI out of the critical section and handing a structured request to a deterministic sub-workflow is the part I would copy first. For the calendar case there is a native idempotency key that fits step 2. Google Calendar's events.insert accepts an event id supplied by the client, and a second insert with the same id is rejected with a 409 instead of creating a copy. The id has format rules (lowercase letters a to v and digits 0 to 9, at least 5 characters), so the booking request ID hashed and encoded as lowercase base32hex fits. A retried or doubled tool call then becomes a conflict the workflow can treat as already booked, whether or not the pending row was written. It does not replace the re-check in step 3, because someone booking the same slot by hand gets a different id. But it does close the timeout case where the first insert succeeded and only the response was lost.