Your Voice Agent Needs Three Exits, Not One

Most voice agent demos optimise the happy path. Caller asks for a booking, agent books it, everyone claps. I have shipped these into hospitals, vet clinics, garages and brokerages, and the happy path is not where they live or die. They die on the calls that fall off the edge of the script. An agent that handles ninety percent of calls and drops the other ten is not a ninety percent success. The ten it drops are the calls that mattered most: the emergency, the angry customer, the deal that was ready to close. The business judges the whole system on those, and they are right to. If you write software you already know this shape. It is error handling. We all know the error paths are the real product surface and we all still write them last. Voice agents punish you faster, because the failure is audible and a human is listening to it live. Three exits, not one "Transfer to a human" gets treated as a single feature, one boolean in a config. In production it is three different code paths, and conflating them is what makes an agent feel broken. Exit one: transfer the live call. The caller stays on the line and a person picks up. Right when the situation is urgent, when the caller has already been through one loop of misunderstanding, or when the business loses real money by making this person call back. It is also the exit with the most ways to fail, because it depends on a specific human being available this second. Exit two: take a structured message and escalate. The agent captures the details properly, ends the call cleanly, and fires an alert into whatever the team actually watches. This is the correct exit far more often than clients expect, especially outside business hours, and it is the one that gets skipped. Exit three: refuse and route. The agent declines the topic entirely, says so plainly, and points at the right channel. For a medical practice that is clinical advice. For a brokerage it is anything touching price negotiation or fair housing. The agent does not need a graceful answer here. It needs a firm one. Once you have three exits you stop trying to build an agent that always knows the answer, which is a losing game, and start building one that always knows where the call goes next. Much smaller problem, and actually solvable. I write the exit conditions before the script My first question to a client is never what the agent should say. It is: which calls, if this thing handles them badly, would make you turn it off tomorrow? The answers come back short and specific, and they are the escalation spec: - The vet clinic said any caller describing a collapsed, bleeding or poisoned animal. No triage, no questions, straight to a person. - The garage said anyone stranded on a roadside. Whatever they were calling about becomes irrelevant, because a person standing by a motorway is a different kind of caller. - The medical clinic said anything that reads as symptoms or advice. Not the agent's job at any confidence level. - The brokerage said any caller mentioning a competing offer. Speed to a human is the entire value of that call. Those go into the flow as first-class exits before I write a line of the booking path. Same instinct as writing the throw sites before the function body. It also changes what the client tells you. "Handle our calls" is not a spec. "Never let a stranded driver sit through a booking script" is, and it is testable. The trigger set that actually catches escalations Escalations fire from four sources. An agent that implements only one will miss calls. Content triggers. The caller says something on the list. Emergency words, legal words, cancellation words, a competitor's name. Easy to specify, so most implementations stop here. Explicit request. The caller asks for a human. Non negotiable, and I wire it at every node in the flow. An agent that keeps steering someone back into the script after they asked for a person is the fastest way to make a caller hate a business. If they ask twice, it should already have happened. Repair-loop triggers. The agent has failed to understand the same thing twice, or the caller has repeated themselves, or the call has run well past the length this kind of call should take. Nothing hit a keyword. The conversation is just going badly, and the agent should detect that from structure alone. This is the trigger everyone forgets and it catches the most calls. Sentiment triggers. The caller is audibly frustrated. Worth having, worth keeping conservative. A false positive means a human takes a call they did not strictly need, which is cheap next to the alternative. What the handoff has to carry A transfer that drops a confused human into a live call with no context is barely better than a dropped call. The person picking up starts by asking the caller to repeat everything, which is exactly what the business paid to avoid. So every handoff carries a payload: who is calling and their callback number, why they called in the agent's own words, what has already been established, and what triggered the escalation. Where the receiving team lives in a CRM, that lands as a note on the contact before the phone rings. The agent stays thin, the systems behind it stay smart. The callback number matters most. Get it early, confirm it, and treat it as the one field the agent is genuinely patient about collecting. If the transfer fails, that number is the only thing standing between the business and a lost lead. This is also the warm versus cold decision. Cold transfer is fine for high volume routing where the destination already knows what it is for, like someone who just wants the parts desk. If making the caller repeat their story would damage the relationship, brief the receiver first and transfer warm. Nobody picks up, which is the normal case Here is the part that gets built last and breaks first. Transfer is a request, not a guarantee. It is a network call to a human and it can time out. The line is busy, it is 7pm, someone is on holiday. If the plan was "transfer to a human" and nobody answers, the caller gets silence or a voicemail beep, and the system has failed at the one call it existed to protect. What I build instead is a ladder with a terminating case: - Try the primary destination with a short ring window, not a long one. A caller listening to ringing is spending patience they arrived with. - Try the fallback if there is one. On-call phone, second location, an owner's mobile after hours. - If nobody picks up, the agent comes back on the line and says so honestly. Not "please hold" again. Closer to what a person would say: everyone is with a customer, here is when someone will call you back. - Capture callback details, confirm the timeframe, end the call cleanly. - Fire the escalation into whatever the team actually watches. The agent does the talking, n8n does the alerting, the SMS, the ticket and the follow-up. Step three is the one clients push back on and it is the one that saves them. An agent that admits nobody is available and commits to a callback keeps the lead. An agent that keeps trying to transfer loses it. Ring time and lookup time are both spent by the caller, so your latency budget applies to the handoff too. Speak before the silence, not after it. Why I treat this as a safety problem Most of my thinking about escalation did not come from voice AI. It came from years of building systems where a confident wrong answer was the worst possible output. In clinical eye-tracking work, the headset could produce a number for every session, but the honest system was the one that could say the capture was not good enough and hand the judgement back to a clinician. In public safety XR, an overlay showing stale data with full confidence was more dangerous than one admitting it had lost tracking. A voice agent is the same class of system. It will be wrong sometimes, and the question is never how to prevent that entirely. It is what the system does at the edge of its own competence. A well built handoff is the strongest signal that an agent was built by someone who has run one in production. The short version - Build three exits: transfer live, take a message and escalate, refuse and route. - Write the exit conditions first, starting from "which calls would make you turn this off". - Trigger on content, on explicit request at any point, on repair loops, and conservatively on sentiment. - Carry context into the handoff, and get the callback number early. - Plan for nobody picking up, and end that path with an honest promise instead of a hold. The longer version, with more of the client-by-client escalation specs, is on my site. Top comments (0)