You can afford more agents. You can't afford to watch them.

On my current setup, the tokens are paid for, the hardware has spare capacity, and the task list is full. My attention is the part running out. Nelson Cowan's research puts the central store in working memory at three to five meaningful items, not agent threads. In a 2007 study of one human supervising simulated missiles, performance degraded at 16 vehicles. Neither study establishes a safe number of agent sessions.

In the weeks leading up to August 6, 2026, I juggled more than ten concurrent tasks across projects, terminals, writing, debugging, messages, and agents. My self-tracked notes show that I lost track of what I was doing about four times a day. That is a personal count, not a general limit. My current rule is to cap the number of open threads while I build a validation loop that can take some review off the human. The evidence warns me about overload. It does not tell me what the cap should be.

I lose track of what I'm doing four times a day

A heavy day means terminals open across four projects. An agent is writing code in one, another is debugging in a second, and a third is drafting text. A terminal flashes for attention, I jump to it, handle it, and come back. The thing I opened the previous terminal to start is gone. I jump into the next task and hope I remember.

My notes from those weeks show that I lost my thread four times a day on average, usually while juggling more than ten concurrent tasks: projects, terminals, writing, debugging, messages, agents. I noticed the problem as the number of parallel tasks grew, but my notes do not establish the cause. Heavy concurrent days also left me feeling more mentally tired at night. That fatigue was felt, not measured.

The strange part is what is not scarce in my setup. My LLM subscription has tokens left. The machine could run more agents. The backlog of tasks worth doing is longer than ever. The bottleneck I can see is my attention.

In conversations across a franchise network, operators report the same pattern: a sharp, noticeable rise in cognitive load as agent usage increased. That comes from reported conversations, not delivery data.

This is not a discipline problem

I first blamed myself for getting bad at juggling. The research below gives another explanation: switching among unfinished tasks carries a cost, and working memory is limited.

On August 6, 2026, a thread on r/ClaudeAI titled "Am I the only one getting physically stressed from AI coding?" drew a discussion from people who described feeling more mentally drained while using coding agents. That thread is anecdotal. It does not show how common the problem is.

Vendors are promoting more parallel work. OpenAI's Codex post promotes running "many tasks in parallel". Anthropic's Claude Code docs describe parallel sessions in separate worktrees as a normal workflow. Cursor suggests you configure notifications and sounds so you know when each agent finishes. None of those pages defines how many active threads a person can supervise well.

Why does managing AI agents create cognitive overload?

Context switching leaves some attention behind on the unfinished task. Sophie Leroy's 2009 study calls this attention residue. When you leave a task unfinished, the next task runs on the attention you have left. That is what happens when a flashing terminal pulls me away.

The second name is capacity. Nelson Cowan's working-memory research puts the central storage limit at three to five meaningful items in young adults under specific test conditions, not the seven of older folklore. A terminal is not a memory item, so Cowan's result does not prove that ten terminals cross a hard limit. It does show that the central store used for thought is small.

The cost of each switch is also measured. Gloria Mark's team at UC Irvine tracked information workers. Among interrupted work resumed the same day, resumption took 25 minutes and 26 seconds on average, with 2.26 other working spheres handled first.

Programmers fare no better. Across 10,000 recorded sessions from 86 programmers, only 10% had programming activity resume within a minute of an interruption. Most took longer.

Which raises the question: is there a hard ceiling, and has anyone measured it?

A related ceiling has been measured outside software

Military research on supervising autonomous systems gives us a related comparison.

In a 2007 study, Cummings and Guerlain had 42 U.S. Navy personnel supervise simulated missile strikes. At 16 vehicles, performance and situation awareness significantly degraded. The paper also points to air traffic control, where performance declined with 17 aircraft compared with 10 or 11. It suggests that 70% utilization, meaning the operator's percentage busy time, is a valid threshold for predicting significant performance decay in that setting.

The transfer is only an analogy. These are missiles and aircraft, not coding agents, and nobody has run this study on agent sessions. The study covers one human supervising autonomous systems, but the mission and demand pattern differ from software work.

Firms already use span of control to think about human supervision. Agent work creates a related problem when the human remains the validator, but the military study does not tell a firm how many agents to run.

The strongest counterargument is that better tools can raise the ceiling by reducing how often a human must intervene. The Cummings paper measured total percentage busy time, not time spent making decisions. It does not show whether filters, alerts, or agent managers can raise the limit for coding work.

The feeling of speed can mislead you

Parallel work can feel fast before the results arrive.

METR ran a randomized trial with 16 experienced open-source developers working on 246 issues in repositories they knew in early 2025. With AI tools, they took 19% longer. They believed AI had made them 20% faster. METR now says that historical result no longer reflects current tools, and its later study produced an unreliable current estimate because of selection effects. The early-2025 perception gap is still the one I recognize from my own notes.

The feeling of parallel progress can hide coordination cost. Dropped threads do not appear in the dashboards I use unless I count them. Ten moving tasks are not the same as ten finished tasks.

The same vendor pages that promote parallel work also tell users to review it. Cursor, verbatim: "The faster the agent works, the more important your review process becomes." OpenAI: "it still remains essential for users to manually review and validate all agent-generated code."

The decision risk is still unmeasured

Past the number of threads I can reliably follow, I worry that my decisions get weaker. I have not measured decision quality or skill loss, so I cannot claim either one happened. What I can measure is when I lose the thread. That is the signal I use to stop adding work.

When should a human stay in the loop?

I see one practical fork. You can try to hold more threads, or give agents more autonomy and keep the higher-level decisions yourself. The AI Readiness Assessment asks the same question at the firm level: who reviews what the agents produce, and can that review capacity keep up?

Task-switching costs persist even with generous preparation time. Practice may make a workflow more familiar. Cowan's central storage range remains three to five meaningful items, but neither source establishes a fixed limit on agent sessions.

A validation loop lets agents work without constant human review. An orchestrator assigns the work, a creator does it, and a validator checks it. The creator fixes problems until the validator passes the work or an attempt limit is reached.

On the Delivery Model Ladder, this is the Stage 2 constraint: a human still holds the review layer. The four stages of reviewing AI work shows how that layer changes before a firm can move toward Stage 3.

Until then, delegate the inputs, own the outputs gives you the delegation rule, routed by the cost of the mistake. A task that runs safely to a checked artifact without asking for a decision does not need the same active attention as a task waiting for your review.

What can you do this week, before that layer exists?

Cap the threads on purpose

For now, I cap concurrency below what the infrastructure allows. I set the cap by how many threads I can hold, even when the subscription and hardware can run more.

Three to five open threads is a conservative first test. Research has not established an agent limit. Count your dropped threads for a week before changing the cap. I capped my threads but stopped counting afterward, so I have no before-and-after result. I also never measured my percentage busy time.

The honest cost is that I have no finished system. I use the cap while the validation layer is missing. It gives me a smaller active set to watch, but I have not measured whether it reduced dropped threads or improved my decisions.

Where this advice stops

The measured results come from missiles and aircraft, and no study has measured how many agent sessions one operator can supervise. This cap applies to threads where you remain the validator.

A thread that runs to a checked artifact without asking you for decisions does not need to stay in your active set. That is an operating definition, not a result the studies tested. I use the cap as a precaution while the validation layer is missing, not as a measured loss reduction.

The open question is whether operators learn to juggle more or move up to more abstract decisions. Firms running agents make that choice whenever they decide which calls remain human. My bet is on deciding higher, and the cap is my temporary rule until the tooling catches up.

If this was useful, subscribe to the newsletter.