Context Switching in the Age of AI Agents — When You Become the Scheduler#

2026-07-19

Now that AI agents carry out the final execution of work, people can run several tasks at once. And yet lately I have been feeling a strange kind of fatigue. Working with two or three agents in parallel, my hands are not particularly busy — but my head keeps spinning without traction. Every time a response notification arrives, I switch straight to that session to check it, and the result is a scattered mind and, if anything, worse overall performance.

This essay is the result of investigating why, along with the operating rules I have decided to adopt. The short version: the problem is not the agents. It is on the human side — specifically, in how I context-switch (the act of unloading one task’s mental state and loading another’s).

The New Bottleneck: This Time, It’s the Human#

Break down how collaboration with an agent actually works. The agent is not wired directly into my brain, so conveying what I want requires conversation. Much of that conversation happens before the work starts, but plenty of it keeps happening mid-task. And the agent is not an instant responder either. In my environment, a response takes about three minutes on average.

Sitting idle for three minutes is wasteful, so naturally I pick up other work in the meantime. That is how the agent conversations multiply to two, then three. Up to this point, every step is a reasonable choice. The trouble starts afterward. Every time I hop between sessions, I have to re-establish “what was I doing here again?” and reload that context into my head — and it takes far longer than expected.

If the structure were “kick off a task, come back an hour later,” switching cost would hardly matter, because switches would be rare. But when two or three conversations with a three-minute response cycle overlap, the picture changes. Switching is forced on you every few minutes, and the human ends up playing the role of an operating system scheduler, endlessly swapping processes in and out. The difference is that an OS context switch takes microseconds, while a human one takes minutes.

Why the Brain Can’t Keep Up — Three Lines of Research#

The evidence that this fatigue is not imaginary has been piling up for a long time.

First, attention residue. Sophie Leroy of the University of Washington formalized the concept in a 2009 paper: even after you switch from task A to task B, cognitive activity about A does not fully shut off — it lingers and degrades your performance on B (Leroy’s research overview). The crucial part is the condition: residue is strongest when the previous task was left unfinished. A conversation with an agent is, structurally, always left unfinished at the moment you switch away — waiting for a response is itself an open loop. In other words, parallel agent work lands squarely on the exact conditions that maximize attention residue.

Second, the cost of recovery. Gloria Mark’s team at UC Irvine found that after an interruption, it takes roughly 23 minutes on average to return to the prior depth of focus (research summary). If you bounce between conversations on a three-minute response cycle, driven by notifications, reaching deep focus becomes mathematically impossible. You pay the recovery cost on every switch and never once collect the benefit of immersion.

Third, resumption lag and cues. Research by Altmann and Trafton shows that the time it takes to resume an interrupted task can be cut substantially in two ways (Task Interruption: Resumption Lag and the Role of Cues): deliberately encoding a goal right before leaving (“when I come back, I start with X”), and having a conspicuous resumption cue waiting when you return. The “time to reload context when returning to a session” is, in other words, a variable you can shrink.

Put it all together and the diagnosis writes itself. Switching immediately on every notification means repeating unfinished-state switches (maximizing residue) every few minutes (making recovery impossible) with no cues prepared (maximizing resumption lag). I had assembled nothing but the bad conditions — no wonder my head was spinning.

The Three Rules I Adopted#

Out of everything I investigated, three things struck me as immediately actionable.

1. No Switching on Notification — Run Yourself Like a Coroutine#

The core move is taking ownership of the switching moment away from notifications and back into your own hands. When a notification arrives, I do not jump right away. I first finish the small unit of work in the session I am looking at — where a “small unit” means a natural completion point like “read the response fully and sent the next query.”

In programming terms, this is choosing coroutines over multithreading. In multithreading, the scheduler can preempt a thread at any arbitrary moment and hand execution to another (preemptive). Coroutines, by contrast, yield only at points where each task decides “it is safe to pause here” (cooperative). Switching on notification is running your brain preemptively; switching after completing a task unit is running it cooperatively.

There is an asymmetry worth keeping in mind, because it is liberating: the agent pays no cost for waiting. If its response gets read three minutes late, the loss is zero — whereas the cost of a human thought being severed mid-stream has been measured. The human’s rhythm always takes priority.

2. Before Leaving, Drop a Resume Memo in the Input Box#

I work with several IDE (integrated development environment) windows open, each holding multiple agent sessions. The most frequent failure in this setup is “what was I doing in this session again?” Apply Altmann and Trafton’s resumption cues here and the answer falls out: before leaving a session, spend twenty seconds typing the current context and the next step into that session’s query input box. The input box is the first place your eyes land when you return, so it serves as a resumption cue with no extra tooling at all.

You can take it one step further and delegate the job to the agent itself. Before stepping away, ask it to “summarize the current state and list the decisions you need from me at the top when I return” — and the resumption cue assembles itself on screen. The context store moves out of your head and into the agent.

3. At Most Two Interactive Tasks at a Time#

Divide your in-flight work into two kinds.

Any number of long-running autonomous tasks is fine. The problem is the interactive kind, and I have decided to cap them at around two at a time. The exact number can flex with circumstances, but the principle is the point: put a ceiling on how many interactive tasks run concurrently. Practitioner experience converges on the same place — people who have run many agents in parallel consistently report that beyond three or four, it stops being cognitively manageable (Addy Osmani, The Code Agent Orchestra).

Two Ideas That Are Right in Theory but Stubborn in Practice#

Some of the prescriptions I found are ones I agree with in principle but could not adopt as-is. I am keeping these two as reference material to adapt over time.

Front-loading the questions. The root cause of the few-minute ping-pong during a task is insufficient context at the start — so exhaust the clarifying questions up front, and the number of switches drops on its own. Theoretically this is exactly right, and I already put real effort into it. But in practice it is hard, because at the start you often cannot know the complete end state. Humans, too, frequently arrive at “ah, so this is what it actually needs to be” only partway through the conversation. The realistic compromise is not to eliminate discovery but to pull its timing forward: run an exploratory pass first (“don’t implement yet — investigate and bring me a list of the decisions I need to make”), or widen the arrival interval of questions (“batch whatever blocks you and ask at the end of the phase, all at once”).

Only one deep task at a time. The prescription says to keep just one context-heavy deep task as the protagonist and fill the remaining slots with shallow tasks that finish within a few minutes. I agree with the direction, but the boundary between deep and shallow is blurry, and situations where two or more deep tasks must run in parallel are unavoidable. That said, the investigation gave me one useful reframe: depth is not a property of the task but a property of the phase. The same task is deep while you are wrestling with its design and shallow while the agent is off implementing on its own — there is nothing for you to judge. So the rule becomes not “keep only one deep task” but “stagger the phases so that two tasks’ deep phases never overlap” — which turns out to be the same rule as the interactive-task cap above, just worded differently.

Closing Thoughts#

People say the defining skill of this era is using agents well. I have come to feel that half of that skill lies not in prompting but in scheduling on the human side. Agents keep getting better, so the bottleneck that remains is the human brain shuttling between sessions. And that bottleneck is not solved by switching tools. It turned out to be a matter of habit: reclaim the switching moment from notifications (the coroutine style), cap the number of open loops (two interactive tasks), and attach a resumption cue to every loop you leave open (the input-box memo).

One more thing worth writing down: the highest-leverage intervention is not switching well but reducing the need to switch at all. The farther an agent can travel on a single instruction, the more the human context-switching problem dissolves on its own. In that sense, the rules in this essay may just be survival techniques for a transitional period — the stretch until agents’ autonomous execution gets good enough. But that transition may last longer than we think, and survival techniques are worth doing properly.