How it works

Built so the caller never hears dead air.

Phone conversations fail on latency before they fail on intelligence. The design target is a reply within about 800 ms of the caller finishing — and every call records its own per-turn timings, so it is checked, not assumed.

Start free Read the docs

The path of a turn

The fast model decides, every turn.

Every turn is heard by streaming transcription and turn detection. Then the talker either answers straight away, or starts a tool job and keeps talking. Both paths end in streamed speech.

trigger

The caller speaks

An inbound call on your number, an outbound call from a campaign or the API, or a test call from the browser.

inline

Answered straight away

Questions, clarifications and small talk are answered from the agent's own knowledge — no tool round-trip in the way.

background

Reasoner and tools, in parallel

Calendar, CRM or any MCP tool runs asynchronously while the talker says something useful — never dead air, never the same filler twice.

The layers

What happens inside one turn.

Six pieces, each shaving time off the gap between the caller finishing and the agent speaking.

Streaming transcription

Speech is transcribed as it arrives rather than after each sentence, so the transcript is ready the moment the caller stops.

Semantic turn detection

A small model reads the partial transcript and the audio to decide when a turn is really over — it does not cut in on “my email is john… at…”, and it does not wait a fixed second of silence either.

Talker and reasoner

A latency-optimised talker owns the conversation. Anything slow — availability, a CRM lookup, an MCP tool — is handed to a stronger reasoner as a background job; its result comes back as the next thing the talker says.

Speculative prefetch

While the caller is still speaking, likely needs are fetched early (“they said Tuesday” → Tuesday’s free slots), so the answer is often ready before it is asked for.

Filler that is not canned

Three layers: soft thinking sounds, a bank of short acknowledgements never repeated within a call, and contextual lines from the talker — “let me check Tuesday afternoon…”. If a tool is still running after a couple of seconds, the agent asks a useful question instead.

Streamed speech

The reply is synthesised sentence by sentence and starts playing before it is complete.

Tool latency classes

Every tool declares how slow it is.

The class decides whether the agent waits, talks while it works, or follows up after the call — so a slow CRM never becomes an awkward silence.

Instant — under ~300 ms

Runs inline: hanging up, opt-out, reading back a detail. No filler needed.

Slow — up to a few seconds

Runs in the background while the talker says something useful. Booking, availability and most MCP tools.

Offline — longer, or needs a human

The agent says what happens next — “I’ll text you the confirmation” — and the result is sent after the call.

per-turn latency · one call

Checked, not assumed

Measured on every call.

Latency claims are cheap. So every call carries its own timings — you see exactly how fast your agent was, turn by turn.

Design target: a reply within about 800 ms of the caller finishing
Per-turn latency recorded on every call record
In the dashboard, and in GET /api/v1/calls/{id}
Alongside the transcript, outcome, actions and cost

For developers

Set the class per tool.

Register an MCP server and every tool gets a policy: read or write, spoken confirmation, latency class and a timeout. After the timeout, the agent says it could not complete the action.

Tool policy reference MCP overview

tool-policy.json

// Per-tool policy — the latency class decides what the caller hears
{
  "kb.search":       { "mode": "read",  "latency": "instant", "timeout_ms": 1500 },
  "crm.create_note": { "mode": "write", "latency": "slow",    "timeout_ms": 8000 },
  "orders.refund":   { "mode": "write", "latency": "slow",    "confirm": true }
}

FAQ

Latency questions.

See what the runtime includes on the AI phone agent product overview, or how data stays in region on security & Swiss data residency.

How fast does the AI voice agent reply?

The design target is a reply within about 800 ms of the caller finishing. We do not ask you to take that on trust: every call records its own per-turn latency, visible in the dashboard and returned by the API.

Will it cut the caller off mid-sentence?

Turn-taking is decided by a semantic turn detector that reads the partial transcript and the audio, not a fixed silence timer — so a pause in “my email is john… at…” is held, and a finished sentence is answered promptly.

What does the caller hear while a tool is running?

Slow tools run in the background while the talker keeps the conversation going with a contextual line such as “let me check Tuesday afternoon…”. Acknowledgements are never repeated within a call, and if a tool is still running after a couple of seconds the agent asks a useful question instead.

What if a task takes longer than a phone call should?

Mark the tool as offline. The agent tells the caller what happens next — for example that a confirmation will follow by text — and the result is sent after the call.

Can I test the latency myself?

Yes. Build an agent and use the test-call button to talk to it from your browser, then open the call record to see the timings for each turn.

Talk to it yourself.

The fastest way to judge a voice agent is to interrupt it. Build one, call it from your browser, then read its per-turn timings.

Start free See pricing