Teaching a child in
We set out to build the first AI tutor to teach math and reading to kids ages 4-9. For AI to actually teach a five-year-old, pedagogy must be baked into the engineering. A child can't wait for a slow reply, can't read a chat interface, and can't unhear anything a model gets wrong. We wanted to share some of the learnings that shaped our architectural decisions building a real-time AI tutor.
A 2-second pause in conversation feels different to a child than to a developer, or even to an adult on the phone speaking to an automated agent. A couple of seconds is enough for a child's attention to wander and for learning to stop.<br>Good teachers manage this without pausing to think. They acknowledge a child immediately, even when they hold the answer back to let the child work. Teaching is matching the right approach to the current moment, and most approaches aren't answers.<br>When we set out to build an AI tutor for children ages 4-9, we wanted to build a tutor that actually teaches and not just a chatbot that responds quickly. We knew the constraint underneath would be hard, and that it wasn't optional: sub-second response on every turn. Most agents trade off speed for quality through reasoning budgets. Our architecture has to ground the tutor in pedagogy and respond to the child in real-time.
We threw out the standard agent loop.
A teacher is constantly deciding how to engage a student, whether to say something, draw on the whiteboard, play a game, or change topics entirely. The standard pattern for an agent today is a tool loop. The LLM outputs one or more tool calls, waits for them to execute, observes the results, and decides what to do next. So the straightforward way to build a teaching agent is to make a tool for each action a teacher could take.<br>But the tool loop has a latency problem. Frontier models take 2–3 seconds to produce their first token, then decode at around 30 tokens per second. Our actions average a few dozen tokens. Add round-trip latency and audio playback, and a standard loop means 3-4 seconds of downtime between each sentence or change on the screen.
In one of our earlier playtests we watched it happen in real time. A six-year-old boy waited for the agent to think, then asked:
Why is he not doing anything? When is this starting. It's boring.
— Child, 6 years old
Another child in the same round of playtests figured out she only needed to pay attention part of the time and could still keep up. Latency had taught her to tune the tutor out. That was also the moment she stopped learning.<br>The convenient fix would be a smaller, faster model. That's where a scope problem shows up. Teaching is a broad task. A tutor might pick between dozens of actions in a single lesson, and the hardest call is often to withhold the answer and give a hint, ask a smaller question, or let the child struggle just enough that the insight is theirs when it lands.<br>Smaller models struggled to follow instructions across that breadth. An early version of our agent that used one was responsive yet constantly giving the answer away. Every time it did, it took away the moment where the learning happens.<br>So we built a custom harness to balance instruction following, latency, and a flexible action space. The model streams multiple actions in a single response. An interpreter parses and executes each action while the model is still generating the next ones. The child only has to wait for the first action about 30 tokens in, not for the whole response to complete.
Separating generation from execution buys us two more things. We can change which actions are available depending on the situation. For instance, when a question is on screen the agent gets instructions and options for scaffolding rather than answering. And we can validate each action without a latency hit on the happy path. Only if the stream produces an invalid action do we interrupt and re-generate, otherwise execution never pauses.<br>None of this is free. Owning the loop means we've had to build our own observability and tracing instead of leaning on a framework. And we're swimming against the current: frontier models are heavily post-trained on the tool-use pattern. If future models get fast enough, our harness is designed to be replaced by the simpler loop.<br>Lesson: Agent frameworks are building toward background work, where the tradeoff between speed and thinking is easy. Real-time learning sits at the other extreme. Teaching at conversation speed means owning the loop ourselves.
A good tutor predicts what the child will do next.
A real teacher both reflects on what a student just did and anticipates what they'll do next. Teach the same lesson a hundred times and you see the patterns. But you also know this child, where they've been stalling, what excites them, what's likely to trip them up today. You start the lesson with a plan and adjust it on the fly.<br>We call the agent that interacts with the child the converser. Our early experiments...