AI Engineer World's Fair 2026
Don't Let the LLM Drive - Ornella Bahidika & Joel Allou, Microsoft
Read the talk
Don't Let the LLM Drive
Ace’s live voice tutor puts lesson progression in a state machine, leaving the model to perform bounded actions while a harness validates results and decides what happens next.
From a talk by Ornella Bahidika and Joel Allou
Before you start: Basic familiarity with LLM applications and application state is helpful; the TypeScript example illustrates who owns a lesson transition.
The lesson ends halfway through
A multi-step agent completes its demo perfectly. Then a real user arrives, and halfway through the interaction it declares itself finished, skips a state, or loops. For Ace, the live AI voice tutor built by Ornella Bahidika and Joel Allou, that failure would mean losing the structure of a lesson that needs to run from introduction to completion.
The tempting repair is to add more instructions: remember the steps, do not skip ahead, do not stop early. Bahidika frames the underlying issue as control flow. The model can deliver a good explanation without reliably tracking whether it is on step three of six. Her analogy separates the talent from the director: the model delivers the line; the surrounding harness keeps the production moving through the right sequence.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give each step a narrow contract
Ace organizes a lesson as a small state machine: intro → teach → check → grade → advance → wrap. Each step gives the model one bounded assignment and asks for its result. The harness then validates that result, advances the state, and selects the next assignment. The model does not determine the current lesson state.
A minimal TypeScript sketch of that boundary can make the ownership explicit. Here, a teach operation returns an explanation; only application code can move the lesson to check.
typescript
type Lesson = {
state: "teach" | "check";
topic: string;
explanation: string | null;
};
type TeachInput = {
action: "teach";
topic: string;
};
async function teach(
lesson: Lesson,
callModel: (input: TeachInput) => Promise<unknown>
): Promise<Lesson> {
if (lesson.state !== "teach") {
throw new Error("Lesson is not ready to teach");
}
const result = await callModel({
action: "teach",
topic: lesson.topic,
});
if (typeof result !== "string" || result.trim() === "") {
throw new Error("Expected a nonempty explanation");
}
return {
...lesson,
explanation: result.trim(),
state: "check",
};
}
The model supplies content, not a nextState field. An invalid response prevents this transition. The string check illustrates the validation boundary; Ace’s actual content-validation rules are not detailed in the talk.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Smaller assignments enable a smaller model
Allou starts with Claude Opus 4.7 as an example of a frontier model people might use for thinking, processing, and everything between. A live tutor has a more specific constraint: it must speak back and forth with students while remaining reliable, affordable, and fast. Handing the entire lesson to a powerful model leaves that model responsible for coordination as well as conversation.
The harness narrows that responsibility by answering three questions before each action:
- What step is active now?
- Which steps are allowed to follow it?
- What concrete input does the model need to perform only the current action?
This confines each model call to the work required at that moment, rather than asking it to reconstruct the lesson’s control logic.
Allou reports that Claude Haiku 4.5, despite having less reasoning capability than the larger model, meets Ace’s expected performance with this harness. He reports savings in money, time, and latency, but supplies no measurements or controlled tutoring comparison. The demonstration then turns to a recorded lesson, with harness logs displayed on the right side.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Control the operations around the conversation
The narrated recording shows that the harness covers more than the order of spoken exchanges. Allou identifies several operational responsibilities:
- Section instructions: Give the model the specific material to speak about and the action to perform.
- Whiteboard drawing: Handle the drawing actions that accompany the lesson.
- Queue clearing: Include explicit steps for clearing the queue.
- Lesson completion: Define how the lesson ends instead of leaving completion to an improvised model decision.
The completed screen offers Practice: Grammar Foundations and Back to Home, with the developer console alongside it. The individual operations come from Allou’s narration; the console text in this frame is too small to read in detail.
New scenarios become additions to the state machine and lesson logic. The model’s local job remains the same: receive an action-specific input and return that action’s output. Reliability therefore depends on the harness covering the situations the lesson can encounter, including operational steps that are easy to overlook when focusing only on the conversation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The model proposes; the harness decides
That division becomes consequential at three decision points in Ace:
| Decision | Harness responsibility |
|---|---|
| Is the lesson done? | Own the completion decision. |
| Did the student get it right? | Own the decision about correctness and intended learning. |
| What comes next? | Select the next step. |
A model output can be a proposal without becoming an authoritative state change. These decisions determine whether the tutor continues teaching, evaluates progress, or ends the lesson.
Allou says the questions and actions within these categories are engineered outside the model. His description of the model as not having to think concerns this bounded responsibility: it receives an input and produces an output, while the application owns the surrounding decisions. The talk does not specify the grading rules or how Ace establishes that a student has learned the material, so the architectural boundary is clearer than the assessment implementation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Move unreliable control flow into code
The same division can apply to coding agents, applications, runbooks, and onboarding flows. Allou’s diagnostic is qualitative: if reliable completion feels like a coin flip, examine how many workflow decisions the model owns. Move those decisions into the surrounding application and give the model simpler inputs for bounded actions.
The ending returns to the voice tutor with a useful self-correction: let the model talk, but do not let it drive. A model can explain, converse, and propose useful outputs while the harness remains responsible for where the lesson is, whether a result is acceptable, and what happens next.
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 release announcement for the larger model used as the talk's comparison point.
Release announcement covering Haiku 4.5's capabilities, launch pricing, and evaluation methodology.
Further reading
- Building effective agentsArticle
Practical workflow patterns, including predefined control paths and programmatic checks between model calls.
Read the complete timestamped transcript
- 0:00
Hi, I'm Ornella, that's Joel. And we built Ace, a live AI voice tutor that runs a full lesson, start to finish reliably. The trick is LLM is not in charge.
- 0:13
If you have shipped a multi-step agent, you know this moment. It's near the demo, then a real user gets in, and halfway through, the agent decide it's done, or skip a state or even loops.
- 0:26
The demo never show you that. And the first fix everyone reaches for is prompt is harder, add more rules. But reliability was never a prompting problem. It's a control problem.
- 0:41
Think of it this way. The model is the talent, and the harness is the director. The model is brilliant at delivering a line, but it's really terrible at remembering if it's on step three of six.
- 0:53
So we stop asking it to. A lesson is a small state machine with intro, teach, check, grade, advance, and wrap. Each steps hands the model a narrow contract. Do this one thing, return it.
- 1:10
The harness validates what comes back, advance the state, and decide what's next. The model never decide where we are. That's the design. Joel is going to show you the harness thing.
- 1:24
Yeah. So when we think about the frontier models of today, let's take for example, um, Opus 4.7 Cloud from Anthropic, you see that oftentimes people leverage the model for essentially everything.
- 1:40
For the thinking, for the processing, right? And for everything in between. While that can be good, it's not always effective in situation like ours where we are building a live AI tutor that is speaking back and forth with students, right?
- 1:57
For something like this, we have a need to actually build something that is reliable, something that is cost-effective, and something that is fast, right? So this is where the idea of leveraging the concept of harness engineering has come in, where instead of having a model that is really intelligent sort of go through everything for us, we will
- 2:21
build all of these steps that are needed and provide only the input required for the model to execute a specific scenario. So when we were building Ace, we actually thought very deeply about state machines, right?
- 2:35
What is the step right now? And what is the possible steps that could come after? And within each of the steps, what are concrete things that we can provide to the model so that it is confined to that specific action, it is confined to that specific step at that particular moment and only execute what needs to be
- 2:55
done. So by doing this, instead of having a very heavy model like a four point seven, we're actually able to rely on something like a Haiku four point five, which is a much smaller model, doesn't have as much reasoning capabilities, but because of the harnessing around it, is still able to perform at the level in which we
- 3:14
expect, saving money, saving time, and saving latency. So let's go ahead and play this recording, which will show us logs, um, about a particular lesson. So as you can see in this video, especially on the right side, we see logs on all of the different harnessing that are happening, right?
- 3:35
So for example, we see that there is harnessing for a section which provides input to the model about exactly what to speak about, what to do. We have harnessing about drawing on the whiteboard.
- 3:48
We have harnessing that deals with clearing the queue. We have steps to how to end the lesson and everything in between, right? So everything that would allow us to actually build the lesson in a way that is reliable, even if there's a new scenario that comes in, we try to incorporate that in our state machine.
- 4:09
We try to incorporate that with- within the lesson, right? So again, the model, all it worries about is given an input, it knows which action to take, and it provides the output of that action, right?
- 4:21
And so the model never really, um, um, has to think. It proposes, but ultimately it is the harness that decides. And so for his-- Ace specifically, there are three things that we wanted to think about.
- 4:33
Like when is the lesson done is one, right? Did the student actually get it right? Like, did they actually learn in the way they were supposed to? And what comes next, right?
- 4:41
And so everything that comes within those three categories, all of the different questions, all of the different actions that the models needs to take, we have engineered that outside of the model, right?
- 4:52
So again, it's an input. The model receives it and gives us an output, right? And so this is very, very important, and we have found this to be very remarkable, right?
- 5:02
So again, the, the... This is applicable to really everything, right? It's applicable to something like Ace that is a voice model. It's applicable to coding agents, to apps, runbooks.
- 5:15
Um, it's applicable to onboarding flows, right? The same rule applies, right? We want to find a way to not let the model think, but building abstractions around it. So a good way to, to remember on whether you should use this abstraction is essentially to think about the reliability of your agent, right?
- 5:35
If it's somewhat of a coin flip, then you wanna take the control flow out of the model. You want the model to not make as many decisions as it should, and instead build those decisions around the model and simply feed an easy input so that the model can easily produce an output, right?
- 5:53
So don't let the model talk, right? Or actually let it talk, but don't let it drive. So we're Joel and Ornella. This is Ace, and if you have any questions, please let us know.
- 6:05
Thank you.
- 6:06
Thank you.