Engine modes

The mode setting controls the audio architecture of the assistant. All three modes work with prompts and flows alike.

​

Pipeline (default)

Classic three-stage architecture: speech-to-text → LLM → text-to-speech. Choose each stage from the models available to your workspace.

• Full control: pick STT, LLM, and TTS independently, including fallback chains per stage.
• Widest model and voice selection, best multilingual coverage.
• Turn detection via a semantic turn model or voice-activity detection (configurable).

Use it when you want maximum control over quality, cost, and language behavior. This is the right default for production telephony.

​

Realtime

A single speech-to-speech model listens and speaks directly — no separate STT or TTS.

• Lowest latency and very natural prosody (laughter, hesitation, tone).
• Voice selection comes from the realtime model.
• Turn detection can be robust, semantic, or adaptive when the selected voice mode supports it. Other voice modes manage turn timing automatically.
• Fewer knobs: voice library and per-stage fallbacks do not apply.

Use it when conversational feel matters more than fine-grained control — demos, concierge experiences, voice-first products.

​

Half-cascade

A hybrid: a realtime model does the listening and thinking (text-only), while a separate TTS voice does the speaking. Half-cascade has its own text-capable realtime model selection, independent of the full realtime selection. Changing it never changes the separate TTS voice.

• Realtime-grade understanding and turn taking, combined with your chosen TTS voice — including cloned or brand voices.
• Output voice is configured exactly like in pipeline mode.

Use it when you want realtime responsiveness but need a specific voice the realtime model doesn’t offer.

​

Realtime turn detection

For compatible realtime and half-cascade assistants, choose how the assistant decides that the caller has finished speaking:

• Robust (VAD) — responds after a clear pause. Fast and predictable.
• Semantic — waits until the caller seems to have completed their thought, even with a mid-sentence pause. Response eagerness controls how soon it answers.
• Adaptive — short acknowledgements such as “mhm” or “okay” do not stop the assistant, while a clear interruption lets the caller take over. You can also tune minimum silence, voice sensitivity, interruption duration, or disable interruptions.

Assistants that do not expose these choices continue to manage turn timing automatically. Existing assistants remain on Robust (VAD) until you select another mode.

​

Reliability behavior

​

Quick comparison

​

Troubleshooting

​

Losing context mid-call

The assistant asks for information already given, or seems to miss something said earlier. This is a comprehension issue, not an engine-mode dial. Keep the facts it needs in the knowledge base rather than only in the prompt, and in a flow, use collect nodes so captured answers become call variables the rest of the flow can reference instead of asking again. If your plan lets you pick the language model yourself, a stronger one also holds a long conversation together more reliably.

​

Unnatural conversation flow

Awkward pauses, the assistant talking over the caller, or the exchange feeling robotic. Try Realtime or half-cascade for more natural prosody and turn-taking, tune interruption handling and filler phrases so waits get bridged instead of going silent, and revisit the turn-detection mode above if the assistant answers too early or too late.

​

Repetitive responses

The assistant reuses the same phrasing or confirmation across a call. This comes from the prompt, not the engine mode — add an explicit instruction such as “vary your phrasing, don’t repeat the same sentence twice” and test a few different conversation paths to see where it recurs.