How to Evaluate Interruption Detection in Voice Agents

# How to evaluate interruption detection in voice agents

Quick answer

> Quick answer: To evaluate interruption detection, run scripted barge-in scenarios plus real calls, then measure four things: barge-in detection rate, false-barge-in rate, stop latency in milliseconds, and post-interruption recovery. A strong voice agent goes silent within about 300 to 500 ms of a real interruption and ignores backchannels like "uh-huh."

Interruption detection voice agents live or die on timing. A caller cuts in. The agent either stops fast, or it keeps talking over them. That single moment shapes how the whole call feels. Get it wrong and callers repeat themselves, raise their voice, or hang up.

This post is about measuring that moment. It sits under our voice agent evaluation pillar and stays narrow on purpose. Turn-taking as a whole is covered in our turn-taking evaluation post. Here the focus is one skill: detecting and handling interruptions. Evalgent is an independent evaluator. We run barge-in scenarios on your own agent and report stop latency and false-barge-in rates without favoring any vendor.

What interruption detection means in a voice agent

> Interruption detection: the ability of a voice agent to notice when a caller starts speaking mid-response and decide whether to stop. It combines listening while talking, judging whether the caller means to take the floor, and yielding promptly when they do.

Two related terms sit next to it. Barge-in is the caller act of cutting in while the agent speaks. Interruption detection is what the agent does in response. Our barge-in guide walks through the mechanics in detail.

The skill has two failure directions. The agent can miss a real interruption and talk over the caller. Or it can stop for something that was not an interruption at all. Both are common. Both are measurable. A useful evaluation scores each direction on its own.

Interruption handling is also distinct from context tracking. Stopping is one job. Remembering where the conversation was is another. We separate the two in our interruption versus context guide.

Why interruption detection has to be measured, not assumed

Vendors demo interruption detection on clean input. A tester speaks one crisp sentence and waits. Real callers do not behave that way. They pause mid-thought. They say "um" and "hold on." They talk over the agent. They drop short backchannels while the agent is still speaking.

So you cannot trust a demo. You have to measure interruption detection voice agents on messy audio. Use real recorded calls, or synthetic calls built to mimic them. Include mid-sentence pauses, filler words, overlapping speech, and background noise. The goal is to trigger the failures a scripted demo hides. That is how you evaluate voice agent barge-in honestly.

Self-reported numbers do not help either. A provider might claim fast barge-in without saying what "fast" means or how it was measured. Independent measurement fixes that. We explain the case in our post on independent voice AI evaluation.

Interruption detection also matters for risk and trust. An agent that talks over a caller during a dispute or a medical question reads as careless. Frameworks like the NIST AI Risk Management Framework treat that kind of interaction quality as part of responsible deployment, not a nice-to-have.

The interruption scenarios worth scoring

Interruptions come in a few recognizable shapes. Each shape needs its own test and its own pass bar. Testing only the easy case, a hard barge-in on silence, tells you almost nothing. Strong interruption detection voice agents pass every one of these shapes, not just the easy one. The table below maps the five scenarios that matter.

Read each row as a separate score. An agent can be quick to stop yet stop for the wrong reasons. Another can hold the floor well yet ignore genuine cut-ins. You want the full profile before you trust it in production.

The four metrics behind voice agent interruption handling

Voice agent interruption handling breaks into four numbers. Each turns a subjective sense of "it interrupts weirdly" into something you can track and compare.

• Barge-in detection rate. The share of real caller interruptions the agent correctly yields to. Low rates mean the agent talks over people.
• False-barge-in rate. The share of agent stops triggered by backchannels, noise, or cross-talk. High rates mean a jumpy, twitchy agent.
• Stop latency. The time from caller speech onset to agent silence, in milliseconds. This is a form of latency), and it is felt directly by the caller. Our latency guide covers the wider budget.
• Post-interruption recovery. Whether the agent handles the new input and keeps prior context after it stops. A fast stop is wasted if the agent then forgets the call.

Report all four together. A single headline number hides the trade-offs. Fast stop latency paired with a high false-barge-in rate is not a good agent. It is a nervous one.

Backchannels versus real interruptions

The hardest part of interruption detection is telling a real interruption from a backchannel. A backchannel is a short sound that means "I am listening," not "stop talking." Words like "yeah," "right," and "mm-hmm" fall in this bucket. Humans read these easily. Voice agents often do not.

A crude agent stops on any incoming sound. That produces a high false-barge-in rate. It halts every time the caller says "uh-huh." The call turns into a series of false starts. A better agent weighs duration, energy, and content before it yields.

This is partly a voice activity detection problem and partly a speech segmentation problem. The system has to detect that speech is present, then judge whether it forms a real bid for the floor. Human turn-taking runs on the same signals, and people rarely get it wrong.

Your test set must include backchannels on purpose. Sprinkle "yeah" and "okay" through the caller audio while the agent talks. Then check that the agent keeps going. If it stops, you have found a false-barge-in problem the demo never showed.

Full-duplex, half-duplex, and endpointing

Interruption detection depends on the audio architecture underneath. A full-duplex system can send and receive at the same time. That lets the agent listen while it speaks. A half-duplex design handles one direction at a time. It struggles to hear a caller mid-response, so barge-in is weak by design.

