How voice agents handle interruptions and follow-up questions

The single biggest tell that you're talking to an early-generation voice bot is what happens when you interrupt it — modern voice agent architecture handles this fundamentally differently.

Why interruption handling used to be, and often still is, so bad

Older IVR and voice bot systems process speech in a rigid turn-taking model: the system talks, then listens, with no ability to detect and respond to a caller speaking over it. This produces the familiar frustrating experience of a bot continuing to recite a full menu while you're trying to say "representative" three times. It's not a minor UX flaw — it's a structural limitation of systems that weren't built with real-time interruption detection.

How modern voice agents handle this technically

We build on voice infrastructure with real-time, streaming speech detection — the system is continuously listening even while it's speaking, using voice activity detection (VAD) to recognize when the caller has started talking, and stops its own output within a few hundred milliseconds, not after finishing its current sentence. This requires an architecture where text-to-speech output can be interrupted mid-stream (not just mid-sentence, genuinely mid-word if needed) and the system immediately shifts to processing the caller's new input.

Follow-up questions within the same turn — a caller adding a clarification before the system has fully responded to the first part — require the underlying language model to maintain conversational state across the interruption, understanding that the new input is a continuation or modification of the previous request, not a completely fresh conversation starting from zero context.

The latency budget that determines whether this feels natural

For interruption handling to feel human-like rather than glitchy, the full pipeline — detecting the interruption, stopping current output, processing new speech input, generating a response, converting back to speech — needs to complete within a tight latency budget, typically under 500-800 milliseconds for the system to feel responsive rather than laggy. We benchmark and tune specifically against this, because a voice agent that's accurate but has a 2-second lag after every interruption still feels broken to callers, even if the eventual answer is correct.

A concrete example

An early version of a client's appointment scheduling voice agent, built on an older architecture, had a measured average interruption-response lag of roughly 1.8 seconds and a documented pattern of the system talking over callers who tried to correct information mid-sentence ("actually, make that Tuesday not Monday"). Caller satisfaction surveys specifically flagged this as frustrating. We rebuilt on a streaming architecture with real-time VAD, reducing interruption-response lag to under 400 milliseconds on average, and explicitly tested the system against a set of realistic interruption and correction scenarios before relaunch. Post-relaunch satisfaction scores on the "did the system understand you" survey question improved measurably, and call abandonment rate (callers hanging up mid-interaction) dropped as well.

How Ndakum approaches it

Real-time interruption handling is a baseline requirement, not a premium feature, in every AI Voice Agent we build — we test explicitly against interruption and correction scenarios before any launch.