How the Agent Is Stopped Inventing a Slot or Price

Grounding a voice agent is a latency problem before it is anything else. A spoken turn runs on a budget of about 480 milliseconds, and inside it the agent has to parse the caller, read the practice's live diary, shape a result and begin speaking. The cheapest way to hit that budget is to skip the read and answer from the model alone, which is the definition of an agent that invents a slot.

So the whole design is an exercise in reading real data fast enough that the model is never left to make any up. Get it wrong one way and the agent is slow. Get it wrong the other and it is confidently incorrect, offering a two thirty the diary does not hold or a price the practice never set, and a caller acts on it. An ungrounded model does this by default: it predicts the next plausible token, and a clock time or a dollar figure is trivially plausible.

This is the layer I work on. What follows is the turn budget, how a live read is engineered to fit inside it, and the points where the model is denied any way to state a time or a price it was not handed.

A booking call runs to a fixed clock. The line is answered in about 0.4 seconds, the agent replies in roughly 480 milliseconds a turn, a booking commits in about 0.9 seconds, and an urgent call reaches a person in around 3. Every piece of grounding has to fit inside those numbers, or it is not grounding, it is a slower demo.

Stage of the turn	What happens	Budget
Answer	Picked up on the first ring, no per-line limit	about 0.4s
Understand	Intent, provider, urgency and identity resolved, in 50+ languages	within the turn
Read	The live diary is queried for real openings	within the turn
Reply	The agent speaks the shaped result	about 480 ms
Write	The appointment is committed to the system of record	about 0.9s
Escalate	An urgent call is handed to a person	about 3s

The write is the one number the agent is not allowed to race. A reply at 480 milliseconds is quicker than a commit at 900, so there is a pull to speak the confirmation before the system of record has taken it. It does not. The confirmation is sequenced after the write, because saying an appointment exists is a claim only the practice system can make true, and the mechanics of that are in how write-back works.

A model rushed to fill 480 milliseconds does not turn cautious, it turns confident. A 2024 Nature study on model hallucination calls the failure confabulation: fluent, arbitrary, wrong, and dangerous in medicine precisely because it arrives without a hedge.

Reading a live diary inside the budget

The hard part is the read. Availability lives in the practice system, not in a copy 2care keeps, so every call pays a live query rather than trusting a nightly copy. Run naively, that query is slow enough to break the turn, so it is engineered three ways to stay under it.

It fans out. A practice has many provider and service pairs, and the read fetches them concurrently in batches, eight at a time on a Cliniko connection, so a wide diary returns in a handful of round trips instead of one long serial crawl. The batch size sits under the system's rate limit rather than tripping it into throttling.

It is bounded to what the caller needs. Dentally, for one, rejects an availability window of 24 hours or less and one of 90 days or more, so the read asks for a sensible span, around 14 days at a time, and only walks forward if it has to. A narrower window is a faster answer and a lighter load on a system that is also serving the front desk.

It is deadline-aware. Each hop takes the smaller of its own timeout and the time left in the turn, and a provider that would need a rate-limit wait is skipped rather than allowed to stall the call. A hard ceiling of 12 seconds sits under the whole read as a fail-safe, and a booking write gets 10, but those are outer bounds a healthy call never approaches, not the budget it runs to.

All of it hides behind one interface. The same read contract fronts more than 95 systems, so whether the diary is a dental PMS, an aesthetics platform, or any endpoint speaking FHIR R4, the agent asks the same question and gets the same shaped answer.

What the agent is allowed to say

Once the read returns, the model's freedom is deliberately narrow. It does not compose a time. It relays one the read produced, and copies that slot's exact booking values, provider, location, start, end, timezone and service, into the write. A time it invented would carry none of them, and the write would have nothing valid to send, so it fails closed rather than booking a ghost.

The read hands back a shaped shortlist, not a raw dump. Slots at the same clock time are collapsed so two clinicians free at ten read as one offer, anything inside the next 60 minutes is dropped, and what remains is spread across the parts of the day. At most three survive. A half-stated time, "around three", is matched only within a 90 minute window, so it never lands on a 5:30 the read happened to include, and a past or impossible date, a thirteenth month, comes back as a question rather than a scan. Leaked prompt scaffolding, or the literal None and null some models emit for a blank field, are read as absent, never as a value.

3

real openings offered at once, one per part of the day

60

minutes of lead enforced before any same-day slot

90

minute window a vague 'around three' is matched inside

4

read statuses the agent must act on, none meaning invent

What the caller asks	What an ungrounded model does	What the agent does instead
"Thursday at 2:30?"	Agrees, because 2:30 sounds plausible	Offers only times the read returned, copied exactly
"How much is it?"	Quotes a number in the right range	Reads the price the practice set, or defers it
"Does my plan cover it?"	Names a payer or says yes	Reads the coverage on file, invents no plan
"Anything tonight?"	Finds an opening to be helpful	Returns none, and offers another day

The values behind the guardrail

None of this is a temperament the model was asked to adopt. It is a set of fixed numbers in the tools, each closing one way an answer could drift.

