Preparing a call flow is not writing a script. What gets said is the other person's decision; what you can decide is how that conversation is received. What to ask first, how long to wait when they pause, and what not to do when something is uncertain — preparation is mostly those things.
This guide assumes what the voice engine actually does. The pipeline is tuned Korean-first, browser and mobile are the transports live today, and telephony is built but key-gated. Settling those boundaries during preparation saves rebuilding the flow later.
You decide
What is asked first, how long the agent waits, where a person takes over
They decide
How much they say, in what order, and when they cut in
Before the call opens
Some things are already settled before the call connects. Greetings are pre-synthesized at startup: the moment right after connect is where the longest silence tends to appear, and putting a synthesis wait there reads to the other person as nothing happening at all.
Transport is decided here too. The browser connects over WebRTC; mobile connects through the app client. The telephony path has its architecture built but is key-gated, so it is integrated per deployment — we would rather say that plainly than imply you can dial in tomorrow.
Greetings are pre-synthesized at startup, and Korean filler audio steps in when a tool call runs long — the wait is engineered away.
Latency engineering — The silence at connect, and the one during a tool call
Shaping the conversation
The shape of a conversation is set by timing, not by a list of questions. The same question asked before someone finishes is an interruption; asked too late, the line has already gone empty.
How long to wait
Turn-taking is tuned for Korean. A 0.2s Silero voice-activity stop with backchannel handling means a listener's 네 or 음 is not treated as the end of their turn. In Korean conversation a backchannel is closer to a signal to keep going than a signal to stop.
Barge-in sits in the same layer. When someone genuinely starts speaking, synthesis stops mid-sentence; when it is only a nod, it continues. Without that distinction the agent is always getting one of the two wrong — either cutting people off, or talking over them after they have already cut in.
What fills a silence
When a tool call runs past about 0.8 seconds, Korean filler audio covers the gap. The point is not to buy time; it is to keep the other person from concluding the call has dropped.
Transport
Browser WebRTC or the mobile client connects
Speech to text
A vendor model, orchestrated, turns speech into text
Korean tuning
Turn detection, backchannel handling, normalization
Language model
A vendor language model composes the response
Synthesis
Spoken back over sticky failover between providers
Where a person takes over
This is the step most often left out. If you never decide where the agent stops, it will keep talking in exactly the place it should have stopped.
- Wherever risk scoring marked something as needing a look.
- Wherever output guardrails did not let a response through.
- Wherever the person explicitly asks for a human.
- Wherever a judgement would have to be made on unverified state — that path fails closed by default. Safety design covers how that rule is enforced.
A voice agent is not an emergency service and must not be relied on as one. In an emergency in Korea, call 119 for fire or medical help and 112 for police. That route belongs in the call flow itself.
A checklist before you start
These five surface most of what would otherwise force a flow rebuild, and they surface it before the first call.
- Is the transport settled — browser, mobile, or a telephony integration scoped for this deployment?
- Is the wait after someone stops speaking tuned to how Korean conversation actually runs?
- What covers the silence when a tool call runs long?
- Are the conditions for handing off to a person written down as a list?
- Does the work left after a call actually get closed out in the operator console?
More resources
What happens after the call, and how capability is opened in stages.