What to do while the robot works

Here is the new shape of a workday. You give an AI agent a task. It goes off to work for eight minutes. You, restless and optimizing, jump to another project and start directing a second agent there. Then a third. You feel like a conductor running three sections at once.

It is a reasonable instinct. It is also, mostly, an illusion of progress. The research on exactly this problem is older and clearer than the AI hype makes it seem, and it has a specific answer.

This is a solved problem, under an old name

Long before coding agents, robotics studied one human supervising many machines. The core idea is fan-out: the number of agents a single person can effectively run equals their neglect time divided by their interaction time (Olsen and Goodrich).

• Neglect time is how long an agent runs on its own before its output starts to degrade.
• Interaction time is how long you spend directing and checking it.

If an agent runs about eight minutes alone and takes you two minutes to direct and review, your fan-out is roughly four. Try to run more than that and one of two things happens: the agents sit idle waiting on you, so you become the bottleneck, or you under-supervise them, so quality quietly drops. There is a hard ceiling on how many agents you can usefully run, and it is lower than it feels in the moment.

The three taxes you are paying

One: resumption lag, doubled. Every time you jump back to a project, you have to rebuild the context you dropped. In an analysis of 10,000 programming sessions, only 10 percent resumed work within a minute of returning, and in 93 percent of cases the developer had to navigate around to reload context before they could edit anything (Parnin). With an AI agent it is worse than an ordinary interruption, because you do not just rebuild your own mental state. You also have to reconstruct what the agent changed while you were gone. Two reloads per switch, not one.

Two: you stop catching the mistakes. When you supervise automation passively, your attention degrades. Human-factors research calls it the out-of-the-loop problem: you slide from operator to observer, your situational awareness drops, and errors slip past you. In aviation, 77 percent of incidents involving over-reliance on automation came down to a vigilance failure (Frontiers in Neuroscience). Catching the agent’s mistakes is the entire reason a human is in the loop. Push past your fan-out and you stop doing the one job that justifies your being there.

Three: it feels faster and it is not. In 2025, METR ran a randomized controlled trial with experienced developers on large codebases. With AI tools, they were 19 percent slower, while believing they were 20 percent faster. The time saved generating code was spent reviewing and fixing it (METR). Broader industry data tells the same story: teams running many agents merge far more pull requests, but spend so much more time orchestrating and validating that the juggling cancels most of the gain. And in complex work, an interruption as short as five seconds can triple error rates. The cheap-feeling micro-switches are not cheap.

The instinct is half right

None of this means parallelism is bad. Issuing a direction is genuinely low-effort compared to deep coding, and when work is truly parallel and you stay inside your fan-out, running several agents is the right model. The enemy is not parallelism. It is unbounded parallelism, and the specific move of filling the wait with deep context-switching into another project. That is the single most expensive thing you can do with the gap.

What to actually do while it works

1. Cap concurrent agents at your real fan-out. For most people directing coding agents, that is two or three, not six. More than that is theater.
2. Raise neglect time, lower interaction time. This is the real lever. Give agents bigger, well-specified chunks with clear acceptance criteria and tests, so they run longer without you and you can review them faster. Better direction beats more agents, every time.
3. Fill the wait with low-residue, adjacent work. This is the direct answer. Do not start a different brain. Stay in the same headspace: review the agent’s last output, write the next spec, queue the next move, sharpen the plan. Tee up the next direction instead of diving into another project’s deep work.
4. Batch your direction-giving. Do not react the instant an agent pings you. Let them run, then do a single review-and-redirect pass across them on a cadence. Switching cost is paid per switch, so a few scheduled switches beat dozens of reactive ones.
5. Keep one primary, run the rest async. Hold one project as your live, deep-thinking context and touch the others only at checkpoints.

How 6s thinks about it

This is the whole 6s thesis pointed at the agent era. 6s already encodes fan-out: the work-in-progress nudge caps how many projects you keep active, and every project surfaces a single next move so there is always one low-residue thing to do.

That last part is the answer to “what do I do while it runs.” Not “thrash into another project.” Open your primary’s next move, or write the next clear instruction, the kind of low-effort, same-context work that raises an agent’s neglect time and lowers your interaction time. The waiting time is not dead time. Spent right, it is where you set up the next hour to run itself. Spent wrong, it is where your attention quietly turns to soup.