Who Controls When Your AI Phone Assistant Stops Speaking?

When a small business commissions an AI phone assistant, “callers can interrupt it” is not a complete requirement. The owner and developer must make three separate decisions:

1. Can caller speech or keypad input stop a spoken reply?
2. Can the application replace a reply already playing?
3. Should the application receive caller input while that reply continues?

Twilio ConversationRelay assigns these behaviors to interruptible, preemptible, and reportInputDuringAgentSpeech. A fourth setting, echoPromptFiltering, addresses synthesized speech being mistaken for caller input.

This is a documentation-based explanation. No implementation, call test, timing measurement, or customer case study was performed. All examples below are hypothetical and untested.

The four controls at a glance

The practical distinction is stop, replace, or report. Caller input can be reported without stopping playback. The application can also replace playback without a caller interruption.

Caller-controlled stopping: interruptible

interruptible governs caller-initiated stopping. Its documented modes are:

• none: neither speech nor DTMF stops playback;
• dtmf: keypad input can stop playback;
• speech: caller speech can stop playback; and
• any: either speech or DTMF can stop playback.

These modes and their effect are defined in the ConversationRelay reference.

For commissioning purposes, decide which caller actions may stop each kind of reply. A spoken correction and a keypad selection may warrant different rules. Some messages may also need behavior that differs from the session’s general setting.

Twilio documents that ConversationRelay sends an interrupt message when caller speech interrupts TTS playback (WebSocket messages). That statement does not define individual field meanings, interruption duration, speech endpoint timing, or DTMF event behavior. Those details should not be inferred from JSON field names.

Application-controlled replacement: preemptible

preemptible answers a different question: can your application supersede media already playing?

When playback is preemptible, a subsequent text or play message from the application stops and replaces the current media (WebSocket messages). The application—not the caller—initiates this change.

Documented text messages can override the TwiML-level interruptible and preemptible settings for that message. Play-media messages also expose both controls. Twilio documents a default of false for preemptible on play messages, but that default should not be generalized to text messages or other settings (WebSocket messages).

This makes message-level behavior part of the commissioning decision. A business may want a general session rule while identifying particular text or media messages that require different treatment. The supplied documentation does not establish how unspecified fields interact with every possible runtime update, so requirements should stay within the documented overrides.

Reporting input without stopping playback

reportInputDuringAgentSpeech separates receiving input from stopping playback. It controls whether the application receives prompt and DTMF messages while the assistant is speaking. Its documented modes are also none, dtmf, speech, and any (ConversationRelay reference).

Twilio provides this specific configuration:

• interruptible="none"
• reportInputDuringAgentSpeech="speech"

With that combination, caller speech is sent to the application without stopping TTS playback (ConversationRelay reference).

Reporting input does not determine how the application should respond. One possible design choice would be to hold the reported input until playback finishes; another would require different application logic. Neither choice is defined as Twilio behavior by the supplied evidence.

Hypothetical, untested turn-taking example

Consider a hypothetical, untested appointment assistant:

1. The assistant begins describing available services.
2. The caller says, “I only need a repair estimate.”
3. If speech interruption is enabled for that reply, the caller’s speech stops TTS, and ConversationRelay sends the documented interrupt message.
4. During a later reply, caller interruption is disabled while speech reporting remains enabled. The caller speaks, so the application receives that input while playback continues.
5. The scheduling application then receives updated availability. If the current reply is preemptible, the application sends a later text message that replaces the current playback.

This sequence illustrates caller interruption, reporting without interruption, and application preemption. It does not represent tested timing or guaranteed production behavior.

Echo filtering addresses a separate problem

Synthesized speech can bleed into the caller’s microphone. Twilio says the speech-to-text provider might then transcribe the assistant’s own words, causing the assistant to interrupt itself or respond to its own speech (ConversationRelay best practices).

Twilio documents echoPromptFiltering as a mitigation. It can be enabled in <ConversationRelay> TwiML or changed during a conversation through a config message (ConversationRelay best practices). This is guidance, not a guarantee that false interruptions will be eliminated.

What to specify before development

The owner and developer should record:

• whether speech, DTMF, both, or neither may stop playback;
• whether interruption rules vary by message;
• whether caller input should be reported while playback continues;
• how the application should handle input received during playback;
• which media the application may replace;
• which text or play messages need overrides; and
• whether echo prompt filtering will be enabled and evaluated.

These choices belong in the requirements for a customer-service AI workflow, not in a generic “supports interruption” checkbox. They should also be considered alongside the project’s broader business technology and workflow requirements.

This decision does not cover speech-timeout values or defaults, exact interruption timing, carrier behavior, transfers, consent, latency measurements, costs, or suitability for a particular deployment.

If useful, talk through your workflow.

Sources and further reading

• https://www.twilio.com/docs/voice/twiml/connect/conversationrelay
• https://www.twilio.com/docs/voice/conversationrelay/websocket-messages
• https://www.twilio.com/docs/voice/conversationrelay/best-practices