Thirty seconds used to feel like wasted time.
I would send a prompt to an AI agent, watch it start thinking, and immediately press Cmd + Tab. Maybe I would check Lark for a work message. Maybe I would review another pull request. Sometimes I would start a second agent so another task could move in parallel.
It felt efficient. The agents were never idle, and neither was I.
Then several agents started asking for my input at the same time.
One needed a design decision. Another had finished an analysis. A third wanted approval before changing a file. I kept jumping between conversations, quickly rebuilding enough context to answer, then returning to whatever I had been doing before.
The agents were working in parallel. My attention was not.
The illusion of parallel work
Before coding agents became part of my daily work, I usually kept one or two tasks active. A task moved through brainstorming, communication, planning, implementation, testing, review, and delivery. When it was done, I moved to the next one.
AI changed the rhythm. After entering a prompt, I suddenly had a small pocket of waiting time. Even if it was only 30 seconds, I did not want to waste it.
So I filled every gap.
The problem was not only the number of tasks. It was the number of mental contexts. Every conversation had its own goal, constraints, history, assumptions, and unresolved decisions. When I opened another conversation, my brain had to load that context again.
The metaphor is similar to an agent’s context window, although a human brain is obviously not a language model. When I switched, some of the previous context faded. Returning meant rereading messages, reconstructing the reasoning, and remembering why a decision had been made.
Research on task switching describes a real switching-time cost, with more complex rules producing higher costs. Software engineering research shows the same tension in day-to-day work: developers associate productive days with completing meaningful tasks without significant interruptions or context switches, even though observation shows that they still switch frequently.
I could feel that cost in my reviews. Early in the day, I read an agent’s plan carefully. After enough switching, I started skimming and approving. Sometimes I later had to redo the work because the design had not been good enough in the first place.
That was the signal I could not ignore. I was optimizing agent utilization while degrading human judgment.
How I work now
I still use multiple agents. Parallel execution is one of their biggest advantages. The change is that I no longer try to make my own attention parallel too.
I use three rules.
1. Batch work by project
I group related tasks under the same project and reserve a block of time for that project only.
For example, during one project block I might:
- review code generated by different agents;
- brainstorm a feature or optimization with another agent; and
- ask an agent to analyze project data.
Those are different tasks, but they share a foundation: the same codebase, product goals, vocabulary, constraints, and recent decisions. Moving between them still has a cost, but I do not have to rebuild an entirely different mental model each time.
This is the difference between switching tasks and switching worlds.
If I jump from an iOS performance investigation to a hiring document and then to an AI workflow design, almost nothing carries over. If I move from reviewing one agent’s implementation to checking another agent’s analysis in the same initiative, much more context remains warm.
Batching does not remove context switching. It reduces the distance of each switch.
2. Put agent requests in a queue
I used to react whenever an agent asked for input.
If I was halfway through one review and another agent sent a notification, I opened it immediately. My reasoning was simple: if I replied now, the agent could continue working. There would be no dead time.
But the agent’s waiting time is not automatically more expensive than my interrupted thinking.
Now I treat requests as a queue. I finish the current review or reach a safe stopping point before opening the next conversation. Then I choose the next item based on priority, not notification timing.
Some requests are genuinely blocking and urgent. Most are not. A question can wait for a few minutes while I protect the context already loaded in my head.
This creates a useful asymmetry:
- agents can keep working in parallel where they do not need me;
- blocked agents can wait in a visible queue; and
- I process decisions serially with enough attention to make them well.
The goal is not zero waiting time. The goal is good decisions.
3. Replace prompt-by-prompt supervision with loop engineering
Another source of switching was my own prompting style.
Sometimes I was too lazy to prepare a detailed prompt, so I gave an agent one small instruction at a time. It returned after a few minutes, I checked the result, made the next decision, and prompted again.
That felt safe because I could supervise every step. In practice, it was micromanagement. Each short loop pulled me back into the conversation, often before I had finished something else.
Now I spend more time preparing the work upfront. I give the agent:
- a clear goal;
- the context and constraints it needs;
- boundaries for what it must not change;
- validation commands or acceptance criteria;
- checkpoints where human judgment is actually required; and
- a stopping condition.
Then I let it work through the loop: inspect, implement, validate, correct, and report.
This does not mean blindly trusting the agent. I still review the important decisions and the final diff. The difference is that I review at deliberate boundaries instead of reacting to every intermediate event.
Stronger models help, but the process matters more. A capable agent with a weak task definition can still go in the wrong direction. A structured loop makes the work more autonomous without removing accountability.
A simple operating model
The way I work with agents now can be summarized in three lines:
- Batch by shared context. Keep related work together so the mental model stays warm.
- Queue interruptions. Let agents wait until I reach a safe switching point.
- Engineer the loop. Invest in the prompt, constraints, validation, and stopping conditions so the agent needs fewer reactive decisions.
The agents may be parallel. My attention remains serial.
That is not a limitation I need to fight. It is a constraint I can design the workflow around.
Conclusion
AI agents make it easy to start more work than one person can meaningfully supervise. At first, I responded by trying to keep every agent moving. I filled every waiting period, answered every notification, and switched conversations whenever something needed me.
I looked busy, but the quality of my attention dropped.
Now I optimize for a different thing: not how many agents are active, but how well I can review, decide, and steer. Batching keeps related context together. Queues protect work already in progress. Loop engineering gives agents room to operate without pulling me back every few minutes.
The machines can multitask. I should protect the part they cannot replace: focused human judgment.