You Can Afford More Agents. You Can't Afford to Watch Them.

I have room to run more AI agents, the subscription has tokens left, the computer has spare capacity, and there is plenty of work I would like to get done. What I don't have is enough attention to keep following all of them.

That is a strange place to be, because everything on the screen looks like progress. Work is happening in several places at once, but I keep having to stop what I'm doing to decide what happens next somewhere else.

In the weeks leading up to August 6, 2026, I kept notes on how often I lost track of what I was doing. It happened about four times a day on average, usually while I was juggling more than ten tasks across projects, writing, debugging, messages and agents.

Not ten agents, ten tasks, and that distinction matters because the agent isn't the only thing asking for attention.

On a heavy day I might have terminals open across four projects. I open one to start something, another flashes because an agent needs me, and I go over there to deal with it.

When I come back, I can't remember what I opened the first terminal to do. So I pick up the next task and hope the missing one comes back to me.

Honestly, it is a little embarrassing to write that down. I first took it as a sign that I was getting bad at managing my own work, because the tools could clearly do more and I was the person slowing everything down.

But I noticed it as the number of parallel tasks grew, and I felt more mentally tired after those days too. My notes don't prove the extra tasks caused either thing, the lost threads were self-tracked and the tiredness was something I felt, not something I measured.

In conversations across a franchise network, operators reported a similar sharp rise in mental load as they used more agents. Those were conversations, not results pulled from delivery records, so I can't tell you how common it is or put a percentage on it.

What I can say is that buying more capacity would not address the problem I could see in my own setup. I needed fewer things waiting for my attention, or a way for some of them to finish safely without it.

The tools encourage parallel work, and there are good reasons for that. OpenAI's Codex launch post describes running many tasks in parallel, Claude Code's documentation describes separate worktree sessions, which let agents work on separate copies of a project, and Cursor's advice includes notifications so you know when an agent finishes.

None of that tells you how many unfinished tasks you can personally supervise well. The software can keep another task running without knowing whether you have room to think about its result.

And the same vendors say review still matters. Cursor puts it plainly, “The faster the agent works, the more important your review process becomes.” OpenAI's launch guidance says users still need to manually review and validate agent-generated code.

So the extra work doesn't end at generation, it comes back to someone. If you're that person, your attention belongs in the capacity plan as much as the computer does.

There is research that helps explain why this can be difficult, but I want to be careful about what it actually measured. None of the studies in this article gives us a safe number of AI agents for one person.

Sophie Leroy's 2009 work on attention residue describes how some of your attention stays with an unfinished task after you switch to another. You can move to the next window before your thinking has fully moved with you.

That is the part I recognize when a flashing terminal pulls me away. I dealt with the interruption, but the task I left was still unfinished and I had to work out where I was when I returned.

Nelson Cowan's working-memory research puts the central store at roughly three to five meaningful items in young adults under specific test conditions. It is a small amount of information to hold in mind at once.

But a memory item isn't an agent session, and a terminal isn't a fixed amount of thought. You cannot take that result and conclude that five agents are safe or that ten terminals are twice what a brain can handle.

The switching costs show up in work studies too. Gloria Mark and her colleagues found that interrupted work resumed the same day took an average of 25 minutes and 26 seconds to resume, with 2.26 other working spheres handled in between.

That is elapsed time before returning to the work, not 25 minutes of being unable to think. The distinction matters, because people were doing other work during the gap, just as I was answering an agent instead of doing the task I had opened the terminal for.

And in 10,000 recorded sessions from 86 programmers, only 10% had programming activity resume within a minute after an interruption. That doesn't mean the others were wasting time, it tells you that returning isn't always immediate.

The closest comparison in the sources is from supervising autonomous vehicles rather than software. In a 2007 study by Cummings and Guerlain, 42 U.S. Navy personnel supervised simulated missile strikes, and performance and awareness of the situation degraded at 16 vehicles.

The paper also discussed air-traffic-control work where performance declined at 17 aircraft compared with 10 or 11. It suggested 70% operator busy time as a useful threshold for predicting performance decline in that setting.

