For twenty years we treated multitasking as a settled question. The research said it was a lie we told ourselves, and the research was right. Something changed in the last year, though, and it's worth being precise about what.
I now build three products at once. Different domains, different codebases, different customers. Three monitors on my desk, one tuned to each. I spend my day in deep design and brainstorming on one product, hand the execution to agents, and while they work I move to the next monitor and do it again. I round-robin all day. It has become the most productive way I have ever worked.
That should not be possible. Everything we learned about attention says it isn't. So either the research was wrong, or we were describing the wrong thing. I think it's the second one.
The case against multitasking was correct
Start with where the word came from. Multitasking was a computing term first, borrowed in the 1960s to describe a processor interleaving jobs. By the 1980s and 1990s we had lifted it onto people, and it became a badge. Doing three things at once meant you were capable, modern, efficient.
Then the science took it apart. Sophie Leroy, a management professor at UW Bothell, gave the mechanism a name in 2009: attention residue. When you switch from one task to another, part of your mind stays stuck on the first. Her explanation is simple and hard to argue with. "Our brain likes to have things closed, or in good standing, before switching to something else." Leave a task unfinished and it keeps running in the background, quietly degrading whatever you do next.
The American Psychological Association's often-cited work on task-switching put a number on it. Shifting between tasks could cost as much as 40% of productive time. Not a rounding error. A tax on every switch. Around the same time, Stanford researchers found that heavy media multitaskers were actually worse at filtering out irrelevant information, the opposite of the superpower the label promised. Christine Rosen captured the mood in a 2008 essay simply titled "The Myth of Multitasking." The verdict was in, and it stuck for good reason.
None of that has been overturned. I want to be clear about this, because the lazy version of my argument is "AI made multitasking fine again." It didn't. Attention residue is as real today as it was in 2009. If you are holding two hard problems in your own head and flipping between them, you are still paying Leroy's tax in full.
The trick is to stop doing that.
What actually changed
Here is the distinction the old research points straight at, once you look for it. Leroy measured the cost of switching between tasks you are personally executing. The residue is your working memory refusing to let go of unfinished work you own.
Agentic AI changes who owns the unfinished work.
When I design a feature and hand it to an agent, the agent holds the execution state. The half-built thing lives in the harness, not in my head. I am not switching between two things I am doing. I am switching between two things being done for me. The residue gets offloaded to the system, and I get my attention back.
So the unit of multitasking changed. The old unit was tasks I execute, and stacking those was a losing trade. The new unit is agents I supervise, and the waiting between hand-off and result is genuinely free time.
This is the piece people miss. The deep work did not get parallelized. My design and brainstorming are as serial and as focused as ever. If anything they demand more concentration than before, because the quality of the hand-off determines the quality of everything downstream. A vague spec produces vague work on all three monitors at once. What got parallelized is the waiting. Agents now take minutes or hours to do thorough work, and that idle time is where the second and third monitor live.
The mechanics matter here. A year ago an agent finished in seconds, so there was nothing to do while you waited, and the whole idea of a second monitor was pointless. That has flipped. Ask a modern agent to implement a feature, write the tests, run them, fix what breaks, and open a pull request, and it is gone for a real stretch of time. Long enough that sitting and watching it is the waste. The better agents got at sustained, multi-step work, the more the round-robin stopped being a gimmick and became the only sensible way to use the gaps. The pattern didn't come from a productivity theory. It came from watching progress bars and refusing to waste the time in front of them.
I have written before about harness engineering and the AI Conductor Era. This is the personal, day-to-day face of the same shift. The conductor metaphor is about orchestrating agents. This is about what your own attention does while they play.
I am not the only one who found this
When I started working this way it felt like a hack I had stumbled into. It isn't. Some of the most credible builders in the field have landed in the same place, and the tooling market has followed them.
Simon Willison, who co-created Django, wrote in October 2025 about what he called embracing the parallel coding agent lifestyle. Multiple terminals, different agents in different directories, tasks fired off in parallel. His framing matches mine almost exactly. He can only review and land one significant change at a time, but a growing number of tasks can be fired off in parallel "without adding too much cognitive overhead" to that primary work. The deep thread stays single. The waiting gets filled.
Anthropic's own engineers run this at a scale that makes my three monitors look modest. They describe well over a dozen concurrent Claude Code agents across terminal tabs, browser sessions, and a phone, each on its own isolated branch, with notifications pulling them back only when a decision is needed. The Pragmatic Engineer named the whole pattern outright in a piece called "programming by kicking off parallel AI agents." When Gergely Orosz calls something a trend, it has already crossed from anecdote into industry behavior.
The market signal is the loudest part. An entire category of tooling appeared in 2025 and 2026 to manage exactly this: agent orchestrators, parallel session managers, control planes for supervising fleets of agents. Tools get built when a behavior becomes common enough to be worth productizing. The infrastructure catching up to the workflow is the validation.
The honest limit
Now the part that keeps this from being hype. Parallelizing the waiting is not free, and the people doing it are the first to say so.
Addy Osmani, an engineer at Google, wrote the sharpest version of the counterargument. Running agents in parallel, he says, is "not just a question of throughput. It is a new kind of cognitive labor." He names an "ambient anxiety tax," the background vigilance about what might be going sideways in a thread you haven't checked. He puts his own ceiling at three to four threads depending on complexity, and cites Willison's blunter take: four agents in parallel and you're wiped out for the day by late morning.
I feel this exactly. Three products at three monitors is not a number I picked. It is the number where I still understand everything that is happening. Push to a fourth and the residue Leroy described comes back in a new form, not as unfinished tasks in my head but as comprehension debt across threads I am supervising faster than I can truly absorb.
There are two other real costs. Code review has become the bottleneck. Agents produce faster than any human can evaluate, and the judgment work does not parallelize. And there is a burnout thread running under the enthusiasm. Engineers going all-in on agents report working harder and tiring faster, because the stream of small judgment calls never stops. The failure mode isn't running out of agents. It's running out of yourself.
So the skill here is not multitasking. It is designing the hand-off and defending the limit.
What this means
The lesson from twenty years of attention research still holds. Protect deep focus. Do not flip between hard problems you are personally holding. Leroy was right and nothing about AI changes it.
What changed is that you can now take execution out of your head entirely. Do the thinking serially, at depth, on one thing at a time. Hand it off cleanly, with a spec sharp enough and constraints tight enough that the agent can run without you. Then let the waiting, and only the waiting, run in parallel.
My dark lab does the tedium now. The coding, the testing, the deploying. What it gave back is not the ability to do three things at once in my head. It is the ability to spend my whole day on the parts that need me, design and customer engagement, while the parts that don't happen on the other two monitors.
Multitasking was never the problem. Doing the wrong things in parallel was. Get the unit right and the old rule and the new workflow stop being in conflict. They were describing different things all along.