Ask for an AI assistant and the specification you get back will describe what it can do. Answer questions. Take bookings. Draft replies. Look things up.
The specification that matters describes when it stops.
Every AI system we have shipped and would defend is defined more by its exits than by its capabilities. Not because the models are weak — they are not — but because a system that can act on your behalf and has no designed way to stop is a system whose worst day is unbounded. And the worst day is the one that decides whether you keep it.
This is also the part customers notice. Nobody minds that a bot could not answer. Everyone minds a bot that would not let them past.
The exit is a product decision, not a fallback
The word "fallback" is the problem. It frames the handoff as what happens when the real feature fails, which puts it last in the design and last in the budget.
Invert it. The handoff is the feature that makes everything else safe to deploy. It is what lets you put a language model in front of customers without betting the relationship on its worst output.
Specify it first and the rest of the system gets easier to scope, because you now know what the machine has to be right about and what it merely has to recognize.
Six patterns, and where each belongs
These are the handoffs in systems we actually run. They are different mechanisms for different risks, and most real deployments use several.
1. On request, immediately and without argument
The simplest and least negotiable. A person asks for a person and gets one. No retention loop, no "let me try once more", no hidden escape hatch.
Bronjoy's help bot escalates on request, and the command is a plain one. The temptation to make this harder is exactly the temptation that produces the support experiences everyone hates, and it is usually created by measuring deflection rate — a metric that cannot tell a resolved customer from a defeated one. We argue that through in the deflection arithmetic.
2. On repeated failure
The same bot escalates after repeated unhelpful answers and on error.
This matters because customers do not always ask for a human. Many will rephrase the same question three times and then leave, and that silent departure is invisible in your metrics. Counting consecutive unresolved turns and escalating on the third converts a silent loss into a handled case.
3. By category, before the conversation starts
Some subjects should never be answered autonomously, regardless of confidence.
On the same bot, billing and account replies are held for human approval. Not because the model gets them wrong more often, but because being wrong about them is expensive and hard to walk back. Category-based holding is cheap to implement and removes a whole class of risk without touching the rest of the experience.
4. Anything that commits money, always
Nomadeo — an AI sales agent working in Russian, Uzbek and Kazakh over WhatsApp and Telegram — runs the strictest version of this rule: anything that commits the business to money, a price, a discount or a deadline, stops and waits for a person to confirm.
It also shows what the surrounding machinery looks like when the stakes are real. Nine guardrails run on every draft before it is sent: grounding, discount authority, forbidden claims, prompt injection, personal data, stale facts, night mode, rate limits and budget. A blocked draft is recomposed or handed to a person. Facts extracted from a conversation are risk-tiered and reconciled — low-risk ones confirm automatically, high-risk ones go to a decision queue with undo.
The undo is worth noticing. Handoff is not only about stopping before an action; it is about being able to reverse one.
5. Pause mid-run for approval, then resume
A subtler pattern, and the most useful one for internal tools.
Knigopoisk has an admin assistant with tools across orders, products, content, media, users and statistics. When the model proposes an action that needs sign-off, the run pauses, the proposal is recorded, and the agent resumes only after an admin approves or rejects it — leaving an audit trail.
This is better than either extreme. Fully autonomous is unsafe for an assistant that can change orders. Fully manual means the human does all the work anyway. Pausing means the machine does the thinking and the assembly, and a person does the deciding, with a record of both.
6. Admit insufficient evidence
The most disciplined pattern, and the one most systems skip.
Testify audits recorded calls for regulatory compliance. A requirement passes only with a verbatim, timestamped quote. If the evidence is not there, the result is not a guess with a low confidence score — it is "insufficient evidence", and it goes to human review.
The same principle runs through two other things we built. Legible, which produces accessibility remediation for documents, leaves unreadable values null and flagged, on the stated ground that a confident wrong value is worse than no value at all. RecipeReel leaves a quantity blank rather than guessing when the amount is neither spoken nor on screen.
"I do not know" is a handoff. Systems that cannot produce it will produce something else instead, and that something else is what you will be explaining to a customer.
The claim guard: catching the handoff that did not happen
There is a failure mode that none of the six patterns catches, and it is the one that worried us most when we built a voice agent.
A model can say it did something it did not do. It can tell a customer their appointment is confirmed when the booking tool returned an error. Every guardrail above governs actions; none of them governs sentences.
So the Bronjoy AI receptionist has a claim guard: every sentence claiming a booking, a cancellation or a reschedule is checked against the tool calls that actually succeeded. Unmatched claims become a confirmation question and are logged.
The architecture around it is built on the same mistrust. No tool accepts a price. hold_slot returns a hold token that book_appointment requires, so there is no path to a confirmed booking that skips the reservation.
And the honest limits, since this is the kind of claim that should come with them: that receptionist works end to end as a browser demo only. In production it sits behind a VOICE_ENABLED flag that is off, and there is no telephony leg and no phone number. The demo is capped at 30 turns or 10 minutes per session and 20 sessions per IP per hour.
What to specify before you build
Take this list into the scoping conversation. Every line is a decision someone has to make, and making it late is what produces the incidents.
- What can this system do without a person? An explicit list, not a boundary described in adjectives.
- What can it never do? Money, legal commitments, anything irreversible, anything about a person's account.
- What triggers a handoff? Request, repeated failure, category, low evidence, guardrail block, error.
- Where does a handoff go, and who watches it? A queue nobody opens is not an escalation path.
- What does the customer see at handoff? They should be told plainly, with an expectation of when.
- What does the human receive? The full conversation, what was attempted, what failed. A handoff that arrives as "customer needs help" wastes the automation entirely.
- What is logged? Every blocked draft, every unmatched claim, every escalation. This is how you find out what to fix.
- What happens out of hours? Nomadeo has a night-mode guardrail for exactly this. An escalation at 2 a.m. with nobody to receive it needs a different answer from one at 2 p.m.
Item 6 is the one most often botched. The value of a handoff is the context that arrives with it.
Why this makes the system better, not weaker
There is a worry that designing exits produces a timid assistant that hands off constantly.
The opposite happens. A system with well-defined exits can be more capable inside its boundary, because the consequences of being wrong are bounded. It is the systems with no exits that have to be kept vague and cautious everywhere, because any error can become anything.
Nomadeo is the clearest demonstration: nine guardrails, a decision queue, mandatory confirmation on money — and within those limits it negotiates, handles objections and closes, showing the sales manager the tactic it chose, the sources it used and the checks it passed. The constraints are what make that level of autonomy defensible.
Our AI integration and automation work starts at $299 and runs one to three weeks, and human handoff fallback is named in the deliverables rather than assumed. It is the first thing we scope, not the last.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Does a visible "talk to a human" button undermine the automation?
No, and the data you get from it is valuable — the rate at which people press it tells you exactly where the system is failing. What undermines automation is hiding the button, because the customers you trap do not become resolved, they become former customers.
What if we do not have staff to receive escalations?
Then scope the automation to what it can complete alone, and make the fallback a form or a message that promises a reply within a stated time. That is honest. What is not honest is an assistant implying a person is available when nobody is.
How do we stop it from escalating everything?
Measure the reasons, not just the rate. If escalations cluster on one intent, that intent needs better source material — usually documentation, not a better model. Escalation logs are the highest-value feedback an AI deployment produces, and most teams never read them.
Is a confidence score enough to decide when to hand off?
Not on its own. Self-reported confidence is poorly correlated with correctness, and it degrades in exactly the situations you care about. Prefer structural signals: did a tool call succeed, is there a verbatim quote supporting the claim, is this category on the hold list. Testify's "insufficient evidence" is a structural test, not a numeric one, and that is why it is trustworthy.
Should the customer know they are talking to a machine?
Yes, and say it at the start rather than letting them work it out. It sets expectations correctly, it avoids the sharp resentment that follows discovering a deception, and in a growing number of jurisdictions it is becoming a requirement rather than a courtesy.
