DEV Community

Michael Hairetis
Michael Hairetis

Posted on

You cannot make the agent fast enough. Move the wait instead.

I built a small learning app for my two kids on the same agent infrastructure that runs two other platforms. It introduced a constraint the other two never had.

Somebody is waiting.

The orchestration platform runs at four in the morning with nobody watching. If a call takes ninety seconds, it takes ninety seconds, and nothing in the system notices. The publishing platform has a person in front of it, but that person is me, reviewing on my own schedule.

The third has a second-grader holding a pencil, looking at a screen. Her patience is not a performance budget I get to negotiate. It is a hard physical limit, and when I exceed it she wanders off and the product has failed in the only way that matters.

I built it the obvious way first, and the obvious way was wrong.

Generate content one question at a time. Each call is small, so it is fast and unlikely to come back malformed, and I prefetch the next question while the child works on the current one. In theory the waiting hides behind the thinking.

In practice a child does not fill the gap the way a scheduler does. They answer, and then they sit. If the prefetch had not landed they watched a spinner, and they did that between every single question. Six items in a set, six opportunities to lose them.

The architecture that looked responsive on paper was the least responsive thing I could have built, because it distributed the waiting across exactly the moments when the user had nothing to do.

The instinct is to make the calls faster. That instinct is wrong.

You usually cannot make an agent fast enough to be invisible, so stop trying and change when it runs instead.

The app now plans three lessons at once and builds each one complete in a single call, every question and figure and answer finished and stored before the child sees any of it. Lesson one takes a minute or two. They wait for that, once. While they work through it, lessons two and three build in the background. From there, opening a lesson is a database read. I measured it at six milliseconds.

The waiting did not shrink. It moved. One wait at the front, where a user will tolerate it because nothing has started yet, in exchange for zero waiting during the part where they are actually engaged.

Two details make it hold up. The lesson has to be genuinely complete, not a plan with placeholders, or the scheme collapses back into the original problem. And the background build has to survive a server restart, because in-flight async tasks die silently and leave a lesson stuck at "building" forever.

The full piece covers the applets the agent writes as working code, the positional bias I found in generated quizzes, and why my reader cannot read.

https://openred.space/blog/a-seven-year-old-will-not-wait.html

Top comments (0)