The Kasper team3 min read
The worst thing a phone agent can do is not misunderstand you. It is to understand you, tell you it has done the thing, and not do it.
That failure has a particular texture. The caller hangs up satisfied. Nobody opens a ticket, because from the caller's side nothing went wrong. The problem surfaces days later, when the appointment does not exist, and by then the only record is a transcript in which your own system says it handled everything.
We designed around that specific failure, and the design has one rule underneath it: an agent may only claim to have done something it actually did.
Unavailable is a state, not an absence
An agent is offered a set of tools — create a ticket, look up a caller, transfer to a human, send a message. Each tool belongs to a subsystem, and subsystems get built at different times.
The tempting shortcut is a stub: a function shaped like the real one that returns success and does nothing. It keeps the demo working. It also means the model is told, truthfully as far as it knows, that the ticket was created.
Kasper does not allow that. A tool whose subsystem does not exist is registered as unavailable, and if it is somehow called anyway it returns tool_unavailable rather than a fabricated success. The agent then has to say something true — that it cannot do this right now — which is a worse conversation and a better outcome.
This is not a convention we ask developers to follow. It is a prohibition in the product specification, and the catalogue that lists tools has no way to express "pretend".
A tool that fails says so, in words
Tenants can define their own HTTP tools: a URL, a method, an auth header, a schema for the inputs. Those calls fail the way all network calls fail — timeouts, bad gateways, a schema that no longer matches.
When one does, the agent receives a structured error, not an empty result. The difference matters more than it sounds. An empty result invites the model to fill the silence; it has a conversation to continue and nothing to continue it with, and a plausible sentence is easier to produce than an admission. A structured error gives it something specific to report, so what the caller hears is that the lookup did not come back — not an invented balance.
The tools themselves are fenced in for the ordinary reasons: HTTPS only, private address ranges blocked and re-checked after DNS resolution so that a hostname cannot resolve inward, a ten-second ceiling, a response size limit, rate limits per tenant. None of that is interesting until the day it is the only thing standing between a misconfigured tool and your internal network.
The sandbox records what it would have sent
Demo workspaces and testers get a different treatment again. Outbound effects — WhatsApp, email, SMS, payment links, custom tools — are simulated: the system records what would have been sent and returns success without contacting the provider. The conversation is marked as sandboxed, and its usage is metered separately and never billed.
The point is that a test call behaves like a real one everywhere except at the boundary where it would touch somebody outside. You can rehearse the whole flow, and nobody gets a text message at two in the morning because a colleague was trying something.
Why we would rather disappoint you
There is a version of this product that demos better. It has no unavailable tools, no structured errors surfacing in conversation, and no moment where the agent says it cannot help with that yet. Every one of those absences is achieved the same way: by saying yes when the answer is no.
We think the trade is obvious in one direction and invisible in the other. A caller who is told the system cannot book that today will call back, or ask for a person, or wait. A caller who is told it is booked will arrive.
If you are evaluating voice agents, the useful question is not what happens when everything works. It is what the thing says when a tool times out — and whether you can tell from the transcript that it did.