That isn't 70% of the day making decisions, it is total busy time, and missiles and aircraft aren't coding agents. I would not turn any of those figures into a rule for your company.

What carries over is the question, how much of the supervisor's time does each additional system demand? If a better tool reduces how often you have to step in, it can change how much you can supervise, which is why the number of windows alone won't give us the answer.

I also don't think the feeling of speed is enough to tell us whether the setup is working. Several tasks moving at once feels very productive, especially compared with waiting for one to finish.

In METR's early-2025 randomized trial, 16 experienced open-source developers worked on 246 issues in repositories they knew. With AI tools they took 19% longer, while afterward they believed AI had made them about 20% faster.

That is a historical result, not a verdict on today's tools. METR's February 2026 update said its later experiment couldn't give a reliable current estimate, in part because people who didn't want to work without AI were selecting themselves out.

So I am not saying AI makes developers slower. The useful point for this problem is that the feeling and the completed-work measurement can disagree, and I don't want to use one as a substitute for the other.

My dashboards didn't show the task I forgot to start. They showed the work that was running, which meant I had to count the dropped threads myself to see that part of the cost.

There is another part I worry about, the decisions. I catch myself handing more thinking to an agent when I already have too many things to follow, because accepting its suggestion is easier than rebuilding the whole problem in my head.

That is my experience, not a measured decline in decision quality. I haven't tested whether my decisions got worse or whether I lost any ability to solve difficult problems, and I don't want to turn that worry into a fact.

But I do want to separate two reasons for delegating a decision. One is that the agent can handle it within a boundary you've chosen, the other is that you don't have the attention left to think about it, and those are not the same reason.

Decide what still needs you

I see two possible directions, get better at following more things, or make more of the work able to run without constant intervention and keep fewer, more important decisions yourself.

Practice can make a workflow familiar, but task-switching research found costs that persisted even with preparation time. That doesn't establish an agent limit either, it just gives me no reason to assume I can practice my way out of every interruption.

My bet is on changing the work around the agent. An orchestrator assigns a task, a creator does it, and a validator checks the result, then the creator fixes what was rejected until it passes or reaches an attempt limit.

The useful part is that the task can reach a checked piece of work before it comes back to me. It doesn't need me to watch every intermediate step, provided the checking is good enough for that task and there is a clear point where it stops and asks for help.

That is not permission to let everything run on its own. Checkability and the cost of undoing a mistake help decide how much to delegate, and the cost of an error that escapes tells you where that freedom needs a stronger boundary.

A task waiting for my approval still belongs in the work I have to follow. A task that can run to a checked result without asking me for a decision doesn't need the same active attention, although somebody still needs to own failures and exceptions.

That is an operating distinction, not a claim that a background task takes up zero working memory. It is how I would decide what counts toward the active set.

On the Delivery Model Ladder, a human holding most of the review is a Stage 2 constraint. The four stages of reviewing AI work describes how that checking layer can change before you move toward Stage 3.

Use a cap while that layer is missing

I don't have this solved. I capped the amount of work I run at once because I could see myself losing the thread, and I didn't want to keep adding tasks just because the infrastructure could handle them.

Three to five open threads is a conservative first test I would consider, not a limit established by the research. Your jobs may demand very different amounts of attention, so the number needs to come from what you can actually follow.

Before changing it, count dropped threads for a week and note what was open when they happened. Then keep counting after you change the cap, because that is the part I failed to do.

I stopped counting after I imposed mine, so I don't have a before-and-after result. I also never measured my percentage busy time, and I can't claim the cap reduced mistakes or improved my decisions.

It gives me a smaller active set to watch, which is the direct effect of running fewer things. Whether it improved the work is a separate question that needs the measurement I didn't keep.

If you lead a team, I would ask the same question about the person reviewing your agents' work. The AI readiness assessment includes review capacity for that reason, because the company can buy more production than one reviewer can keep up with.

This advice applies where a person is still following the work and making the calls, not to every agent running quietly in the background. Better checks and fewer interruptions could let that person supervise more, and the sources here don't tell us how far that can go.

For now, before I start another agent, I want to know whether I'm adding work the system can finish or another decision that will come back to me. Spare tokens don't answer that question.