Think about the last time you talked over a walkie-talkie versus talked over the phone.
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, because the channel itself won’t let you do anything else.
Most voice AI agents today are built like walkie-talkies, even the ones marketed as “interruptible.” 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, or it can hear you but has nowhere to put what it heard until it’s done. 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, and neither of you loses your place. That’s not a nice-to-have — it’s what makes something feel like a conversation instead of two people taking turns reciting monologues at each other.
This post is about the gap between those two things, why it’s much wider than it looks from a demo, and what it actually takes to close it.
“Interruptible” usually means turn-taking, not interruption
Here’s the distinction that matters, stated as plainly as possible up front: most products that advertise “interruption handling” have actually built turn-taking, not barge-in.
Turn-taking means the system is good at detecting silence — it notices when you’ve stopped talking and hands the floor back to you (or to itself) at that boundary. That’s a real and useful thing to build well. A system with good turn-taking doesn’t awkwardly talk over you when you pause, and it doesn’t leave three seconds of dead air wondering if you’re done. But it’s fundamentally a gap-detection problem: find the silence, then switch. There is no dropdown moment where the agent is mid-word, mid-sentence, or mid-thought and something makes it stop anyway.
Barge-in is a different problem: the agent has to keep listening while it is actively producing audio, recognize that what it’s hearing is real speech and not noise or its own voice bleeding back into the microphone, and tear down its own in-progress output — immediately, not at the next sentence boundary — without losing track of what it was actually doing.
Those two capabilities get marketed with the same word. They are not the same engineering problem, and the second one is dramatically harder. The rest of this post is about that second problem.
The three layers real barge-in actually needs
Getting from “plays back audio, then listens again” to “can be cut off mid-sentence and recover gracefully” requires work at three separate layers, and skipping any one of them is where the illusion breaks.
1. Voice-activity detection (VAD)
Before anything else can happen, something has to answer a narrower question than “is the user talking”: is there real human speech happening right now, distinguishable from background noise, a cough, a chair creaking, or the agent’s own voice being picked back up by the microphone?
This is genuinely a signal-processing problem, not a language one — it has to run fast enough to matter (dozens of times a second) and has to be resilient in an uncontrolled acoustic environment, which most voice AI deployments are. Getting this wrong in either direction is costly: too sensitive, and every ambient sound triggers a false interrupt; too conservative, and a user has to raise their voice or repeat themselves before the system notices they’re talking.
2. Frame-level audio buffering and playback control
Detecting speech is only useful if something can act on it immediately. Audio doesn’t get generated and played back as one atomic unit — it’s synthesized and streamed in small chunks (frames), and playback happens continuously from a buffer. Real barge-in means that buffer has to be interruptible at the frame level: the moment a real interrupt signal arrives, playback has to stop now, not after the current sentence, not after the current buffered chunk finishes draining. A system that can only stop between sentences is still doing turn-taking with a slightly finer grain — it isn’t true barge-in.
3. Workflow / state-machine coordination
This is the layer that’s easiest to skip and most damaging when skipped. Stopping the audio is the easy 20% of the problem. The hard part is: the agent was in the middle of doing something — following a branch of a conversation flow, halfway through composing an answer, maybe about to call a tool. When it gets cut off, that in-flight work doesn’t just vanish cleanly. Something has to decide: was that step actually completed? Should the next thing the agent says pick up from where it left off, abandon that branch entirely, or route somewhere new based on what the user just said?
Get this layer wrong and you get an agent that handles the audio interruption fine but then says something that makes no sense in context — because nothing told the part of the system deciding what to say next that the previous plan was scrapped.
What has to happen, in order, for it to feel instant
Here’s the sequence from the previous version of this post, because it’s still the clearest way to see why this is hard — the “note over agent” step in the middle is the entire problem this post is about.
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?"Unpacked into the three layers above, that “note over agent” step has to do, in order:
- VAD layer: distinguish “the customer just started talking” from noise or echo, fast enough that the delay is imperceptible.
- Playback layer: stop the agent’s own audio output at whatever frame it’s currently on — not at the next clause, not after a buffer flush.
- Workflow layer: tell whatever’s driving the conversation “that step didn’t finish — here’s what actually happened, decide what comes next,” so the agent’s next sentence is grounded in the real state of the conversation, 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 curated demo, but falls apart the moment a real caller talks over the agent mid-list, or two people near the same microphone are talking at once, or the “interruption” turns out to be a truck passing outside.
Where this actually breaks in practice
Two failure modes show up constantly once a barge-in system leaves the demo environment and meets real users and real rooms.
False-positive interrupts from background noise. A VAD tuned to be responsive enough to feel snappy will also occasionally fire on things that aren’t the user talking — a notification chime, someone else in the room, the agent’s own voice leaking back through an open speaker into the mic. Every false positive is a real cost: the agent stops mid-sentence for no reason, the user has no idea why, and now they have to say something to get it moving again. This is exactly why barge-in systems can’t just crank VAD sensitivity to maximum and call it done — every gain in responsiveness has to be weighed against the false-positive rate it introduces, and that trade-off is one of the genuinely hard tuning problems in this space, not a solved default.
The agent “fighting” the user to finish a sentence. This is a coordination bug, not a VAD bug: the audio layer stops, but the underlying generation logic — the part deciding what to say — doesn’t get the memo in time, so a half-second later the agent starts talking again, picking up mid-thought as if nothing happened. To a user, this reads as the agent actively resisting being interrupted, which is a worse experience than either turn-taking or a slightly slow interrupt would have been. It’s the direct, visible symptom of skipping the workflow-coordination layer described above — the audio stopped, but nothing told the decision-making layer the plan had changed.
What Wetel’s implementation does, honestly
Given how much of the above can be oversold, here’s a plain description of the actual mechanism, not a marketing gloss.
Wetel’s barge-in is a cooperative interrupt system — it works by checking, at fine-grained checkpoints, whether the current turn has been cancelled, rather than by forcibly severing a running process mid-instruction. There are two coordination layers involved, both grounded in a single per-turn “generation” counter that travels through the whole conversation turn so a cancellation signal can only ever affect the exact turn it was raised for, never a later, unrelated one.
- Response-generation checkpoint. As the agent’s reply streams out, it’s checked against that generation’s interrupt state at each sentence boundary — not once at the end, and not per token, but frequently enough that a real interruption cuts the response off within a sentence of the moment it was detected, rather than at the end of a much longer planned response.
- Workflow-run checkpoint. Independently, the workflow engine driving the conversation checks interrupt state between each step of the graph it’s executing. A step already in flight (a tool call already sent, for example) is allowed to finish rather than being torn down destructively mid-execution — but the next step won’t run if the turn has been cancelled, and the engine re-evaluates from a state that reflects what actually happened, not what the original plan assumed would happen.
- Client-side listening. Voice-activity detection itself runs on the client, close to the microphone, which is architecturally the right place for it — it needs to react in milliseconds and doesn’t need a network round-trip to do its job. When the client detects real speech while the agent is talking, it immediately stops local audio playback and signals the backend to cancel the in-flight turn, rather than waiting for a round-trip confirmation first. That’s a deliberate choice to prioritize how the interruption feels over waiting for perfect server-side confirmation.
The honest caveat, in the same spirit as the rest of this post: this is a fast, well-coordinated cooperative interrupt — sentence-level cancellation on the response stream, step-level cancellation on the workflow graph, and client-side detection that acts before waiting on the network — not a claim of exotic real-time signal processing running inside the core API. The distinction we drew earlier in this post (turn-taking vs. true mid-utterance interruption) is the one to hold this implementation against, and it lands clearly on the barge-in side of that line: the agent really can be cut off mid-sentence, the in-flight response really does stop rather than finish and get suppressed, and the workflow really does re-route based on what happened, not on the original plan.
Why most vendors don’t actually attempt this
None of the three layers above is exotic in isolation — voice-activity detection, streaming audio playback, and cancellable state machines are each individually well-understood problems. What makes real barge-in rare in practice is that all three have to work together, in the right order, within a budget of a few hundred milliseconds, without any one layer silently assuming the others already handled the coordination.
It’s also the kind of feature that’s easy to fake for a demo and expensive to get right for production. A scripted demo can hardcode the happy path — a clean interruption, in a quiet room, at a sentence boundary. Making that hold up against a noisy call center, a user who talks over the agent mid-word, or two overlapping voices near the same microphone means solving the false-positive problem and the coordination problem described above for real, not just for the one scenario in the sales deck.
That’s also why this is the single most useful thing to actually test, not take on faith, when evaluating any voice AI 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. Talk over it mid-word, not at a pause. Then ask what happens to the conversation after that interruption — does the agent remember what it was in the middle of and route sensibly from there, or does it just apologize and restart from a generic fallback? The gap between “handles interruptions” and “actually built for interruptions from the ground up” is invisible on a spec sheet and obvious within the first thirty seconds of actually pushing on it.