Featured Article
Implementation
When a caller interrupts a voice AI agent, stop the obsolete audio, update the conversation to reflect what was actually played, and check any business action already in progress before responding. Stopping speech alone does not tell you whether an appointment, CRM update or follow-up message was committed.
For a developer, this is a coordination problem across audio, conversation memory and tools. For a marketing operations team, the practical question is simpler: if someone says “wait, change that,” will the system act on the correction?
Published by ConversAI Labs. This guide combines vendor documentation with a proposed application design, not comparative testing. It does not establish native ConversAI interruption controls or a guaranteed response time.
What should happen when a caller interrupts?
Consider an appointment workflow. The agent is saying, “I can book Wednesday at ten,” when the caller interrupts: “No, Friday afternoon.”
The next action depends on what the application has already done. If Wednesday was only a suggestion, discard it. If a booking request was dispatched, establish its outcome before issuing a replacement. If Wednesday was already booked, changing the appointment requires a separate, verified operation.
Use three distinct state records:
| State | What it answers | Example |
|---|---|---|
| Audio response | Which response is still allowed to play? | Response 42 was interrupted; later chunks for 42 are obsolete |
| Conversation | What was played, and what correction did the caller make? | Wednesday was suggested; Friday is now requested |
| Business action | Was a side effect requested, committed or left uncertain? | Booking attempt 17 is awaiting a confirmed outcome |
An interruption invalidates the old spoken continuation. It should not silently erase the record of an external action.
Why must the audio buffer and conversation history agree?
A model can generate a sentence before the caller has heard it. Your application may also have queued audio downstream. Stop producing obsolete speech and clear queued playback where the transport supports it.
In bidirectional Twilio Media Streams, the documented clear message empties the audio buffer. Twilio also returns matching mark messages for remaining buffered audio after a clear. Therefore, a returned mark must be interpreted alongside your clear operation; it is not automatically evidence that the caller heard that segment. See Twilio's WebSocket message documentation.
LiveKit documents stopping speech and truncating conversation history to the portion heard before an interruption. Its turn-handling guidance also distinguishes genuine interruptions from backchannel responses. See LiveKit's turn and interruption documentation. Those are vendor-specific behaviours: verify the SDK, model and transport used in your deployment.
For a custom implementation, a useful design is to attach a response version to every outgoing audio chunk. When you accept an interruption, invalidate that version. Discard late chunks from the old response, reconcile playback markers and start the next response under a new version. Serialize those transitions so an old chunk cannot be enqueued after the clear.
Keep the generated text separate from the playback-aligned conversation record. If playback evidence is incomplete, record uncertainty instead of treating an entire generated confirmation as delivered.
Does interrupting speech cancel a CRM or booking action?
Do not assume so. Treat speech control and external action control as separate application responsibilities. A local cancellation or timeout is not evidence that a remote write was reversed.
Use an explicit decision table:
| Action state when the correction arrives | Proposed handling | What the agent can safely say |
|---|---|---|
| Not dispatched | Replace the proposed arguments after validating the correction | “Friday afternoon—let me check availability.” |
| Dispatched, outcome unknown | Query or reconcile the original attempt; do not blindly create another | “Let me check whether the first booking went through.” |
| Confirmed committed | Explain the existing result and use an authorized change or cancellation operation | “Wednesday was booked. I’ll check the options for changing it.” |
| Confirmed failed | Retry only if the new intent is still valid | “That booking did not complete. Let’s check Friday.” |
Give business operations their own identifiers and states. Do not reuse a speech response ID as the sole booking identity. Before applying a late tool result, check which operation it belongs to and whether it changes the caller's current situation.
This complements booking verification, duplicate webhook handling and CRM conflict handling. The distinct task here is coordinating those outcomes with a caller who changes direction mid-response.
How should you test interruption handling?
Use synthetic calls and a test CRM or calendar. Inspect audio playback and destination records together; a transcript alone cannot establish what happened.
| Test | Acceptance evidence |
|---|---|
| Caller corrects a date mid-sentence | Old date is not repeated as the final choice; new date is validated |
| An old audio chunk arrives after the interruption | It is discarded rather than played during the new turn |
| Caller interrupts while a booking request is in flight | Original attempt is reconciled; no duplicate appointment |
| Caller says “okay” or background noise occurs | Behaviour matches the intended backchannel/noise policy |
| Tool succeeds after speech was interrupted | Committed result remains recorded and is accurately explained |
| Caller interrupts a confirmation | The agent does not assume the full confirmation was delivered |
Measure the interval from caller speech onset to audible agent stop, separately from the delay to the next useful response. Review median and slower-tail values by route, language and noise condition. Choose acceptance limits for your use case rather than borrowing an unsupported universal latency target.
Also count unwanted cut-offs, repeated questions and incorrect side effects. A fast stop can still leave the wrong appointment in the CRM. Add these cases to your voice-agent regression checks.
Start with one correction flow
Begin with a reversible test: change a proposed appointment before dispatch, then repeat while the test booking is in flight. Keep opaque call and operation IDs, state transitions and timing measurements in the test evidence; avoid copying customer transcripts or contact details into general analytics.
For ConversAI Labs, review the API documentation and confirm the controls available in your account before designing around them. Create an account, create an agent and make a controlled test call, then validate the destination record.
Current pricing is ₹1 = 1 credit and 4 credits per connected voice minute (₹4/minute). Workflows are free for now; a test that connects a voice call uses the same voice rate. The account includes 100 free credits, with allowance terms checked in the account. See pricing.
About ConversAI Labs Team
The ConversAI Labs team writes about building and operating voice AI workflows.