A harness should own the flow of a multi-step agent because prompting alone does not prevent skipped steps, loops, or premature completion.
2
Ace models a lesson as a state machine and gives the language model a narrow contract for each step.
3
Moving decisions outside the model lets Ace use a smaller model while saving money, time, and latency.
Summary
Ornella Bahidika and Joel Allou describe Ace, a live voice tutor that runs lessons through a harness rather than letting the language model control the flow. The lesson is represented as a state machine with stages such as intro, teach, check, grade, advance, and wrap. At each stage, the harness gives the model one narrow task and validates its output. It decides whether the lesson is complete, whether the student got the answer right, and what happens next. The speakers argue that this control belongs outside the model because models can declare success early, skip steps, or loop. They also explain that the approach lets Ace use Haiku 4.5 instead of a larger model such as Claude Opus 4.7, while saving money, time, and latency. They apply the same idea to whiteboard actions, queue clearing, coding agents, operations runbooks, and onboarding flows.
Reliability problems in flow agents are control problems
Ornella Bahidika describes what happens after a multi-step agent leaves the demo: a real user may encounter an agent that declares itself done halfway through, skips a step, or loops. The first response is often to strengthen the prompt and add more instructions. Bahidika argues that this misses the source of the problem. The model is good at delivering a particular response, but it is poor at remembering where it is in a sequence. Her comparison is that the model is the talent and the harness is the director.
Ace breaks a lesson into intro, teach, check, grade, advance, and wrap. Each step sends the model a narrow contract: perform one action and return the required result. The harness validates what comes back, advances the state, and chooses the next step. The model does not decide where the lesson is. This structure keeps the model focused on the current action instead of asking it to remember the whole procedure.
Joel Allou says teams often use a frontier model for the thinking, processing, and everything in between. That approach is less effective for a live tutor, which needs to be reliable, cost-effective, and fast. Ace instead builds the required steps in the harness and provides the model only the input needed for the current scenario. The state machine defines the current step, possible next steps, and the concrete information the model receives at that moment.
Constrained execution lets Ace use a smaller model
Because the harness confines the model to a specific action, Ace can rely on Haiku 4.5 rather than a larger model such as Opus 4.7 from Anthropic. Allou says Haiku 4.5 has less reasoning capability, but the surrounding harness still lets it perform at the expected level. He connects that choice to lower cost, less time, and lower latency. The control structure carries part of the work that would otherwise be left to a more capable model.
The harness owns lesson completion, grading, and progression
For Ace, the speakers moved three groups of decisions outside the model. The system determines when the lesson is done, whether the student actually got the answer right, and what comes next. The model receives an input and returns an output for the action assigned to it. It can propose an action, but the harness makes the final decision. This prevents the model from quietly deciding that a lesson is complete or advancing without the required check.
The same pattern covers actions around the conversation
The lesson logs show separate harness logic for a section, whiteboard drawing, clearing the queue, and ending the lesson. Each part gives the model instructions about what to speak about or what action to perform, then handles the result outside the model. Allou says new scenarios are incorporated into the state machine and the lesson rather than left to the model's general judgment.
Control flow should leave the model when reliability is uncertain
Allou offers a practical test: if an agent's reliability feels like a coin flip, take control flow out of the model. Build the decisions around it and feed it an easy input that produces a bounded output. He applies this idea beyond Ace to coding agents, operations runbooks, and onboarding flows. The model can still talk, but it should not drive the sequence.
"Don't let the model talk, right? Or actually let it talk, but don't let it drive."05:39
Who should watch
You are building a multi-step agent that sometimes skips steps, loops, or declares completion too early.
Your voice, coding, onboarding, or operations flow needs the model to produce responses without owning the sequence of actions.
You are deciding whether a smaller model can handle a bounded task when application code controls the surrounding state.
