Five Patterns, and You Own All Five
Prerequisite: Lessons 01-09, all six named failures and their fixes, plus compliance and evaluation. This lesson assumes you've seen every pattern once already; it doesn't teach anything new, it shows you the five shapes hiding inside the six failures. After this lesson, you can: name all five orchestration patterns this course teaches, trace each one back to the lesson that introduced it, and explain why none of them is waiting on a smarter model to work.
Nine lessons, six named failures. This lesson does no new teaching. It's the moment you step back and see that six failures were never six unrelated problems. They collapse into five patterns, and every one of them is something the engineer building the agent already owns.
The public failures are the same evidence, read narrower
This course opened by noting it isn't the first place these headlines have shown up. If you've taken Why Agents Fail on this site, you've already seen the full four-incident timeline (Air Canada, McDonald's × IBM, Klarna, Taco Bell) used there as evidence for a broader claim: these are harness failures, not model failures. That timeline lives there; this course won't reprint it.
What's worth adding here is a narrower, voice-specific reading of the two incidents from that timeline that actually ran through a spoken or phone-adjacent channel: Air Canada's chatbot and McDonald's drive-through AI. Both read differently once you've spent nine lessons on concurrent systems instead of chatbots in general. Air Canada's hallucinated refund policy being ruled binding is what lesson 07 spent an entire lesson on: a model that was allowed to be the source of a customer-facing fact instead of state as source of truth being the only thing permitted to speak. McDonald's drive-through AI, pulled after wrong orders piling up under real-time pressure, reads through this course's lens as a system making an effectively irreversible decision (the order that's about to be handed to a car) inside a live, turn-taking interaction with no undo: the same shape lesson 03's turn-taking and lesson 05's cooperative cancellation exist to prevent. Klarna and Taco Bell, by contrast, are chat and order-flow incidents: real evidence for the harness-failure claim generally, but weaker fits for a course specifically about the phone.
None of these were unserious teams. Read through this course's lens, they didn't fail because the model was insufficiently capable. They failed in a concurrent-systems-shaped way: state lost at a boundary, a decision executing at the wrong moment, a channel with no undo. That's this course's own claim, sitting on top of evidence already on the record elsewhere on this site.
Six failures, five patterns
Here's the collapse. Six named failures across this course resolve into five reusable patterns, because one pattern, progressive control, turns out to be the shared gate shape behind three separate failures, not three different fixes.
| # | Pattern | From | What it fixes |
|---|---|---|---|
| 1 | Semantic turn-taking | Lesson 03 | "Was that a complete thought?" sitting above raw ASR endpointing, so the agent doesn't cut a caller off mid-sentence just because they paused. |
| 2 | Two-tier interrupt classifier | Lesson 04 | A fast word-count path plus a small LLM with context, so the system can tell a real interruption from a backchannel like "mm-hm" without either one working like a chat tool call. |
| 3 | Cooperative cancellation | Lesson 05 | One shared cancellation token, checked at every safe point by every in-flight operation, so a "stop" mid-tool-call actually stops the reply instead of letting a stale answer play anyway. |
| 4 | State as source of truth | Lesson 07 | The LLM picks which tool to call; the application, not the model, writes and owns the state that gets spoken aloud, so a hallucinated number is structurally incapable of reaching a customer's ears. |
| 5 | Progressive control | Lessons 06, 08, 09 | Agentic by default, with a deterministic hard gate at the seams where being wrong is expensive: the wrap-up gate before a call can end (06), the validated-envelope gate before a transfer can fire (08), and the disclosure gate before the LLM gets the mic (09). Three failures, one gate shape |
None of it is waiting on a better model
Not one of these five patterns is waiting on a better model. Every one is an orchestration-layer decision the engineer already controls today.
The takeaway
Voice agents are concurrent systems, not turn-based ones.
The components (ASR, TTS, the LLM itself) shipped; they're increasingly things you buy rather than build. Your leverage is the orchestration layer wrapped around them, and you own it entirely. Latency, not intelligence, is what drives abandonment, which is why lesson 09 insisted on measuring p95 instead of an average that hides the calls that actually made someone hang up. And across every failure in this course, the fix came back to the same instinct: let the LLM pick the tool, never the truth.
If your framework assumes the user hits a "send" button when they're done talking, voice will break it in ways that look like model failures but are really architecture failures. Now you know which five patterns close that gap, and which lesson to reopen when you need the mechanics again.
That's all nine lessons. Revisit any one of them from the course overview, or start applying the five patterns to the voice agent you're actually building.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