Ask which model your agent uses. If it is effectively half-duplex, no amount of tuning will fix late barge-in. The limit is structural. This is the full-duplex vs half-duplex voice agents question, and it sets your ceiling. Echo cancellation matters here too. The agent must not mistake its own voice, leaking back through the line, for the caller cutting in.

Endpointing is the related decision of when the caller has finished a turn. Aggressive endpointing makes the agent jump in early and talk over people. Slow endpointing leaves dead air. Interruption detection and endpointing are two sides of managing the floor. Our barge-in versus turn-taking guide draws the line between them.

How to evaluate interruption detection in a voice agent

Here is a repeatable method. It works whether you are testing one agent or comparing vendors on the same bar.

1. Define the scenarios. Start from the five rows above: hard barge-in, backchannel, overlap and noise, self-barge-in, and recovery. Add call types specific to your use case.

2. Build the test audio. Script each scenario with real timing. Include mid-sentence pauses, filler words, and background noise. Reuse real call recordings where consent allows.

3. Set your pass bars. Decide the stop-latency ceiling, the detection-rate floor, and the acceptable false-barge-in rate before you run anything. Written bars stop you moving the goalposts later.

4. Run each scenario multiple times. One pass is noise. Repeat each case across voices, accents, and noise levels to get a stable rate.

5. Measure from the audio, not the transcript. Timestamp caller onset and agent silence in the waveform. A transcript cannot tell you stop latency or who talked over whom.

6. Score both directions. Log misses (talk-overs) and false stops (backchannel or noise triggers) separately. Report barge-in detection rate and false-barge-in rate side by side.

7. Check recovery. After every yield, confirm the agent handled the new input and kept prior context. A clean stop with a lost thread still fails the call.

8. Compare against the bar. Roll the scenario scores into a scorecard. Rank agents on the full profile, not one flattering number.

How Evalgent evaluates interruption detection

Evalgent runs this method as an independent third party. We build barge-in scenarios on your own agent, using your call types and your audio. We measure stop latency in milliseconds, barge-in detection rate, and false-barge-in rate on backchannels and noise. We also check post-interruption recovery, so a fast stop that loses context still shows up as a failure.

We do not sell an agent, and we do not favor any vendor. That is the point. Buyers comparing interruption detection voice agents get numbers they can trust. The numbers are measured, not reported by the provider. The same discipline runs across our broader voice agent testing work.

If you are choosing between vendors or hardening one agent before launch, this is the evidence you need. Book a demo and we will run interruption scenarios on your agent and hand back the profile.

Frequently asked questions

How to evaluate interruption detection in a voice agent?

Run scripted barge-in scenarios and real calls, then measure four things from the audio: barge-in detection rate, false-barge-in rate, stop latency in milliseconds, and post-interruption recovery. Test hard cut-ins, backchannels, noise, and self-barge-in separately. Set pass bars first, repeat each case, and score misses and false stops apart.

What is barge-in in voice agents?

Barge-in is when a caller starts speaking while the voice agent is still talking, meaning to take the floor. Interruption detection is the agent's response: noticing the cut-in and deciding whether to stop. Good barge-in support lets a caller interrupt naturally, the way people do in human conversation.

What is a false barge-in?

A false barge-in is when the agent stops for something that was not a real interruption. Common triggers are backchannels like "uh-huh," background noise, cross-talk, or a third voice. It makes the agent feel jumpy and produces stop-start calls. False-barge-in rate measures how often this happens across a test set.

How do you measure stop latency?

Measure stop latency from the audio waveform. Timestamp the moment the caller starts a real interruption, then the moment the agent goes silent. The gap, in milliseconds, is stop latency. A strong agent stops within about 300 to 500 ms. Transcripts cannot give you this number, so score it on the audio.

How do voice agents tell backchannels from interruptions?

They weigh signals like duration, energy, and content before yielding. A short "mm-hmm" is a backchannel and should not stop the agent. A longer, directed utterance is a real bid for the floor. This blends voice activity detection with speech segmentation. Weak agents stop on any sound, which drives up the false-barge-in rate.

Why does my voice agent talk over callers?

Two usual causes. First, the architecture may be half-duplex, so it cannot hear the caller while speaking. Second, its interruption detection may be tuned to ignore short input, missing real cut-ins. Aggressive endpointing also makes an agent jump in early. Measure barge-in detection rate and stop latency to find which one is at fault.

What is the difference between full-duplex and half-duplex voice agents?

A full-duplex agent sends and receives audio at once, so it can listen while it talks and support real barge-in. A half-duplex agent handles one direction at a time, so it struggles to detect interruptions mid-response. If barge-in is weak, confirm the audio model first. A half-duplex limit cannot be tuned away.

What is post-interruption recovery?

Post-interruption recovery is what the agent does after it stops for a caller. Strong recovery means it handles the new input and keeps prior context, so the call continues cleanly. Weak recovery means it repeats its old line or loses the thread. A fast stop paired with poor recovery still counts as a failed turn.

The bottom line

Interruption detection is measurable, and a demo will not show you the truth. Score barge-in detection rate, false-barge-in rate, stop latency, and recovery on messy audio, in both directions, before you trust an agent live.