AI Engineer World's Fair 2026
Your Voice Agent Doesn't Need a Frontier Model
Read the talk
Your Voice Agent Doesn’t Need a Frontier Model
Ace keeps its voice tutor responsive by moving lesson state, mastery tracking, and next-step decisions into code, leaving a small model to turn those decisions into speech.
From a talk by Joel Allou and Ornella Bahidika
The pause is the problem
A student asks a voice tutor a question. The tutor goes silent. Is it thinking, or has the app stopped working? For Ornella Bahidika and Joel Allou, who built the live AI voice tutor Ace, that ambiguity is the opening design problem. Bahidika describes even a one-second pause as enough to make the interaction feel broken.
When an answer feels wrong, reaching for a smarter, larger model is an understandable response. But a voice application also has to preserve the rhythm of conversation. Ace’s target is to start talking in about 950 milliseconds. In that budget, a model that spends a full second thinking has already waited too long, however good its eventual answer. The target is Ace’s design constraint, rather than a universal threshold for conversation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the model a turn summary, not the whole lesson
Ace makes a small model viable by taking responsibilities away from it. The surrounding system tracks what happened in the lesson, what the student knows, and what should happen next. Every turn, it hands the model a summary. The model’s remaining job is to express the prepared result conversationally.
Allou uses Anthropic’s Claude Opus 4.7 as the frontier-model example, initially calling it Claude 4.7. Such a model can reason through a lesson, interpret a student’s question, and work out an answer. But doing that reasoning during the conversational turn can consume the seconds the voice interface cannot spare. Ace moves that work outside the speaking model.
A state machine encodes anticipated lesson scenarios and coordinates transitions between steps. An additional intelligent layer derives the student’s mastery and helps determine whether the lesson is complete. Together, these components decide the next action, the content to display, and how a question should be answered. Their output goes to the model to verbalize. This separation makes the speaking model a consumer of lesson decisions instead of the owner of lesson progression.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The same question, two different systems
The recorded comparison starts with Opus 4.7 without Ace’s implementation. A simple question leaves the model visibly thinking before returning an answer. The second example asks the same question using the smaller Haiku 4.5 with the surrounding architecture in place.
| Configuration | Reported response |
|---|---|
| Opus 4.7 without Ace’s scaffolding | Allou describes a couple of seconds to return an answer. |
| Haiku 4.5 with Ace’s scaffolding | Allou reports an answer in about 900 milliseconds. |
Both the model and the scaffolding change, so the comparison illustrates the combined design rather than isolating either contribution. The recording does not specify the timing boundaries or repeated-trial conditions; the reported response time should not automatically be read as time to first text token or first audible speech.
Allou attributes the improvement to moving logic and reasoning into code before the speaking model is called. He also describes the smaller model as cost effective, without supplying cost figures. The visible tutor result shows a lesson titled “The Eight Parts of Speech,” alongside chat messages and a developer panel. The interaction feels almost instant to him because the decisions needed for the response have already been made.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Pay for structure in code
The smaller model creates its own engineering obligation. Allou reports that Haiku 4.5 without scaffolding tends to drift over long structures and needs strict rules to stay organized. Scaffolding is the price of narrowing the model’s job. He frames that price as development work paid in code, rather than reasoning performed afresh on every conversational turn. His selection rule is to choose the fastest model the latency budget allows, then spend the remaining effort on scaffolding.
That work means enumerating scenarios, defining transitions, and deciding how each situation should be handled. A small TypeScript teaching example can make the boundary concrete. Suppose a parts-of-speech lesson asks the student to identify a noun. An upstream evaluator supplies correct; the transition function updates lesson state and prepares the speaking instruction:
typescript
type LessonState = {
step: "noun-practice" | "verb-practice";
nounMastered: boolean;
};
type Evaluation = {
answer: string;
correct: boolean;
};
function handleNounAnswer(
state: LessonState,
evaluation: Evaluation,
) {
if (state.step !== "noun-practice") {
throw new Error("Expected noun practice");
}
const next: LessonState = evaluation.correct
? { step: "verb-practice", nounMastered: true }
: { ...state };
return {
state: next,
display: evaluation.correct ? "Verbs" : "Nouns",
speakingSummary: {
studentAnswer: evaluation.answer,
correct: evaluation.correct,
instruction: evaluation.correct
? "Confirm the noun answer, then introduce verbs."
: "Explain that a noun names a person, place, or thing; ask again.",
},
};
}
const preparedTurn = handleNounAnswer(
{ step: "noun-practice", nounMastered: false },
{ answer: "cat", correct: true },
);
Here, the example’s deliberately simple mastery rule advances after one correct answer. Ace’s actual mastery algorithm is not specified. The architectural point is the handoff: preparedTurn contains the next state, display choice, and speaking summary before any language generation occurs. The model receives the prepared instruction; it does not choose the transition or assign mastery.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A small model inside a larger system
Allou extends the pattern beyond voice tutoring to other real-time applications where latency matters, and to high-volume workloads where repeated reasoning carries a recurring cost. The surrounding system owns the durable structure: state, scenarios, decisions, and progression. The model supplies the language at the point where language is needed. In that architecture, the model can become the smallest part of the system while the application remains capable of guiding a complete interaction.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Anthropic's launch announcement for Opus 4.7, covering capabilities, availability, pricing, and reasoning-effort controls.
Anthropic's introduction to its small Haiku 4.5 model, including low-latency use cases and launch pricing.
Further reading
Metric definitions and instrumentation examples for separating model, speech synthesis, and end-to-end conversational latency.
Read the complete timestamped transcript
- 0:00
Hi. I'm Ornella, and that's Joel. And we built Ace, a live AI voice tutor. It run on a small model on purpose, and I want to tell you more why that's not a compromise.
- 0:14
Quick gut check. That silence on a voice call, that's the difference between a tutor and a broken app. When a voice agent pause for even a second, your brain says it's dead.
- 0:31
So when the answer feel a little off, every instant stay crates for the smartest, biggest model. In voice, that instant is actually a back quad.
- 0:44
Because our budget was never IQ, it's millisecond.
- 0:49
The AI model need to start talking in about 950 milliseconds. A frontier model that think for a full second has already lost the room, no matter how good the answer is.
- 1:04
So we made the model small and took the hardest po- jobs away from it. It doesn't decide when happen... what happened in the lesson. It ha- it doesn't track what the student knows.
- 1:17
It doesn't plan what's next. We have a system in place to do that, and it hands the model a summary every turn. What's left for the model is one thing it's really good at, talking, and that's iterate.
- 1:32
Joel, go on and show them what it actually feel like.
- 1:36
Yeah. If maybe I can add some color to what Ornella was mentioning. So if you think about the models of today, especially the frontier model, let's take Claude 4.7, which is, uh, from Anthropic.
- 1:49
The model is really good at reasoning. You can give it a problem, in this case a lesson, and it can reason through it, it can reason through what the student is asking, and it can come up with the answer.
- 2:00
But that is actually precisely the problem because the reasoning can take couple of seconds, and those seconds are really valuable when you are building voice applications. So what we are doing is saying, "Hey, let's extract all of the thinking away from the model so that the model focuses on only what matters," which is speaking, in our
- 2:24
case. So all of the thinking is extracted into a state machine. So for Ace, we have thought about all the scenarios that are needed for a lesson. We have built a state machine that is able to coordinate each step to the next, and we've also added intelligent layer on top to derive some of the mastery that a
- 2:45
student might need for the lesson to be complete. So everything, when it comes to what happens next, when it comes to what needs to be displayed, when it comes to how to actually answer a question, it's all done outside of the model, and we simply feed that output to the model to speak out.
- 3:07
And so let's go ahead and look at an example and see how that works in real time. So the first video here is without the implementation we've done. So it's a simple Opus 4.7.
- 3:19
We ask a very simple question, and as you can see, the model is thinking, it's reasoning, and it takes couple of seconds to return the answer back to the user.
- 3:28
In this video, we've added everything we just talked about on Haiku 4.5, which is a much smaller model. Same question, but now you see that the answer comes in about 900 milliseconds.
- 3:42
And so that's the beauty of building around the model. So by removing all of the thinking, all of the logic, all of the reasoning from the model and actually putting it within the code, we actually saved a lot of time and allows us to use smaller models, which are cost effective and actually better at real-time voice applications.
- 4:04
And as you can see, this feels almost instant. And again, that's because all of the smart parts have already happened prior to the model actually speaking.
- 4:15
But I have to be honest because this isn't necessarily free. It has a cost, right? A small model like the Haiku 4.5, if it doesn't have any scaffolding, tend to drift on long structure and really needs strict rules in order to be able to stay organized.
- 4:35
So the scaffolding piece is the price. But the good thing is you pay it once and in code, right? Not on every single turn. So here's the rule: pick the fastest model that your latency budget allows, and then spend the rest of your time actually building the scaffolding.
- 4:54
So in our case, right, maybe you build a state machine. You build the reasoning process. You think about scenarios. What happens if this happens? How should your model handle it?
- 5:04
Everything that comes with the logic, everything that comes with the harnessing, you do that outside of the model and then allowing the model to focus on that one thing that it's really good at.
- 5:16
And so that's true for voice applications like Ace. That's true for real-time applications where latency is of priority, and that's really true for anything that is high volume, right?
- 5:28
In those cases, the model is the smallest part of the system. So this is Joel and Ornella, and we are building Ace again. And if you have any questions, let us know.
- 5:41
Thank you.
- 5:42
Thank you.