Interruption Handling Is Not a Timing Problem — It's a Loop Problem

Barge-in and voice activity detection (VAD) are just the layer that catches when a user cuts in. The real operational risk sits one step later: what state the conversation loop returns to after the interruption. Google's Gemini Live API documentation recommends setting the silence duration (silenceDurationMs) for automatic VAD to 500–800ms, balancing end-of-turn detection against response latency. That setting only improves how fast you detect an interruption — which state the session resumes into afterward is a separate design problem it leaves untouched.

Three Requirements: Correct Resume, Honoring the Interjection, No Re-delivery

A recently published benchmark, IHBench, injects six types of interruptions mid-utterance into voice agents running state-machine-driven workflows, then scores each one on three criteria: does the agent resume the workflow at the correct step, does it actually act on what the user interjected (a correction, a refusal, an extra question), and does it avoid replaying content it already delivered. Those three axes are the design requirements for chatbot and callbot loops, full stop — resumption has to be accurate, interjections cannot be ignored, and repetition drives people to hang up or walk away.

From Design to Operations: A Roadmap for Building an Interruption-Recovery Loop

At the planning stage, split the response into "detection latency" and "recovery accuracy" and set numeric targets for each. Reasonable deployment bars: under 300ms from interruption detection to response stop, resume accuracy (rate of returning to the correct workflow state) above 95%, and a re-delivery rate (rate of repeating content already heard) below 5%. Reusing IHBench's three evaluation axes as operational KPIs directly means you don't have to invent a separate metrics framework.

Once targets are numeric, the workflow itself needs to be modeled explicitly as a state machine. Without predefining, for every transition — ask, confirm, process, complete — which state an interruption should return to, teams end up improvising at runtime, and the resume point drifts inconsistently from one session to the next.

One common failure pattern is a "fake listening" error: the agent ignores what the user interjected and just continues the original script. A user cuts in with "wait, tell me the amount first" and the agent keeps going in its original sequence anyway. The fix is to parse the interruption utterance as a separate intent first, insert a branch into the workflow for it, and only return to the original state after that branch is handled.

Another failure pattern is a "reset-style resume" — replaying delivered content from the very start. After a barge-in, a common implementation just discards the whole context and restarts from the welcome message. The fix is to keep a "last fully delivered utterance index" in session state so a resume only continues from that point onward, and to scope retries to a partial retry from that last completed point rather than a full restart.

Decide abort conditions and backoff up front, too. If interruptions repeat three or more times at the same workflow step, stop auto-recovery and fail safe into a human handoff. Resume after a 200–500ms backoff instead of immediately, re-confirming that the user's utterance has actually ended — this cuts down false positives where the agent mistakes a pause for an interruption and keeps re-triggering recovery.

For pre-deployment quality control, reproduce the six interruption types IHBench covers — correction, refusal, counter-question, supplying extra information, an unrelated utterance, and premature confirmation — as a scenario test set, and use per-type resume accuracy as a deployment gate. Log the interruption timestamp, the workflow state at that moment, the post-resume state, and whether re-delivery occurred as standard fields, and mask payment details, national ID numbers, and other PII in the raw utterance text before storing it.

Run the improvement loop weekly. Pull the workflow-state/interruption-type combinations with the most resume failures to the top, isolate the root cause, and keep changes to the state-machine structure in a separate change log from changes to the recovery logic alone — that separation is what lets you trace a regression's cause quickly.

Takeaways at a Glance

The core of chatbot and callbot loop engineering isn't detecting an interruption fast — it's resuming at the correct point, acting on what was interjected, without repeating yourself. Set the design bar with measurable targets like 95%+ resume accuracy and under 5% re-delivery, and build in a fallback path to human handoff whenever interruptions repeat at the same step — that costs far less than fixing it after the fact.

References

Google AI for Developers – Live API capabilities guide

arXiv – IHBench: Evaluating Post-Interruption Recovery in Voice Agents with Structured Workflows