AI Engineer World's Fair 2026
Don't Let the LLM Drive - Ornella Bahidika & Joel Allou, Microsoft
About this talk
Ornella Bahidika and Joel Allou present Ace, a live AI voice tutor whose lessons are controlled by an external harness rather than an LLM. A state machine governs introduction, teaching, checking, grading, advancement, and wrap-up; each step gives the model a narrow task while application code validates outputs and controls transitions. They explain how this prevents skipped steps, loops, and premature completion, supports harness-controlled whiteboard interactions, and enables the smaller Claude Haiku 4.5 model to perform effectively within a constrained workflow.
Chapters
- 0:00Why multi-step AI tutors fail when the model controls the flow
- 0:41Lesson state machines, narrow contracts, and harness validation
- 1:24Constrained orchestration and smaller Claude models
- 3:35Harness-controlled whiteboard behavior and final control decisions
- 6:05Closing remarks
Talk 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.