來電者打斷時，如何更新語音智能體的對話狀態

Imagine an appointment assistant offering two times: “I can offer Tuesday at ten, or Thursday at two.” The caller cuts in after “Tuesday at ten” to ask about parking. If the model later asks “Which of those two times works?”, it is relying on an option the caller never received. The audio stopped correctly. The conversation state did not catch up.

Disclosure: This article was researched and drafted by an AI agent using my public project documentation and the linked technical sources.

My SmartVoiceX case study documents a built phone operations product with ongoing development: calling flows, calendar and API integrations, human transfer, and call records. Those features make conversation state consequential. A booking flow needs to know more than what the assistant intended to say.

The example above is hypothetical. The implementation pattern below is a proposed approach, not a claim that SmartVoiceX uses Twilio ConversationRelay or already implements these exact mechanisms.

Generated text is not a delivery receipt

Twilio's September 25, 2026 interruption-handling guidance describes a useful division of responsibility. ConversationRelay handles speech playback and interruption detection. The application still owns the model's conversation history. Twilio specifically advises updating that history to reflect the speech played before an interruption.

This is an ongoing voice-agent engineering concern, rather than a newly launched October feature. It matters as teams connect streamed speech to actual workflows: a model can finish generating a sentence well before playback finishes delivering it.

For the appointment example, I would keep distinct records of the complete generated response and the portion reported as played. The former is useful for debugging. The latter should shape the next conversational turn. Neither proves that the caller understood or accepted an offer.

That distinction changes the recovery response. The assistant can answer the parking question, then introduce the remaining option. It should not assume that two choices are already part of the shared conversation.

Use the interruption event without overreading it

The ConversationRelay WebSocket reference documents an interrupt message with utteranceUntilInterrupt and durationUntilInterruptMs. The first reports the utterance played before the cutoff; the second provides the elapsed duration. These are useful application inputs, not evidence of comprehension or confirmation.

In a comparable integration, I would reconcile the interrupted assistant turn before requesting the next model response. I would retain the generated text in an audit record, mark that turn as interrupted, and give the model the reported spoken portion with its interruption context. Simply deleting the entire turn could also lose something the caller actually received.

I would also stop forwarding obsolete output from that response. Cancellation alone needs scrutiny: an already scheduled callback may still deliver tokens. An application-owned response identifier can help reject output belonging to a superseded response. This is a proposed concurrency safeguard, not a field promised by Twilio's interrupt message.

The important invariant is practical: once a response has been superseded, its remaining speech should not reappear after the caller's new request. Test that property at the boundary where text leaves the application, including delayed output.

Keep calendar state separate from spoken state

Interrupting a sentence does not undo an external operation.

Suppose a calendar write succeeds, but the caller interrupts the confirmation. The application now has two facts: the appointment exists, and the confirmation was only partly delivered. Trimming the assistant's words must not erase the successful write or trigger a second booking when the conversation resumes.

For that situation, I would have the next response consult the recorded operation result and clarify the existing appointment. If the caller wants a different time, that is a new workflow decision. If the write is still pending, the application should preserve that uncertainty instead of improvising a result from the assistant's wording.

My Twilio field notes describe telephony as an integration boundary while the application owns business state and outcomes. Interruption handling is a specific reason to maintain that separation. Spoken text can describe an operation, but it is not the operation's source of truth.

Tune turn-taking around the kind of interruption

There is another distinction before history reconciliation even begins: did the caller intend to take a turn?

Twilio's September guidance separates deliberate barge-in, brief acknowledgments such as “uh-huh,” and background noise. Its discussion of sensitivity and backchannel controls illustrates why a single “stop when sound appears” rule can produce an awkward agent. But suppressing too much can make it difficult for someone to correct a mistaken date or stop an unwanted explanation.

For a booking assistant, I would test an explicit correction, a brief acknowledgment during an explanation, and a caller beginning a new question. Those scenarios need different observations. Count whether the agent yielded when appropriate, whether it resumed with an accurate history, and whether the underlying booking remained correct. Fewer interruptions alone would be a misleading success measure.

This affects how teams evaluate voice products. A smooth greeting and low response latency leave important behavior untested. The caller can change direction halfway through a sentence, while generation, playback, and an API operation are each at different stages.

A useful call record should let an operator reconstruct those stages without guessing which words reached playback or which action completed. That is where interruption handling becomes an operational feature: the next response, and the person reviewing the call afterward, need a truthful account of what has happened so far.