Turn detection that doesn't talk over you

Updated 14 September 2026 with production numbers, the August incidents and figures.

A voice agent has to make one decision hundreds of times per call: is it my turn? Get it wrong one way and it talks over the caller; get it wrong the other way and it sits in silence while the caller wonders if the line dropped. Talkif's turn-taking is layered: a voice-activity detector and a local turn detection model decide when the caller has stopped; a word-count gate decides whether what the caller said while the bot was talking counts as an interruption; two guards keep the greeting from being killed by noise; and, optionally, the language model itself gives the final verdict on whether a thought was complete. Over the last 30 days of production, the end-of-turn decision — from the caller's last sound to the bot being released to answer — took a median of 530 ms, and 36 % of the bot's turns were interrupted by the caller. The other half of feeling like a person, answering fast, is in why our bots start talking in under half a second.

The bar: people overlap less than five per cent of the time

Human conversation is tighter than any turn detector. Stephen Levinson's review of the turn-taking literature puts it plainly: "less than 5% of the speech stream involves two or more simultaneous speakers (the modal overlap is less than 100 ms long), the modal gap between turns is only around 200 ms" — and the only way to manage that is that "one must plan while still listening and predicting what the rest of the incoming turn will contain" (Levinson, 2016). People also lengthen syllables at the ends of turns, and listeners use that as a "Go" signal.

A bot cannot read the caller's face and, over a phone line, gets a fraction of the prosody. What it has is silence, the words so far, and a model trained on what turn endings sound like. The design question is how to combine those without either talking over people or leaving them hanging.

Silence is a hint; the turn model decides

Two hundred milliseconds of silence is where the decision starts, not where it ends. The voice-activity detector (Silero VAD) fires after 200 ms without speech; that hands the last three seconds of audio to a local turn-detection model that answers one question — does this sound like the end of a turn, or a pause in the middle of one? If it says "end", the caller's turn is released and the model starts generating. If it says "pause", the bot keeps listening, up to three seconds of silence, before giving up and treating it as an end anyway.

Marcus, of Daily's client SDK team, describes what a native-audio turn model adds over a silence timer in Daily's post on its own open model: "This allows us to make decisions using the intonation and pace of the user's speech — which provide essential cues about the user's intent — rather than just the words themselves" (Daily blog, July 2025). That is the distinction the figure above turns on: the 200 ms is a timer, the pause-or-end verdict is a model, and the three seconds is the timer's second job as a fallback.

Both models are loaded before any call starts, so this decision costs inference, not startup. Measured over 566 bot turns between 14 August and 12 September 2026, the gap from the caller's last sound to the turn being released was a median of 530 ms and a p90 of 3.2 s — the long tail being, in the main, the three-second fallback firing on pauses the turn model judged incomplete. The pipeline framework we build on supplies the detector and the turn model; what we decided is that the turn model is always on and never customer-configurable, because a flow that turns it off sounds worse for everyone on it.

Barge-in: not every word is an interruption

While the bot is speaking, the caller says "mm-hm", or "yes", or "right". A system that stops talking on any voice activity stops for all of those, mid-sentence, and the conversation turns into a stutter. The gate for this is a word count: while the bot is speaking, the caller's speech must reach n recognised words before it counts as an interruption; when the bot is silent, one word is enough. Backchannels pass under it; real interruptions clear it.

That gate is framework code and it is off by default; a flow opts in with a number. The part that took us a while to get right is how it composes with the rest. Turn-start is an "any of these" decision across several strategies, and the default set includes one that starts a turn on voice activity alone. Prepend the word gate to that list and it does nothing — the voice-activity strategy fires first, before the word count is even known. We found this in the evaluation harness rather than in production: a test where the bot counts to ten and the caller says two words should complete the count, and with the gate merely prepended it did not. The rule now is that when a flow sets a minimum, the word gate is the only turn-start strategy, and the evaluation checks the transcript word by word rather than asking a model whether the run "looked right" — which is how the first version of that test passed while the interruption was still firing.

Two guards on the greeting

The greeting is the most exposed moment of the call, for a reason that only appears once you have made the greeting fast: the bot is ready to speak before any audio has reached the caller. Nothing the caller says in that window can be a response to the bot, and nothing they say can be an interruption of it — there is nothing yet to interrupt. It is pickup noise, or a mistranscription of silence.

The first guard holds the caller's input until the first bot audio has actually been sent. It exists because of a call in August 2026 that lasted nine seconds: a Turkish speech-to-text model emitted a common stock token on 1.2 seconds of silence, the transcript started a caller turn, the greeting was cut before a single frame of it was audible, and the language model — reading a context in which it had apparently been interrupted — called the end-of-call function. The only audio on that call was the goodbye. The second guard mutes the caller during the bot's first utterance, so a greeting that has started can at least finish. Both are on by default. A third, muting until the whole first turn completes, is available and off.

What happens to a cut-off greeting also changed. Before July, an interrupted greeting was flushed and nothing was written to the conversation context — which still said "greet" — so the model greeted again on the next turn, and the next; we saw it three or four times in a row on production calls. Now an interrupted turn is backfilled into the context with what was generated, marked as not delivered, so the model knows what it meant to say and knows the caller did not hear it.

Muting during a tool call — available, and off

While a flow function runs — a lookup against your API, a booking — the bot is waiting on something that can take up to 35 seconds. A caller who fills that silence with "hello? are you there?" would, in a naive system, start a new turn, and the result of the lookup would arrive into a conversation that has moved on. The pipeline can mute the caller for the duration of the function call: input during it is dropped, not queued.

It is off by default, and per flow, because it is a real trade-off. Muted words are lost to the model — the transcriber still hears them and the call's transcript events carry them flagged as gated, but the agent will not respond to them. For a flow whose functions are fast, an un-muted caller is better served; for one whose functions call a slow backend, a muted one is. The setting sits next to the others in the flow's interruption block, which is where every choice in this post lives: the word minimum, the four mute strategies, and the completeness gate below.

The final arbiter, if you want one

The last layer is the one that sounds least like signal processing. With it on, the language model itself decides whether the caller's turn was complete: the first token of every reply is one of three markers — complete, cut off mid-thought, or needs more time — before any speakable text. On "complete", the reply is spoken. On the other two, the text is suppressed, the marker is kept in the context, and a timer starts; if the caller says nothing more within five seconds (or ten, for "needs more time"), the model is asked for a brief natural prompt instead. A "complete" that arrives while the caller is audibly still speaking is treated as stale and downgraded. The point is the distinction the model can make and silence cannot: "That's a really good question" is grammatically finished and conversationally not.

This is framework machinery, and it is off by default here. It costs a model round-trip per turn, and we have not yet measured its accuracy on our calls well enough to turn it on for everyone — which is the honest reason it is a per-flow switch. The acoustic turn model remains the arbiter on flows that leave it off, and it is not bad company: it is the thing behind the 530 ms.

What this does not solve

The three-second fallback is a blunt instrument: a caller who pauses to think for four seconds gets answered, and the p90 above is largely that fallback firing. Speech-to-speech models, which take audio in and produce audio out, bypass this whole layer and bring their own turn-taking, so none of the flow settings apply to them. And no gate helps with a caller who genuinely changes their mind mid-sentence — the model has to handle that in the conversation, as a person would.