Evaluate Voice Agent Interruption Recovery Beyond Stop Speaking

Voice agent interruption recovery has three parts: stop the right speech, understand the new input and continue from the correct state. An assistant that becomes silent immediately can still fail if it later repeats an abandoned answer or completes an action using information the caller corrected.

Evaluate recovery as a whole conversation. The question is whether the caller can change direction naturally without losing control of the request. This is especially important when an interruption occurs near a confirmation or while another system is responding.

Separate interruption types

Begin with three distinct events. A correction changes a fact: “Actually, the last digit is seven.” A new request changes the task: “Before that, what time do you close?” An acknowledgement, such as “right,” may simply mean the caller is listening.

These should not automatically have the same effect. LiveKit's turn-taking guidance distinguishes interruption handling from endpointing and speech scheduling. Available controls depend on the runtime and model; do not assume a particular setting exists in every product interface.

For an operator, the practical first step is to record what happened rather than guess which control to change. Did the assistant fail to stop, miss the correction, or resume the wrong sentence? Each symptom points to a different investigation.

Build a timed test matrix

Use one short business conversation and interrupt it at several meaningful points:

This is a proposed evaluation matrix, not a promise that every mode supports every behaviour. Remove actions that are outside the assistant's supported scope and label any unresolved case before launch.

A hypothetical correction case

Imagine a caller spelling an equipment code. The assistant starts reading back “A, B, seven,” and the caller says, “No, D, not B.” A successful recovery stops the obsolete readback, acknowledges the corrected character and checks the entire code if the action depends on accuracy.

Review the final stored value as well as the audio. If the conversation sounds correct but the tool receives the original code, speech recovery passed while state recovery failed. If the tool had already completed, the assistant must explain the actual situation rather than imply it silently reversed the action.

Listen for stale speech

After an interruption, listen for a delayed sentence that belongs to the previous turn. It may sound harmless in a general answer but become misleading when it confirms an abandoned request. Mark the sentence, its timestamp and the state of any related action.

Also check excessive repetition. Restarting a long explanation from the beginning after every small sound can make a technically responsive assistant exhausting to use. The best outcome is often a short continuation or a targeted clarification.

Use the same microphone and route when comparing configurations, then add a small set of realistic environments. A headset, speakerphone and noisy room can expose different problems. Change one condition at a time so an improvement has an interpretable cause.

Score recovery, not just speed

Track time to stop audible speech where you can measure it, but pair it with correction accuracy, stale-speech incidents and successful continuation. Keep uncertain cases separate. A screen transcript alone cannot establish what overlapped at the caller's ear.

Burki's natural voice discussion provides context for conversational flow. Use its testing guide to turn one frustrating interruption into a repeatable acceptance case. Approve a change only when the caller's intended correction survives through the final result.