arrow_backBACK TO BUILDING VOICEBOTS — TELEPHONIC & BROWSER, THE REAL ENGINEERING
Lesson 01Building Voicebots — Telephonic & Browser, the Real Engineering5 min read

Anatomy of a Voicebot

October 28, 2026

TL;DR

A voicebot is a loop of four stages: you speak → STT turns speech into text → an LLM decides what to say → TTS turns text back into speech → you hear it. One trip round the loop is a 'turn', and the whole game is making that turn fast (target under ~1 second) and natural (the bot waits its turn, and lets you interrupt). The single most important idea is that everything STREAMS and overlaps — the bot starts transcribing before you finish, starts thinking before STT is done, and starts speaking before it has finished thinking — so the stages don't add up into a long wait. Each stage is a swappable component (Lessons 4-7), and the same brain runs over a phone call or a browser (Lesson 2). Get this loop clear and the rest of the course is detail.

Before any transports, providers or frameworks, you need one clear picture in your head: a voicebot is a loop. You speak, it listens and turns your speech into text, it decides what to say, it turns that into speech, and you hear it — then round again. Everything else in this course (which transport, which STT, how to make it cheap) is detail hung on this loop. So let’s make the loop crisp, because once it clicks, the rest stops feeling like a pile of unrelated jargon.

The Four-Stage Loop

Here is the whole thing in one picture.

The voicebot loop: four stages in a circle, as fast as you can make them. You speak (microphone) → STT (speech to text) → LLM (decide reply) → TTS (text to speech) → back to you speaking. One 'turn', target under 1 second. Everything streams and overlaps: the bot starts talking before it has finished thinking (Lesson 8)

The four stages:

  1. You speak. Audio comes in — from a phone call or a browser microphone (Lesson 2). It arrives as a continuous stream of small audio chunks, not one big file.
  2. STT (Speech-to-Text). A speech recogniser turns that audio into text — “what is the housing scheme” (Lesson 4). For Indian use this has to handle many languages, accents and code-mixing.
  3. LLM (the brain). A language model reads the text, decides what to say, and often does something (looks up an order, checks eligibility, books a slot — Lesson 6). It produces the reply as text.
  4. TTS (Text-to-Speech). A voice synthesiser turns that reply text back into audio (Lesson 5) — in the user’s language, sounding as natural as you can afford.

Then the audio goes back out to the user, and the loop repeats for the next thing they say. One full trip around this loop — from the user finishing their sentence to the bot starting its reply — is a turn, and the quality of your voicebot is largely decided by two properties of that turn: how fast it is, and how natural the turn-taking feels.

The Two Things That Make or Break It

Speed. Humans are exquisitely sensitive to conversational delay. A gap of a few hundred milliseconds feels normal; a gap over about a second feels laggy, like a bad phone line, and people start talking over the bot or hang up. So the target for a turn is under ~1 second, ideally 600–900 ms. That sounds impossible when you add up the stages naively (STT takes time, the LLM takes time, TTS takes time) — and it would be, if you ran them one after another. Which brings us to the central trick of the whole course.

Natural turn-taking. A good voicebot knows when you’ve stopped talking so it can reply (not too eagerly, or it cuts you off; not too slowly, or it feels dead), and it lets you interrupt it — if it’s rattling off the wrong thing and you say “no, the other one,” it should stop and listen. That’s barge-in (Lesson 8), and a bot without it feels broken, like talking to an answering machine.

The Central Idea: Stream Everything

Here is the insight that makes sub-second voicebots possible, and it’s worth internalising now because it runs through every later lesson: the stages don’t run one-after-another — they stream and overlap.

  • STT is streaming: it transcribes as you talk, emitting partial results, so the moment you stop, the text is basically ready — it didn’t wait for you to finish and then start (Lesson 4).
  • The LLM starts generating its reply from the first token, and you can feed it the transcript the instant STT finalises.
  • TTS is streaming too: it starts producing audio from the first sentence of the LLM’s reply, so the bot starts speaking before the LLM has finished thinking (Lesson 5).

So instead of STT time + LLM time + TTS time added up into a long wait, the stages overlap — each one starts working on partial output from the one before. The bot is transcribing while you’re still talking, thinking while it’s finishing transcribing, and speaking while it’s still thinking. That overlap is how you turn what looks like a 2-second pipeline into a sub-second perceived response. We’ll make this concrete with a real latency budget in Lesson 8; for now, just hold the principle: never “wait for the whole thing” at any stage.

Everything Is Swappable (and the Brain Is Shared)

Two more structural facts that shape the whole course:

  • Each stage is a component you choose. STT, LLM, and TTS are separate pieces, often from different providers, and you’ll mix and match them (Sarvam STT with a cheap LLM and Sarvam TTS; or Deepgram with a premium LLM and ElevenLabs). An orchestration framework like Pipecat (Lesson 7) wires them together so you can swap one without rewriting the others. This modularity is what lets you tune for quality, latency and cost independently.
  • The brain is the same across channels. Whether the user is on a phone call or in a browser, the STT→LLM→TTS brain is identical — only the transport that carries the audio differs (Lesson 2). This is a huge simplification: build the conversation once, offer it over both a phone number and a web widget.

That’s the entire skeleton. A voicebot is: audio in → STT → LLM (which may call tools) → TTS → audio out, streamed and overlapped to feel instant, with each piece swappable and the brain shared across phone and browser. Every remaining lesson fills in one part of this picture — but if you remember only the loop and the “stream everything” principle, you already understand what a voicebot is.

Pitfalls to Avoid

  1. Thinking of it as request/response, not a loop. A voicebot is a continuous, interruptible conversation, not a series of isolated questions. Design for turns and barge-in from the start.
  2. Running stages sequentially. Waiting for STT to fully finish, then the LLM, then TTS, blows your latency budget. Stream and overlap every stage.
  3. Ignoring turn-taking. Getting “when has the user stopped talking?” wrong (endpointing) makes the bot either interrupt people or feel dead. It’s a first-class problem (Lesson 8).
  4. No barge-in. A bot you can’t interrupt feels broken. Plan for the user talking over it.
  5. Coupling the brain to the transport. If your conversation logic is tangled with phone-specific or browser-specific code, you can’t offer both. Keep the brain transport-agnostic (Lessons 2, 7).
  6. Underestimating the latency bar. “A couple of seconds” is not fine for voice; humans notice. Aim for under a second and measure it (Lesson 8).

Quick Recap

  • A voicebot is a loop: you speak → STT → LLM (which may call tools) → TTS → you hear it. One trip is a turn.
  • Two things decide quality: speed (target a turn under ~1 second) and natural turn-taking (good endpointing + barge-in).
  • The central trick is stream and overlap everything — transcribe while you talk, think while transcribing, speak while thinking — so stages don’t add up.
  • Each stage (STT, LLM, TTS) is a swappable component, and the same brain runs over phone or browser — only the transport changes.
  • Remember the loop and “stream everything,” and the rest of the course is detail.

Next lesson: the two ways a user reaches your voicebot — a phone call or a browser — and why the smartest design keeps the brain identical and swaps only the transport underneath.