What stops the AI from promising an appointment time that does not exist?

The rule: never say a time the system did not return

A language model asked about Tuesday afternoon will happily produce a plausible answer, because producing plausible answers is what it does. The defense is not a stern instruction in the prompt. It is removing the model's ability to answer at all. Availability comes from a tool call. If the tool call returns nothing, the agent has nothing to say about availability.

Written as a hard constraint: the set of times the agent may speak is exactly the set of times the scheduling API returned in the last few seconds. That is enforceable in code, and prompt instructions are not.

Two-phase booking closes the race

Between the moment the agent offers a slot and the moment the caller says yes, ten or twenty seconds pass. In a busy dispatch board that is enough time for a CSR or another caller to take the slot. The result is a customer who was told three o'clock and finds nothing on the schedule.

The fix is to reserve first and confirm second. Place a short-lived hold when you offer, release it if the caller declines or the call drops, convert it to a real job when they accept. Not every scheduling system exposes a hold primitive, so sometimes it has to be built in the integration layer against ServiceTitan, Jobber or whatever the dispatch board actually is.

Availability is not the same as capacity

An empty box on the calendar is not permission to book. Real capacity depends on skill (not every tech can do the job), zone (the truck cannot be in two suburbs at once), parts, membership priority, and whatever the dispatcher knows that is not in any field.

This is where naive booking automations do the most damage. They fill the schedule technically and destroy it operationally, and dispatch spends the morning undoing it. The honest scorecard for an automated booking system is the share of its bookings that dispatch later moved. If that number is high, the agent is doing harm even when every appointment technically existed.

Choose the narrow slice first

• Start with job types that have fixed duration and no skill routing. Tune-ups and standard maintenance, not diagnostics on a system nobody has seen.
• Give the agent a bounded window. Offering only the next few days limits how wrong a bad hold can be.
• Reserve buffer. Let the agent book into a defined share of the board and leave the rest under human control.
• Instrument reschedules by booking source. That single report tells you whether to widen or pull back.

Widening scope should be a decision backed by that report. Doing it because the first two weeks felt fine is how these projects lose the dispatcher's trust, and once dispatch stops trusting the automation they will route around it. More on that pattern in operational AI.