Think about the last time you talked to a walkie-talkie versus a phone call.
On a walkie-talkie, only one person can transmit at a time. You press the button, say your piece, say “over,” and release. If you have a sudden objection halfway through the other person’s sentence — too bad. You wait your turn.
Most voice AI agents today are built like walkie-talkies. The agent finishes its entire scripted sentence — even if you’ve already said “wait, no, I meant next Tuesday” three words in. It can’t hear you while it’s talking. To the agent, your interruption either gets dropped entirely or gets queued up and answered after it finishes the thing you were trying to stop it from saying.
A phone call doesn’t work that way. You can cut someone off mid-sentence. They stop talking. The conversation re-routes in real time. That’s not a nice-to-have — it’s what makes it feel like a conversation instead of two people taking turns reciting monologues at each other.
Why this is a genuinely hard problem, not a small one
The walkie-talkie model is easy to build: play the whole audio response, then start listening again. The phone-call model requires the agent to be listening the entire time it’s speaking, and to be able to tear down its own in-progress response the moment real speech is detected — without losing track of where the conversation actually is.
sequenceDiagram
participant Customer
participant Agent
participant Workflow
Customer->>Agent: "I'd like to book an appointment—"
Agent-->>Customer: "Sure! What day works for—"
Customer->>Agent: "—actually, cancel that"
Note over Agent: Speech detected mid-sentence.<br/>Playback stops immediately.
Agent->>Workflow: Interrupt current step
Workflow-->>Agent: Re-evaluate: cancellation branch
Agent->>Customer: "No problem — is there anything else I can help with?"That “Note over Agent” step is the entire problem. The agent has to:
- Detect real speech versus background noise, in real time, while its own audio is playing.
- Stop its own audio output immediately — not at the next sentence boundary, not after a buffer flushes.
- Tell the workflow engine driving the conversation “that step didn’t finish, here’s what actually happened,” so the next thing the agent says is grounded in reality, not in a script that assumed it got to finish talking.
Skip any one of those three and you get something that looks like barge-in in a demo, but falls apart the moment a real customer talks over the agent mid-list, or the moment two people in a noisy environment are both talking near the microphone.
What this means if you’re evaluating a platform
Ask whoever’s selling you a voice AI platform to actually interrupt their own agent mid-sentence, live, not in a curated demo video. Ask what happens to the conversation state after that interruption — does the agent remember what it was in the middle of, or does it just apologize and restart? The gap between “handles interruptions” and “actually built for interruptions from the ground up” only shows up once you push on it.
This is the kind of decision that’s invisible from a spec sheet and obvious in the first thirty seconds of actually using the thing.