Barge-in is when a voice AI agent detects that a caller has started talking over it and stops speaking immediately, instead of finishing its sentence. You measure it with detection latency, false-trigger rate, and premature-cutoff rate, because a threshold set wrong breaks the call in either direction.
What Is Barge-In?
In voice AI, barge-in means the caller can interrupt the agent's speech and be heard right away, instead of waiting for the agent to finish talking. This only works on a full-duplex audio pipeline, one that keeps listening while it plays audio back. A half-duplex system, one that stops listening the moment it starts talking, cannot do this at all: it has to finish its turn first.
The term has an older, unrelated meaning in telephony. "Call barging" is a supervisor feature that lets a manager join a live call to listen in or step into the conversation. That is a three-way conferencing feature, not a turn-taking behavior. This article covers the voice AI sense: the caller cutting off the agent mid-sentence, and how you detect and tune that interruption.
This overlaps with turn-taking research generally, but it specifically describes the caller-initiated case. An agent choosing to jump in on a caller, to correct a wrong number, say, is a different design problem with its own rules, usually handled as agent-initiated interruption or backchannel suppression rather than this.
How Is Barge-In Detected and Measured?
Detecting it happens in two layers. Voice activity detection (VAD) runs first: it is a binary classifier that labels a short window of audio as speech or non-speech, usually from signal energy or a lightweight acoustic model. VAD does not know whether that speech is a real interruption or just a cough, so a second layer, called endpointing, decides whether the detected speech is worth stopping for. Endpointing and turn detection are the general version of this same decision, applied to every turn in a call, not only to interruptions.
LiveKit's turn-detection documentation describes the same layering. Voice activity detection finds the periods of silence in what the caller says. The agent then applies heuristics to that VAD data to perform phrase endpointing, which determines the end of a sentence or thought. LiveKit exposes the interruption case as its own setting, with an adaptive mode and a VAD-only mode, so teams choose how much confirmation they want before the agent yields its turn.
Endpointing accuracy is an active research area, because a timeout that is too short cuts callers off mid-thought and one that is too long makes the agent feel unresponsive. A 2015 Interspeech paper proposed computing the expected pause duration across all active speech hypotheses, rather than trusting a single best guess, specifically to separate a mid-sentence pause from a real end of turn. A 2023 Interspeech paper on semantic VAD reported a 53.3% average latency reduction over traditional VAD on an internal dataset, by adding frame-level punctuation prediction to the detector, without significant deterioration in the back-end ASR's character error rate.
Thresholds are configurable, and vendors expose them directly. Deepgram's endpointing parameter, for example, defaults to 10 milliseconds of silence before it finalizes a transcript, and you can set it to any millisecond value depending on how aggressive you want detection to be. Detection thresholds carry the same tension: a shorter window catches interruptions faster but is more likely to fire on noise, and a longer one is safer but slower to react.
This page stays at the definition and measurement-concept level. If you need the cross-ASR-engine comparison, latency percentiles, and an automated test harness for interruption testing, the dedicated testing methodology covers that in depth.
Why Barge-In Matters for Voice Agents
Callers expect to be able to cut in. If you have ever shouted a menu option over an IVR prompt, or said "yes" before a phone tree finished its sentence, you already know the expectation: real conversations do not wait for a full turn to finish before the next person responds. An agent that ignores this feels scripted and mechanical, not conversational.
For human agents, this kind of interruption handling is automatic. People read pitch, pauses, and filler words to know when it is safe to jump in, and they adjust instantly. Voice AI agents do not have that instinct built in. They need an explicit detection and endpointing layer to approximate it, making the same split-second call a human makes without thinking.
The cost of getting it wrong is concrete, not abstract. A caller who states a critical detail, an account number, a symptom, a change of mind, while the agent keeps talking has effectively been ignored. If the agent does not stop, that detail may never reach the transcript the rest of the call logic depends on. These failures do not just feel bad; they can silently drop information the caller thought they gave you.
What Happens When the Threshold Is Tuned Wrong?
Barge-in has two failure directions, and they pull against each other. Set the detection threshold too sensitive, and you get an over-eager response: the agent stops mid-sentence for a cough, a door closing, or a "mhm" the caller meant as a backchannel rather than a turn-taking signal. Callers notice this fast. It reads as a nervous, stuttering agent that cannot finish a thought.
Set the threshold too conservative, and you get the opposite failure: an under-sensitive one. The agent talks over a real interruption, forcing the caller to repeat themselves, raise their voice, or sit through a prompt they already answered. This usually reads worse to callers than an over-eager agent, because it feels like the system is not listening at all, rather than being slightly too jumpy.
There is no single correct setting for every deployment. Tightening the threshold to cut false positives raises the risk of missing real interruptions, and loosening it to catch every real interruption raises the false-trigger rate. The right balance depends on the use case: a symptom-intake line for a clinic should probably lean toward catching every interruption, while a line reading a long required disclaimer might tolerate a slower, steadier threshold.
How Does Barge-In Differ from General Overtalk?
Overtalk and barge-in sound like the same thing, and they are related, but they measure different things. Overtalk is usually a percentage of an entire call: the share of total time where both parties are speaking on top of each other, measured from separate audio channels. The interruption event is narrower: the moment a caller starts talking while the agent is mid-response, plus how fast the agent reacts to it.
Every barge-in produces a moment of overtalk, but not every overtalk moment starts from one. The agent can also start speaking too early over a caller who has not finished. That counts toward overtalk, but it runs in the opposite direction: the agent interrupting the caller, not the caller interrupting the agent. The dedicated silence and overtalk detection guide covers the whole-call metric and how it is scored; this page stays scoped to the caller-interrupts-agent case and the detection layer behind it.
Where Does Cekura Fit?
Cekura scores interruption handling as part of its cross-platform voice agent benchmark. In the current seven-platform cohort, the benchmark puts interruption-handling scores between 5.00 out of 5, the top scorer, and 4.73 out of 5, the lowest scorer, based on the mean interruption score across calls where the interruption evaluator applied. Those scores come from the benchmark's frozen v1 release, 7 configurations across 82 scenarios with 3 retained repeats, read in August 2026. Scores move as platforms and models change, so treat the published benchmark as the source of truth rather than any single number repeated later.
Cekura tests this behavior before an agent ships and monitors it in production once the agent is live. Cekura then feeds the failures it finds back into tuning, so teams are not just scoring the problem but closing the loop on it. That covers both directions: the agent that stops for background noise, and the agent that keeps talking over a real interruption.
If you want to see where your own agent's interruption handling lands, Cekura can walk you through scoring it against the same evaluator used in the benchmark.
Frequently Asked Questions
Is barge-in the same as call barging in a contact center?
No. Call barging is a supervisor feature: a manager joins a live call to listen in or step into the conversation, essentially a three-way call. Barge-in, in voice AI, is the caller interrupting the agent mid-response and the agent stopping to listen. The two terms share a name but describe unrelated features.
What is the difference between barge-in and voice activity detection?
VAD is the first layer: it classifies short windows of audio as speech or non-speech. Barge-in is the behavior built on top of that classification, deciding whether detected speech during agent playback is a real interruption worth stopping for, which is the job of endpointing, not VAD alone.
What causes false barge-in?
A detection threshold set too sensitive. The agent stops for coughs, background noise, a door closing, or a backchannel word like "mhm" that the caller meant as encouragement, not an interruption. Tightening the threshold reduces false triggers but raises the risk of missing a real one.
What happens if barge-in is too slow or disabled?
The agent keeps talking over a real interruption. The caller has to repeat themselves, raise their voice, or sit through a prompt they already answered. This usually reads worse to callers than an over-eager agent, because it feels like the system is not listening at all.
Does Cekura test this behavior?
Yes. Cekura scores interruption handling across ASR engines and voice platforms, and tracks both failure directions: the agent that stops for background noise, and the agent that talks over a real interruption. Cekura keeps the results on a live benchmark rather than restating a fixed number as permanent.