Control	Value	What it stops
Options per offer	3, one per part of day	A wall of near-identical times
Same-day lead	60 minutes	Offering a slot nobody can reach in time
Requested-time match	90 minute window	"Around three" landing on a far-off slot
Answerer temperature	0.1	The model drifting off the clinic's own text
Turn reply	about 480 ms	The pause that tempts a model to fill it
Read, then write	12s and 10s ceilings	A hung call with no honest status

Every value here is checkable. Ask to see any of them, or listen to the behaviour each produces on a live call, rather than taking the number on trust.

Prices and coverage, read not recalled

A price reaches a caller only when the practice has set one in its service list and a read returns it in the moment. The agent keeps no price sheet of its own. When a service has no price, it says the clinic will confirm the cost at the visit, which is true, in place of a figure that merely sounds right.

Anything that is not a booking, what a treatment involves, what to bring, the opening hours, goes to a small fast model pointed only at the clinic's own documents. It runs cold at a temperature of 0.1, is capped near 800 tokens, and is told to keep under three sentences and to name at most three services before it says "and more". It answers from what it was handed, and when the answer is not there it says so rather than reaching for a number. Insurance is the same rule harder: it uses only the plan the record returns, and names no payer, member id or plan that was not, handing anything it cannot ground to a person.

The write refuses a phantom

Grounding the offer is the first line. The write is the second, and it assumes the first will sometimes be wrong. Before anything reaches the practice system, a preflight checks the chosen slot against existing appointments and rejects a clash, so a mangled time cannot overwrite a real booking. The write carries an idempotency key, so a dropped acknowledgement and an automatic retry cannot become two appointments in one slot. A deposit service is re-checked at the moment of writing rather than trusted from the earlier read, because the diary can move in the seconds between the offer and the commit.

The patient data all of this touches is encrypted at rest with AES-256 and carried over TLS 1.2 or better, and every offer and write is logged. That is what makes the path auditable rather than a black box. A wrong answer is a record you can open, not a mood the model was in.

When the honest move is to hand off

Grounding produces a great deal of I do not know, and the system treats that as a clean result. Every read returns one of four statuses the agent must act on: slots found, none found, bad date, deposit required. There is no status that means improvise, so the agent has nowhere to put a guess even if it formed one.

A treatment that needs a deposit taken inside the practice system is the clearest case. The agent names the service, says a team member will finish it, and routes the call, with the transcript and resolved identity already attached, to a person in about 3 seconds, or to a clinical queue in about 4. It forms no clinical view and makes no promise it cannot keep. What a clean handover carries is in what an escalation contains.

Why inventing is blocked in the wiring, not the prompt

The reason 2care can say its agent will not invent a slot is not that we asked it politely. A line in a prompt that says never make up a time counts for little against a model tuned to be helpful at speed. The guarantee comes from leaving the model nothing to invent from: the times it can say are the ones a read just returned, the prices are the ones the service list just held, the plan is the one on file. Take those away and an honest non-answer is what is left.

That is also why 2care can show its working. Every offer traces to a read and every booking to an acknowledged write, so the freelancing a buyer is right to fear is not policed one call at a time. It is designed out of the path.

Where this does not help

Grounding stops the agent inventing. It does not make the practice's data correct, and the limits are worth stating plainly.

If the diary itself is wrong, a slot booked against it is booked wrongly and just as confidently, because reading live faithfully repeats a bad calendar. If prices are missing from the service list, the agent keeps deferring to the visit, which is safe but not the answer the caller wanted, and the fix there is data entry, not a cleverer model.

And a clinic that wants the agent to improvise, to talk a wavering caller into a slot or ballpark a price to keep things moving, will find it deliberately will not. That is the whole design, and it is the wrong tool for anyone who wants a smooth guess over an honest gap.

Frequently asked questions

Does reading live make the call slow?

No. The read is built to finish inside the same turn the reply runs on, about 480 milliseconds, by fanning out provider queries in small concurrent batches and bounding the window to what the caller needs. A 12 second ceiling sits under it only as a fail-safe, not as the speed a healthy call runs at.

Can the agent ever offer a time the practice does not have?

Not on its own. It repeats only openings a live read just returned, and copies each one's booking values rather than composing them. If the diary comes back empty it has nothing to say but to offer another day, so any time it states is one that existed when it read.

How would I verify it does not invent?

Every call can be replayed against deterministic checks over its recorded evidence, so a booking with no matching read behind it is caught rather than trusted. The strongest test is still the two-minute one you can run yourself: ask for a full day, then an unset price.

What does it say when it does not know a price?

It says the clinic will confirm the cost at the visit. A price reaches the caller only when the practice has set one in its service list and a read returns it. The agent keeps no separate price sheet, so there is nothing stale or invented for it to quote.

How does it handle an insurance question?

It reads the coverage recorded on the file and answers from that alone. It will not name a payer, plan or member id that was not returned. A benefits question it cannot ground from the record is passed to a person rather than answered with a guess.

Ask to hear it guess

If you are weighing any voice agent, ours included, run one test before you read a feature list. Ask it for an appointment on a day you know is full, then ask the price of something the clinic has never set. Listen for whether it conjures a time and a number to please you, or tells you the honest thing. It takes two minutes and it sorts products faster than any deck.

Hear a real call try to book a slot that is not there and say so on the platform overview, or book a demo and bring the hardest question you have.