I have noticed something when I work with several agents at the same time. The harder I try to squeeze useful work into every spare minute, the easier it becomes to lose my place.
One agent is building something. While that runs, I can get another to research something else. Then there is a gap, so why not start a third? And while I am waiting for that, there is another little job I could get moving.
It all looks terribly efficient.
Then I come back and think: hang on. Where are we? Which bit did we agree? Have I actually read that result, or have I just seen that it finished?
There is activity everywhere. My understanding has not kept up.
So here is my recommendation: go slower than you think you need to. Take stock at each phase. Understand where you are before adding another moving part.
I do not mean make the computers work slowly. I mean give yourself enough room to direct the work properly.
Parallel work is not parallel understanding
I like working with agents. This is not a sudden announcement that we should put them away and return to doing everything by hand.
But there is a difference between several things happening at once and me understanding several things at once. Each time I move to another thread, I need to remember its brief, its assumptions, what it has changed and what I am supposed to decide next.
That is work too. It is just less visible than a screen full of generated code.
If I open another task because there is a genuine opportunity to do independent work, lovely. If I open it because watching a progress indicator feels like wasting time, I should probably pause.
An agent waiting while I think is not necessarily a problem. Sometimes that is the most useful thing happening in the whole arrangement.
The research calls some of this attention residue
Sophie Leroy's research describes attention residue: attention can remain with unfinished work after we switch to another task. Her work with Theresa Glomb also examined how expecting to return under time pressure can make it harder to concentrate on the interrupting task. That is a useful explanation for the feeling that one thread is still occupying your head while you are reading another. It is not a study of Codex threads. Applying it here is an inference. 1
Older laboratory experiments by Joshua Rubinstein, David Meyer and Jeffrey Evans found time costs when participants alternated between tasks. More complex rules increased those costs; cues about the next task reduced them. These were classification and arithmetic experiments, not measurements of a working day with agents. They support the existence of switching costs, not a universal claim that every interruption wastes a particular number of minutes. 2
There is evidence closer to software work too. A 2018 study analysed 4,910 tasks from 17 developers, alongside a survey of 132 developers. In its retrospective analysis, voluntary switches were associated with greater disruption than externally imposed interruptions, measured through suspension length and nested interruptions. The task records came from one company, so that result needs care when generalising. Still, it challenges the comfortable idea that interruptions are only a problem when somebody else causes them. 3
Opening another agent can be my interruption. I cannot blame all of this on notifications.
The work moves from producing to judging
A CHI 2025 paper surveyed 319 knowledge workers, who supplied 936 examples of using generative AI. The researchers described critical thinking shifting towards checking information, integrating responses and overseeing the task. Greater confidence in AI was associated with less reported critical thinking. This was self-reported evidence, not an experiment proving that AI damages people's thinking skills. 4
That distinction matters. My point is not that using agents makes us less capable. It is that the work they leave us with deserves proper attention.
Reading a result is not the same as accepting it. Accepting it is not the same as checking that it works alongside the other changes. And a task marked complete is not necessarily a finished outcome for the company.
Suppose an agent produces a proposed fix in a minute. I then spend time understanding it, checking the tests and discovering that it depends on a decision another agent has quietly changed. The useful measure was never the minute it took to produce the fix. It was the time until we had something checked and usable.
That is why I would rather ask, "What have we finished and verified?" than, "How many agents have we kept busy?"
Other people are noticing it too
There are several useful perspectives here, but they are not all the same kind of evidence.
Cal Newport questions how much work we put on our plate. In his writing on slow productivity, he asks whether a deliberately smaller workload might damage our professional results less than we fear. I like that question. It is a productivity argument, not a clinical finding or an experiment with AI agents. My version is: does opening one more thread genuinely help, or does it just make me feel industrious? 5
BCG reports a more recent AI-specific warning. In a 2026 account of its study of 1,488 full-time US workers, BCG says 14% of AI users reported what it calls "AI brain fry": mental fatigue associated with excessive AI use or oversight. This is consultancy-reported survey evidence, not a clinical diagnosis or proof of causation. It does not establish a safe maximum number of agents for everyone. 6
Practitioners describe the loss of control very plainly. In January 2026, DoltHub's Tim Sehn wrote about trying Steve Yegge's Gas Town agent orchestrator. He described more activity than he could comfortably comprehend, followed by an autonomous merge despite failing integration tests. That is one person's account of an early tool and configuration, not a verdict on its current version or on all multi-agent work. It is nevertheless a recognisable warning: speed without a dependable approval boundary can become expensive. 7
These sources do not prove my exact workflow is the right one. They do give us good reasons to take the human part of agent work seriously.
But parallel agents really can help
There is an important counterargument. Sometimes more agents are exactly what the work needs.
Anthropic reported a 90.2% improvement on its internal research evaluation in June 2025, comparing an Opus 4 lead with Sonnet 4 subagents against single-agent Opus 4. This does not establish the gain from parallelism alone at an equal token budget. It also reported that multi-agent systems used about 15 times as many tokens as ordinary chat interactions in its data. Those are different comparisons: the token figure is not a 15-fold comparison with a single agent. Nor is the evaluation result a promise about your project. 8
Its engineering account is especially useful because it describes both the gains from independent research and the problems: duplicated work, excessive delegation and difficulties where tasks need shared context or have many dependencies. It recommends clear objectives, outputs and boundaries. 8
That is the distinction I want to preserve. Parallelism is useful when the work can really be separated. It is much less attractive when everybody is changing the same thing while waiting for everybody else's decisions.
My recommendation is therefore not "one agent forever". It is only launch as much work as you can still understand, review and bring together.
Work in small waves
Here is a simple way I would put this into practice. It is my proposed operating method, not a scientifically validated agent-count formula.
1. Agree what this phase is for
Before starting agents, decide what you are trying to achieve. Not the whole ambitious programme. The next useful outcome.
For example: "Find out why this test fails and return a proposed fix with evidence. Do not deploy anything."
That gives me something I can review. "Improve the system" is rather harder to judge, especially when several agents interpret it differently.
Write down what success looks like, what is out of scope, who owns the decision and what requires approval. Match actual permissions to that boundary; a sentence in a prompt is not an access control.
2. Separate independent work from dependent work
One agent could inspect the failing test while another reads the relevant documentation. They can return findings independently without changing the shared system.
But if the second task needs an architectural decision from the first, it should wait for that decision. Otherwise I am paying for work based on an assumption I have not yet agreed.
For coding, separate branches or working copies can reduce file collisions. They do not resolve incompatible design decisions. Somebody still needs to bring the work together and test it.
3. Start a wave you can review
I would begin with one or two clearly bounded streams, then increase only when review remains manageable. That is a cautious starting point, not a rule about everybody's brain.
An experienced operator with routine tasks, good isolation and reliable checks may manage more. A single unfamiliar, consequential task may already need all your attention.
Do not add another stream just because a button makes it easy. Ask what will happen when its result arrives alongside the others.
4. Stop at a meaningful checkpoint
At the end of a phase, take stock. What did we learn? What changed? Which tests actually ran? What failed? What still needs a decision?
I do not want an endless running commentary or a ceremony after every trivial action. I want a pause when the information is sufficient to choose the next step: after investigation, after a proposed change, after testing or before a consequential action.
If the output contradicts another task, resolve that before sending both onwards. A conflict does not become less important because both agents sound confident.
5. Integrate and close
Accept, reject or revise the output. Record the decision. Make clear what is now the current state and what remains open.
For a tightly connected change, finish that review before opening the next wave. Truly unrelated background work need not stop because one task is slow, provided its boundaries and review arrangements remain clear.
The point is controlled progress, not making every task wait for the slowest one unnecessarily.
Leave yourself a way back
One useful research-backed habit is wonderfully unglamorous: write a short note before switching.
Leroy and Glomb's ready-to-resume intervention asked people to briefly plan their return to interrupted work. Their research found reduced attention residue and better performance on the interrupting task. The university's account explicitly says the studies did not test whether the plan improved performance when people returned to the original task. 1
Here is my adaptation for agent work. The template itself is a practical suggestion, not the intervention verbatim:
Last decision: We agreed to investigate the existing approach before replacing it.
Current state: Investigation complete. Proposed fix not yet accepted.
Evidence: Findings and test output are linked in the task record.
Open question: Does the fix preserve the existing contract?
Next action: Review that question before approving changes.
Keep one small task list with links to the actual outputs. Do not build a second administrative empire just to remember the first one.
I want the next look at a thread to start with understanding, not detective work.
When to go wide, and when to stay narrow
Use this as a judgement aid, not a permission slip. The actual risk, dependencies and access controls still decide what is appropriate.
| Situation | My recommendation |
|---|---|
| Independent research questions with clear source requirements | Run them in parallel, then compare the evidence. |
| Tests that are genuinely isolated and do not compete for the same resources | Run together if the environment supports it; collect their results in one place. |
| Alternative drafts or proposed solutions | Parallel exploration can help. Keep a clear owner for the final choice. |
| A later task depends on an unresolved decision | Decide first, then start the dependent task. |
| Several agents want to change the same files or records | Isolate the work or sequence the changes, then check the combined result. |
| Deployment, sending, deletion or another consequential action | Keep explicit approval and technical controls appropriate to the action. A review summary is not authorisation. |
| Unread results are accumulating and you cannot explain the state | Pause new starts. Review, reconcile and reduce the open work. |
This applies beyond coding. Research for a board paper can be divided; the final recommendation needs to make sense as a whole. Several people or agents can inspect an accounts problem; changes to the same financial records need a controlled process.
A prompt you can actually use
Here is what I would ask my harness before it gets carried away. By harness, I mean the application that coordinates the model, its tools and its work.
Help me work in small, reviewable phases.
First summarise the outcome, acceptance criteria, dependencies and things you must not change. Identify what can genuinely run independently.
Propose a small first wave and wait for agreement on its scope. Use only the access and authority already granted. Do not widen them.
At each agreed checkpoint, show what changed, the evidence, what failed, unresolved decisions and the next suggested step. Distinguish an agent's claim from a result verified by a check.
Keep a short current-state note with links to the outputs. If tasks conflict or a decision needs me, flag it rather than working around it silently.
Do not treat approval of a plan as approval to publish, deploy, send or delete anything outside the authority I have explicitly given.
I would still inspect whether the harness follows this. A well-written prompt is helpful; it is not a guarantee.
Voice could make the checkpoints easier
This connects with my request to give each Codex thread its own voice.
I would love to arrive at a checkpoint and ask, "Right, explain where we are. What have you actually checked? What do you need me to decide?"
That could be much easier than reconstructing a long thread. It is also an opportunity to learn what the system is doing, instead of just approving something I do not understand.
But the voice should point me to evidence, not replace it with reassurance. A friendly explanation can still be wrong. A coordinating agent can still misunderstand the workers underneath it.
My request to harness developers is simple: make the state of the work easier to understand than the volume of activity. Show waiting decisions, conflicting assumptions and results awaiting review. Help me pause new starts without losing completed work. Give me a clear way back after an interruption.
I do not need another display telling me how very busy everything is.
Judge the whole outcome
Try a smaller wave for a few comparable tasks and see what happens. Include the time spent framing, waiting, reviewing, integrating and repairing. Keep the quality bar the same.
Watch how many results remain unread, how often you redo work and whether you can explain the current state without opening every conversation again. Record agent usage separately: a saving in your time and a saving in tokens are not always the same thing.
If a smaller wave helps, keep it. If your work is genuinely independent and more concurrency improves completed outcomes without weakening checks, use more. There is no prize for being artificially slow either.
The evidence here does not give us a universal number of agents, a guaranteed productivity gain or a diagnosis for feeling tired. Human task-switching experiments, AI surveys and engineering accounts answer different questions. Together, they support taking coordination seriously. They do not remove the need to learn what works for your particular job.
What I have noticed is simpler: when I try to fill every gap, I can lose my place. Taking stock helps me know what I am doing.
So let the agent wait while you read. Finish the phase. Understand the result. Then decide what comes next.
Go slower than you think you need to. You may find you finish more of what matters.
For a compact version of the operating principle, see the Agent Canon companion.
Sources and notes
Research checked on 10 September 2026. The opening experience and the small-wave method are my own account and recommendation. The sources below support the surrounding mechanisms and examples, within their stated limits.
- University of Washington, Peter Kelley, Task interrupted: A plan for returning helps you move on, 16 January 2018. Researcher interview and description of Leroy and Glomb's four studies; original paper DOI. Not an AI-agent experiment.
- Rubinstein, Meyer and Evans, Executive control of cognitive processes in task switching, 2001. Original journal abstract; laboratory classification and arithmetic tasks. No claim here about a fixed workplace recovery time.
- Abad and colleagues, Task Interruption in Software Development Projects, 2018 preprint. Full text, including the single-company and retrospective-method limitations.
- Lee and colleagues, The Impact of Generative AI on Critical Thinking, CHI 2025. Original research, including Microsoft-affiliated authors; survey and qualitative accounts, not a causal experiment.
- Cal Newport, What Would Happen If We Slowed Down?, originally posted September 2021. Author's argument about workload; not a measured agent-performance result.
- BCG, AI for CEOs: Amplifying Time and Judgment at the Top, 2026. Consultancy's account of its US worker survey. Self-reported fatigue; do not interpret as a clinical diagnosis or an agent-count threshold.
- Tim Sehn, A Day in Gas Town, DoltHub, 15 January 2026. First-person practitioner account of an early configuration, not a controlled comparison or current product review.
- Anthropic, How we built our multi-agent research system, 13 June 2025. Vendor engineering report and internal evaluation. Model configurations, comparison groups and workloads matter.