The cascaded approach: modular, swappable, interpretable
The architecture described throughout this course so far, separate ASR, LLM, and TTS components chained together, is called a cascaded pipeline, and it's still the dominant way voice agents are built. Its biggest advantage is modularity: each component can be developed, evaluated, and swapped independently. A team can upgrade to a better ASR model without touching the LLM, switch TTS voices without retraining anything else, and debug problems by inspecting the intermediate text at each seam, since the transcript and the LLM's text response are both directly readable. That interpretability also matters for safety and business logic: content filtering, business rules, and tool-calling logic can all hook into the plain text representation sitting between the audio stages.
The cost of that modularity is exactly the latency-stacking problem this course has spent most of its lessons on. Every seam between components is a place where information has to be serialized down to text and handed off, discarding information that existed in the original audio, like tone, emphasis, hesitation, or emotion, none of which survive the trip through a text transcript. The LLM only ever sees words, never how they were said, and the TTS stage has to guess at prosody from text alone rather than inheriting it from how the user actually spoke. Cascaded systems are also, definitionally, at least three separate places where latency and error can accumulate.