AI Scheduling-Assistant Tool-Disambiguation and Stale-Offer Integrity Automation: A "Yes" That Would Have Booked the Wrong Time

A single request to an AI tool either succeeds or fails, visibly, in that one exchange. A multi-turn conversation — propose a time, wait for a person to agree, then actually book it — depends on the assistant correctly remembering what it said and what is still true across that gap, and nothing about a fluent-sounding response confirms that memory is accurate. A model choosing the wrong one of two similarly-purposed tools, or asserting a time it never checked, produces output that reads exactly as confidently as the correct version would — the failure is invisible in the moment and only becomes obvious when the wrong meeting gets cancelled, or the wrong time gets booked.

Both fixes came out of real, dated live-testing sessions run against a genuine internal account on the same day, each one surfacing a different way a multi-turn scheduling conversation could silently go wrong.

The first: two tools exist for cancelling something on the calendar. One is general-purpose — it cancels any calendar entry at all, given that entry's own identifier, and is meant to be called twice in a row as its own confirmation step: once to summarize what will be cancelled, and again with the identical identifier to actually confirm it. The other is narrower and specific to a client meeting that was booked with an actual Google Calendar invitation sent to that client. During testing, the model correctly identified and began cancelling something with the general-purpose tool — the first, summarizing call went to the right place — but on the SECOND call, meant only to confirm the identical action, the model switched to the OTHER, client-meeting-specific tool instead. Nothing in either tool's own description explicitly said "don't switch mid-confirmation," because nobody had anticipated a model doing so mid-flow rather than at the very start. The fix rewrites both tools' own descriptions to state plainly, in each one, exactly which situation it covers and to explicitly instruct against switching tools between the first and second call of the same two-step confirmation.

The second, separate finding: the assistant proposed a specific meeting time, that proposal genuinely lost to a real scheduling conflict, and the system correctly refused to create a confirmable record for a time that didn't actually work. What happened next is where the real gap was — the assistant, with no record of what remained genuinely on offer, announced an entirely different time to the person it was talking to, by plain conversational text, never through the tool that actually creates a checkable, "on the record" proposal. Had that person simply replied "sure," the assistant would have gone on to confirm whatever the last REAL, tool-created proposal had been — which was neither the rejected time NOR the time just announced by text, because that second time had never actually been proposed as far as the system itself was concerned. The fix makes a rejected proposal return, alongside its rejection, whatever offer is still genuinely live for that same person and conversation — so the assistant is told directly what remains valid rather than being left to invent or half-remember a next step. Both affected tools' own descriptions were also updated to state explicitly that a rejection on the exact same action a person already agreed to is not a failure to explain apologetically — it is the system correctly asking for the confirmation it hasn't received yet.

The assistant proposes 9:00 for a meeting; the slot turns out to be genuinely taken, so no bookable proposal is created for 9:00. The assistant tells the person "let's do 4pm instead" — in plain text, without actually proposing 4pm through the tool that would make it real. The person replies "sounds good." Before the fix, that reply would have confirmed 9:00 — the last REAL proposal on record — a time the person had already been told was unavailable. After the fix, the assistant is handed the live offer directly and either presents it accurately or proposes a genuinely new time before ever announcing one.

Centriu's internal AI scheduling assistant now tracks which specific proposal is genuinely still valid through a rejected offer, and consistently uses the correct one of two similarly-named cancellation tools across a full multi-step confirmation — closing two distinct, real ways a scheduling conversation could end in the wrong outcome while still reading as a normal, successful exchange.

This page covers the assistant's own internal conversational-state handling for proposing and cancelling calendar entries — it does not change the underlying calendar-conflict detection itself, which already correctly identified the conflict in both cases described here; the fix is entirely about what happens with that correct detection afterward.

An AI assistant picking a plausible-sounding tool, or stating a time in fluent conversational language, produces output that is indistinguishable in tone from a correct response — confidence is not evidence of accuracy. Centriu's fix closes the specific gap between "sounds right" and "is actually on record" by making the system hand the assistant the genuinely live offer directly, and by making two similarly-purposed tools state their own boundaries explicitly rather than leaving a model to infer them mid-conversation.