Here's what Daniel wrote in this week. He had to call his ISP to whitelist a third-party modem. You give them a serial number, they put it on the list, done. Uncommon procedure. Documented, though. The ISP knows it exists, a slice of their customers will need it, and it is on a page somewhere on their site.
He gets the voice agent. And the agent has decided, before he says a word, that his internet is down. Check the light on the modem. What color is it. Unplug the cable, plug it back in. Wait through the reboot pauses. Daniel tells it, plainly, this has nothing to do with why I'm calling, I know why there's no internet, I have one thing to give your staff and one procedure to follow. The bot comes back with "I understand, but we need to go through these diagnostic steps first." Which is not understanding. That's a comprehension token. It parrots the shape of listening without doing any of it.
And then the good part.
Then he says "speak to a human" in Hebrew, hoping there's a bypass gate buried in the flow. Nothing. The diagnostic keeps rolling, mandatory pauses included, while the bot assumes he's rebooting a modem he is nowhere near. He's miles from home, sitting with a coffee, inventing answers to a troubleshooting script he isn't following, just to get to a person at the end of it.
And here's the detail that makes it worse. He's not even at the modem. So when the bot asks him what color the light is, he has to make something up. He's fabricating data to feed a diagnostic he doesn't need, because the only way out of the flow is through it.
He's lying to a machine to get past it. That's the experience the ISP designed.
And the machine can't tell he's lying, because it isn't checking. It's not verifying the light color against anything. It's just collecting the answer and moving to the next step. The whole diagnostic is theater at that point.
And the question he's actually asking is two-sided. Companies don't want a world where everyone reflexively says put me through to a human the second they hear a synthetic voice, because some of those calls the agent could resolve. Fair enough. But they also can't ship a system that handles exactly one triage workflow and calls everything else noise. So what do you bake in? What design principles stop this?
Two things before we go anywhere. This is a failure-pattern episode, not a phone-tree rant. The failure is the lesson.
And the lesson is expensive. Let's name the pattern first, then get into why it happens.
The name is a single-intent state machine. The agent's dialog state holds one active task, and that task is troubleshoot connectivity. When a second, different intent arrives, the state machine has nowhere to put it. It can't hold two.
So the model might have heard him perfectly.
That's the part people get wrong. Dilr.ai's multi-intent work draws the line cleanly. A model that misses the second intent has a comprehension failure. A model that hears both intents and silently discards one, because its state machine holds a single active task, has an architectural failure. In production the second one is far more common, and no amount of prompt tuning fixes it. You can rewrite the system prompt for a month. The state machine still holds one task.
Which reframes Daniel's whole call. He wasn't talking to a bot that was too dumb to understand him. He was talking to a bot that may have understood him fine and had no slot to file it in.
And that's why it feels so strange on the phone. This is what Phony.ai calls the quiet failure. Nothing sounds wrong. The agent is answering fluently and answering the wrong question, because the caller's situation is outside what it knows and nothing in the conversation marks that. It feels like a successful call from every angle except the caller's.
Every angle except the one person on the line.
Which is exactly why it survives review. If the bot had crashed, someone would have fixed it in a week. A bot that says "I understand, but" in a warm voice and keeps going looks like a working system on a dashboard.
Sixty-one percent of customers say IVR systems contribute to a poor experience. That's TTEC Digital's number. And each additional automated turn raises the risk of the caller dropping off by seven percent. Daniel's call was, what, eight turns deep before a human picked up? Nine?
He was past the point where most people hang up. He stayed because he had a specific thing to accomplish and no other channel to do it in.
Let's put a number on that. If each turn adds seven percent drop-off risk, then by turn eight you've stacked the odds against yourself pretty badly. The math compounds. It's not seven percent total. It's seven percent per turn, multiplying.
Which means a ten-turn call has maybe half the callers still on the line. And the ones who stay are the ones with the highest motivation and, often, the highest frustration.
So the system is selecting for the angriest remaining customers by the time it finally connects them to a human.
That's a brutal design outcome. The people who reach your agents are the ones who wanted it most and waited longest.
So we have the vocabulary. Single-intent state machine. Quiet failure. Now the mechanism. Why does the bot fail to recognize what he actually wants, and why doesn't the escape hatch fire?
Start with what the bot was trained on. The overwhelming majority of calls to an ISP about internet are people whose internet is down and who don't know why. That's the distribution. The classifier is built around that distribution, and the diagnostic flow is built around the classifier. Modem whitelisting by serial number is documented, the ISP expects it, and it is rare enough that it's a rounding error in the training data.
So the intent has no representation.
It has no representation, and when Daniel says "I know why there's no internet, I have one simple thing to provide your staff," the classifier either doesn't fire at all or fires on the nearest thing it has, which is internet problem. And then you get the false acknowledgment. "I understand, but we need to go through these diagnostic steps first."
It's the bot equivalent of nodding while checking your phone.
It parrots back a comprehension token without acting on the caller's turn. TTEC Digital describes the same dynamic from the other end. A bot that opens with "how can I help you?" but can only understand a few pre-programmed keywords. The greeting promises a conversation the system can't have.
The greeting is the lie. That's where the frustration actually starts.
And here's the architectural piece, because this is the one that matters for anyone building. Even if the model hears Daniel's second intent, the state machine can't accept it. Picture a train station with one platform. The train on the platform is the diagnostic flow. A second train arrives and there is nowhere to route it, so it just sits there, or it gets shunted off the board entirely.
And the caller can see the second train. The system can't.
That's the asymmetry that produces the anger. The human is holding two intents. The machine is holding one, and it will not be told otherwise.
So that's intent recognition. Now the escape hatch. "Speak to a human" in Hebrew. Nothing.
Keyword matching is language-dependent by construction. The trigger list is almost certainly English-only, and even inside English it's usually a small set of canonical phrases. Getmacha's writeup on handoff failure says intent matching that only covers the canonical phrase is the single most common cause of the handoff not firing.
So the bot wasn't ignoring him. It was pattern-matching against a list that didn't contain his words, in a language the list didn't cover.
And the fix is architectural, not lexical. You don't add Hebrew phrases to the keyword list. You make escalation phrase-independent instead of keyword-matched, and you add an always-visible control that doesn't depend on parsing at all. Salesforce does this at the topic-classifier layer in Agentforce, so the escalation can't get swallowed by the internal logic of the flow.
Which is the real problem. The escape hatch is inside the thing you're trying to escape.
That's the sentence. The escalation path runs through the state machine, so if the state machine is the thing that's broken, the exit is broken too.
And the escape hatch is the most-tested feature in the whole product. Every voice agent spec has an escalation section. It works in the demo. It fails in the two situations that actually generate complaints. Phony.ai puts it this way. An agent that only stops when told to stop is an agent that will not stop when it most needs to.
The two situations are the caller whose situation is outside what the agent knows, and the caller who is already frustrated. Those are the two moments the handoff has to work, and they're the two moments it's least likely to.
Why does it fail in the demo but not in production? What's different?
In the demo, the tester knows the canonical phrase. They say "agent" or "representative" or "human" in clean English with no background noise. Production is messy. Accents, background noise, people who say "get me a person" or "I need to talk to someone real" or, in Daniel's case, a different language entirely.
The demo tests the happy path of the escape hatch. Production tests everything else.
And the escape hatch is the one feature where the happy path is the only path that matters, because the people using it are already outside the happy path.
Which brings up the uncomfortable version of this. eesel's analysis says handoff failure is often deliberate. Usually because someone is optimizing for deflection rate.
That's the reframe. The ISP's bot isn't incompetent. It's rationally designed to a wrong objective. If a transfer to a human costs money and a contained call costs nothing, then a system that makes the transfer hard is doing exactly what it was built to do.
The bot is working. That's the problem.
And the language failure gets worse under that reading, because a Hebrew speaker who can't trigger the English keyword list is, from the metric's point of view, a successful containment. The dashboard doesn't record "caller gave up on the escape hatch." It records "call resolved without transfer."
He didn't give up. He was never offered the door.
The metric can't tell the difference. That's the whole disease in one line.
We've seen why it breaks. Now what it costs, and what good design would actually look like.
Containment is the metric everyone reports because it's the easy one. Kommunicate's point is that containment doesn't tell you whether the customer's issue was resolved, how long it took, or whether they called back two days later with the same problem. It's a number that goes up when the thing you're measuring is how few people reached a human.
MyOperator is blunter. Automation rate is a vanity metric. Resolution quality, including how gracefully a call escalates when it should, is what actually protects customer experience.
And they put a shape on it. An agent that automates ninety-five percent of calls but mishandles the remaining five will cost more in damaged relationships than one that automates seventy percent and escalates the other thirty cleanly.
That's the trade nobody wants to make, because the first number looks better in a board deck.
Traditional IVR containment averages around thirty percent, by the way. So the baseline this is all being compared against is not high.
The consequences are measurable, which is the part that should end the argument. Forrester predicts thirty percent of companies will damage their customer experience this year through bad AI implementation. Cisco's research has seventy-eight percent of consumers saying bad service makes them want to switch providers.
Hiver's numbers are the ones that should keep people up at night. Fifty-six percent switch providers after a single bad interaction. Eighty-nine percent share the story for months or years.
Daniel is telling it on a podcast. That's the eighty-nine percent in the wild.
The one that maps directly onto his call. Seventy-three percent of customers who are denied a human after requesting one will not return to the brand. Not "are annoyed." Will not return.
He did request one. In Hebrew. The system denied him by not hearing him.
Then there's the regulatory angle, which turns this from a customer-experience annoyance into a compliance problem. Ireland's transposition of the EU distance marketing directive this year gives consumers a right to request human intervention instead of relying solely on an automated system.
A legal right.
Liam Dunne, who runs Klearcom, had the line on it. A legal right to talk to a human is useless unless the handoff works. And he adds the part that should worry anyone deploying these systems now. Agentic AI is good enough that customers interact with it longer before asking for a person. So by the time somebody does ask, they're deep into a query. A broken handoff at that point costs you a lot more than it used to.
Because the customer has already invested the effort. They've already decided the system can't help. The handoff failure isn't the start of their frustration. It's the end of their patience.
The audit conversation changes. A caller who hangs up after being denied a human stops being an abandoned contact and starts being a customer denied something they're entitled to.
What do you actually bake in? Give me the list.
Escalate on the second miss, not the fifth. MyOperator's framing is that if the AI misunderstands the same query twice, a third attempt rarely fixes it. Phony.ai sharpens it. Two is the threshold, not three, because by three the caller has decided what they think of you.
Two feels aggressive until you remember the caller is counting.
Honor explicit human requests on the first ask. Never deflect with another menu. Handle mid-call language switches, which is Daniel's case exactly. If the agent can't follow the language, that's the handoff. Detect frustration without trigger words, because the caller who's angry is the least likely to produce your canonical phrase. Sentiment, rising volume, repeated interruptions, sentences getting shorter.
The angrier you are, the worse your keyword compliance.
There's one I like a lot. Encode "retrieval came back empty or thin" as a stop condition. If the agent is about to answer from general knowledge rather than from your material, that is exactly the moment to stop. Phony.ai's line.
The moment the bot starts improvising is the moment it should hand off.
Never promise a transfer you can't complete. An out-of-hours ring-out is worse than an honest "nobody's available, here's a callback time." Carry full context across the handoff, the transcript, the believed intent, what the agent couldn't answer, and why it stopped. Design for recovery, because callers are disfluent and the agent will mishear things. Give a quick audio cue and refocus without blaming the user or over-apologizing. Set capability expectations up front, so the caller knows what the bot can and can't do before they invest three minutes in it.
And the last one.
Consider whether the intent should be automated at all. Some intents are simply better handled by a live agent, especially when empathy, sensitive data, or complexity are involved.
Which brings us to the hardest case in this whole episode. Daniel's modem whitelisting sits between routine and complex. It's documented enough that the ISP expects it. It's rare enough that no bot was trained on it.
That's the gap none of the vendor frameworks name. It's not routine, so you can't just automate it. It's not complex, so it doesn't trip the escalate-to-human rules. It falls through the middle.
The design principle there isn't train the bot on every rare procedure. That's a losing game. There will always be another rare procedure next month.
The principle is build a system that recognizes when it's outside its training and escalates gracefully. The bot doesn't need to know what a modem whitelist is. It needs to know that when the caller's intent doesn't map to anything in its flow, that's the signal.
Which is the opposite of what it does now. Right now the signal is "unknown intent, default to the most common flow."
The operating-model piece, because this is why it persists despite everyone understanding it. The enderturing analysis argues the Forrester thirty percent isn't a knowledge gap. It's an operating-model choice. Procurement is scored on cost-per-contact saved. Pilots run against a deflection target. Nobody measures whether the deflected customer came back angrier.
The deflection looked like savings.
It was actually displaced cost plus reputational damage. That's their line, and it's the knock-on effect in one sentence. The metrics that reward the failure are the same metrics that hide it. The dashboard says the bot is working. The only instrument that registers the problem is the customer, and the customer isn't in the reporting.
The hybrid number makes the point. Eighty-seven percent resolution for a hybrid AI-human model, seventy-four for pure AI. The human in the loop isn't a cost. It's the thing that makes the automation look good.
Hilbert: Nineteen eighty-nine. A summer at a regional phone company's repair bureau. The phone tree was a literal tree. Printed cards taped to the wall, and a human operator decided which card to follow.
How did that work?
Hilbert: You listened to the first fifteen seconds of the call and picked the card. That was the job. I was terrible at it for two weeks. I kept grabbing the card for the most common problem instead of listening to what the caller actually said. My supervisor caught me doing it and told me the card is a tool, not a script. If you're reading the card before you've heard the person, you're not helping.
That's the whole episode in one sentence from a wall in a repair bureau.
Hilbert: The bot has a script. That's not the problem. The problem is it has no equivalent of a supervisor leaning over and saying stop reading the card. In the bureau there was always a human nearby who could tap you on the shoulder.
The shoulder is the escalation path.
Hilbert: The shoulder is the escalation path. And it's been removed to save money.
Which is why the fix has to be architectural. You can't tune a prompt into a shoulder.
Hilbert: I kept one of those cards when the bureau closed. It's for customer wants to add a second line. There's a note in the margin in my supervisor's handwriting. Ask why first. I've been waiting thirty years for a company to make the same mistake at scale. They got there.
I'm needed to let somebody in. I'm the only one with the key.
Go.
The most common wrong belief about this whole thing is that the bot failed because it wasn't smart enough.
It may have heard Daniel perfectly and discarded his intent because the state machine couldn't hold two tasks. That's an architectural failure, not a comprehension failure, and no amount of prompt tuning fixes it.
One forward thought, then we're done. If the failure pattern is this well understood, why does it persist? Because the metrics that reward it are the same metrics that hide it. Containment looks like savings. Resolution looks like cost.
Regulation like Ireland's may force the issue by turning a customer-experience annoyance into a compliance liability. But the deeper fix is cultural. Measure resolution, not deflection, and build systems that know when to stop. The bot that answered Daniel fluently and answered the wrong question felt like a successful call from every dashboard angle except his. That gap between the dashboard and the caller is where the failure lives.
Thanks to our producer, Hilbert Flumingtop. This has been My Weird Prompts, the human-AI collaboration podcast. If you've got a failure pattern from the wild, send it in. Email us at show at my weird prompts dot com.
We'll be back soon.
