Running five agents in parallel is being interrupted at scale
The productivity advice of the moment says to orchestrate a fleet of coding agents. The science of interruptions, measured twenty years earlier, says to do the math first.
Terminal two's agent just finished. You're in the middle of the diff in terminal four, holding in your head the reason a migration touches three tables, when the notification lands: "task complete". You switch tabs, because an idle agent is money on fire. Twenty minutes later you come back to the migration diff and stare at the screen with the exact feeling of walking into the kitchen and forgetting what you came for. The three tables are still there.
The reason for them has evaporated.
If that scene feels familiar: it's not an attention deficit, not a lack of discipline, not you "not being cut out for working with agents". It's a phenomenon that was measured, published, and quantified before LLMs existed, and its price tag is far worse than the productivity discourse admits.
The five-terminal orthodoxy
Somewhere between 2024 and 2025, the standard AI productivity advice shifted from "use an assistant" to "orchestrate several". Anthropic itself recommends, in the Claude Code best practices guide, keeping multiple checkouts of the repository with git worktrees and running parallel sessions in each. By early 2026, it became an official feature: coordinated agent teams, with a shared inbox and task list. The documentation recommends three to five per team, and the launch demo featured 16 agents building a C compiler. Threads on X show off grids of six terminals like trophies. The engineer running a single agent is now described as someone leaving productivity on the table.
The reasoning sounds solid: the agent takes minutes to finish a task, and you sit there watching text pour down the screen. Idle time. If one agent works while you wait, five agents work five times as much. The math checks out, as long as you accept the hidden premise: that your role in this arrangement, receiving the result, understanding it, and judging it, has a switching cost of zero.
Recalling the premise is what a 2021 book on cognitive science, The Programmer's Brain by Felienne Hermans, dismantles chapter by chapter, citing research published long before. Because every cycle of prompt, wait, and review has an old name in the literature: interruption. And interruption is one of the best-measured things in all of programming research.
Fifteen minutes, with a paper
First, some ground-clearing. The most famous number in this field, the "23 minutes to recover focus" attributed to researcher Gloria Mark, has an embarrassing provenance: it came from a 2006 interview, and nobody has ever located a paper that contains it. What Mark actually published, in a 2008 study, points in the same general direction (interrupted work does get finished, but at the cost of more pressure and stress), just without the round number that became a consulting slide.
The numbers I'm going to use here have papers, OK? OK.
Chris Parnin and Spencer Rugaber analyzed more than 10,000 recorded programming sessions from 86 programmers to understand what happens when a developer gets interrupted. The central findings:
after an interruption, it takes on the order of 10 to 15 minutes before the person is editing code again.
The Dutch researcher Rini van Solingen had already measured this in the nineties; Parnin's data found the number again. Interrupted in the middle of editing a method, the programmer managed to resume in under a minute in only 10% of cases. And only 7% of sessions resumed editing without first navigating through other parts of the code, because that's what resumption demands: rebuilding by hand, file by file, the mental model the interruption erased.
The mechanism behind that cost shows up in an interesting Japanese experiment, small but suggestive, that measured blood flow in the cortex of programmers reading code, using infrared sensors on the forehead. The peak of cognitive load isn't at the start or the end of the task: it's in the middle.
So, bear with me: code comprehension has a warm-up phase.
You spend the first minutes assembling the model, reach operating temperature, and only then are you actually working. It's what we've always called "getting into flow" (now with thermal imaging).
Put the two together, and the scene from the opening becomes a diagram. When the agent in terminal two pings, you're at the peak of terminal four's curve, at the exact point where the mental model is most expensive and least consolidated. The switch throws that model away. When you come back, you don't resume from the peak: you restart from the ramp.
And there's a cruel detail in the historical comparison. In Parnin's data, collected in a world of coworkers, meetings, and email, the typical programmer got a single two-hour session without interruption per day. That was the environment our industry spent a decade denouncing, with manifestos against open offices, against Slack, against status meetings. Then we took that environment and turned it into a productivity target: a workflow whose basic unit of operation is being interrupted by a machine that finished its homework.
Real multitasking requires one task on autopilot
Here someone always objects: but I'm not being interrupted, I'm multitasking. Managers do it all day. A conductor directs sixteen musicians. Why couldn't I direct five agents? Although I love the enthusiasm, It’s not as simple as “just do it“.
Doing two things at once only works reasonably well when at least one of them is in the phase psychology calls autonomous. In other words, so well trained it runs without consuming working memory. That's why you can run while listening to an audiobook and knit while watching a show. Running and knitting, for someone with years of practice, cost almost zero cognition. It's also why you turn the radio down to park in a tight spot:
when the main task tightens, the brain itself asks to shut off the parallel one.
Now the question that dismantles the conductor analogy: which of your tasks is in the autonomous phase when you orchestrate five agents?
Reviewing an agent's output is not checking whether the intern indented properly. It's reading dense code you didn't write, in a style that isn't yours, deciding whether it can go to production. I've written a whole post about why this is the part of the job that doesn't compress: it's deep comprehension work, the kind of task the studies flag as the hungriest for working memory in all of programming.
And it never reaches the autonomous phase, for a structural reason: automation comes from repeating the same task until it becomes reflex, and every agent diff is, by definition, new. New code, new context, new traps(?). You are not conducting sixteen musicians who know the score. You are taking five reading comprehension exams interleaved, switching texts every few minutes.
At this point you might have a straightforward inference about what the research on what happens under that regime is. And you’re absolutely correct (I assume): consistent and unpleasant.
A 2009 study showed that students reading a text while answering instant messages took significantly longer overall. Another, from 2010, with 219 students, found significantly worse GPAs among Facebook users, with a detail that matters a lot here: three out of four believed the network had no impact on their performance whatsoever.
Perception and measurement don't just diverge; they tend to point in opposite directions.
It's the same pattern as the 2025 METR study, which I picked apart in the post about the comprehension bottleneck: developers feeling 20% faster with AI, and measuring 19% slower. Six open terminals produce the feeling of a mission control room. Unfortunately, the feeling doesn't show up in the changelog.
The math
Let's do the arithmetic the five-agent advice skips.
Suppose each agent finishes a task every 20 minutes, a modest pace. Five agents generate, on average, one "done" every 4 minutes. Each of those events demands from you the comprehension work described above, on a context different from the one in your head. If fully resuming a context costs the 10 to 15 minutes Parnin measured, you are operating permanently below working temperature, in every context at once.
There is no peak of the curve for you. Only ramp.
The cost isn't just slowness. Brian Bailey and Joseph Konstan's 2006 experiment measured what happens to quality: interrupted in the middle of a task, instead of at the boundary between tasks, people made twice as many errors, and reported up to twice the anxiety. Twice the errors, on the one task whose entire purpose is to be the quality gate between the agent's code and production. The five-agent setup maximizes the interruption rate of exactly the person whose mistakes cost the most in the whole system.
And note that none of this is the token cost, which is the only one that shows up on the invoice. Anthropic itself published that multi-agent systems burn around 15 times more tokens than a regular conversation. Everybody debates that number, because it comes in dollars. The interruption tax doesn't come in dollars. It comes in approved bugs, in Friday rework, and in the phenomenon that closes the loop: the day ends, you were busy every minute of it, and sometimes you can't say with what.
The industry discourse even coined a pretty name for the next stage, "agent babysitting", usually framed as a problem to solve with more autonomy for the agents. Almost never with the prior question: how many babies can a single babysitter handle?
The problem isn't the interruption, it's the timing
If the essay ended here, it would be a Luddite manifesto: turn off the agents, go back to vim, one thing at a time. I don’t think so. The same Bailey experiment that measured double the errors also measured the way out, and it's more interesting than abstinence.
It didn't vary whether people got interrupted, only when.
The same notifications, delivered at the boundary between tasks instead of in the middle of them, had a drastically lower cost in errors, time, and anxiety. Interruption at the boundary is almost free. Interruption in the middle is where the double error rate lives. That finding even produced hardware: a researcher in Zurich built the FlowLight, a desk light that infers from keyboard and mouse activity whether the developer is in deep focus and signals coworkers not to interrupt. In a field study with more than 400 participants, it cut interruptions by 46%.
We spent years building protection against human interruption, do-not-disturb statuses, focus blocks on the calendar, and then plugged into our own screens a source of interruptions that doesn't read statuses: the agent pings when it finishes, and it finishes whenever it finishes. A polite coworker waits for you to take off your headphones.
The agent orchestrator is the clueless coworker, industrialized.
Except that, unlike the coworker, the agent is infinitely patient and takes no offense at waiting in line. And that changes the entire design, because the 2026 tool has a property no human interrupter ever had: the timing of the interruption is 100% configurable. You can apply Bailey's finding directly.
Pull, don't get pushed. Agent results go into a queue, and you drain the queue when you close out a subtask of your own, not when the notification arrives. It's the difference between email and the telephone. A real-time "task complete" notification is the phone ringing: turn it off.
Check in at your own boundaries. The time to dispatch tasks and review results is the natural gap between your blocks: you finished reviewing an entire diff, closed a line of reasoning, then you open the queue. Bailey showed that the same workload, shifted to the boundary, costs half the errors.
Review in batches, by context. Three results from the same subsystem, read back to back, pay for one warm-up. The same three interleaved with two others from different contexts pay for five. The warm-up curve is the argument against round-robining terminals.
Protect your resumption. The techniques Parnin observed in programmers themselves carry over whole. Before switching to an agent's result, dump your mental model into a comment: "stopped here because X, next step was Y". Some programmers in the study deliberately left a compile error in the code before stepping away, a roadblock that guarantees the unfinished version can't pass for done and drops you right back at the stopping point. It costs thirty seconds and refunds a good chunk of the resumption ramp.
note: That’s why TDD is so effective.
Worth saying what this critique doesn't reach: work that barely requires comprehension parallelizes fine. A lint pass, a mechanical codemod, a dependency bump with a strong test suite, the kind of change you judge by the CI result, not by reading it. The interruption tax falls on work that requires understanding. It's only there, which happens to be where the risk lives, that the five-terminal math falls apart.
And the heretical question: is five even the right number? The token math is linear, but the comprehension math isn't. Two agents with long, well-specified tasks and verifiable acceptance criteria (tests that must pass, a plan approved up front) generate fewer interruptions, more natural boundaries, and deeper reviews than five agents on short tasks. The throughput that matters belongs to the one component that doesn't get a new instance per prompt: you.
The open office fits in a terminal
My read of the moment is this: the industry correctly diagnosed that waiting on an agent is a waste, and prescribed the wrong medicine because it did the math on the wrong side of the table. It optimized the utilization of the agent, which is abundant, cheap, and patient, at the cost of the utilization of the human, who is the scarce, expensive resource with a warm-up phase. Any engineer who sizes systems recognizes the mistake: saturating the cheap resource and bottlenecking on the expensive one.
You don't need to throw the agents away. You need to treat them the way we learned, painfully, to treat coworkers: a queue instead of a shoulder tap, an async message instead of a phone call, respect for the closed door. All the research already existed when the first six-terminal grid was posted as a trophy. Parnin measured the cost in 2011, Bailey found the timing solution in 2006, and Hermans organized it all into a book in 2021, three years before we needed it.
We spent twenty years learning that interrupting a programmer is expensive, then built a programmer-interrupting machine and called it productivity. Well… For the first time, though, the interrupter takes orders. It waits as long as you tell it to. The queue was always possible; what was missing was a coworker patient enough to stand in it.
Going deeper:
Felienne Hermans, "The Programmer's Brain: What Every Programmer Needs to Know About Cognition" (Manning, 2021), especially chapter 11
Chris Parnin and Spencer Rugaber, "Resumption strategies for interrupted programming tasks", Software Quality Journal 19 (2011); Chris Parnin, "Programmer, Interrupted" (blog, 2013)
Rini van Solingen, Egon Berghout, and Frank van Latum, "Interrupts: Just a Minute Never Is", IEEE Software 15 (1998)
Brian Bailey and Joseph Konstan, "On the need for attention-aware systems: Measuring effects of interruption on task performance, error rate, and affective state", Computers in Human Behavior 22 (2006)
Takao Nakagawa et al., "Quantifying programmers' mental workload during program comprehension based on cerebral blood flow measurement", ICSE Companion (2014)
Manuela Züger et al., "Reducing Interruptions at Work: A Large-Scale Field Study of FlowLight", CHI 2017
Annie Beth Fox, Jonathan Rosen, and Mary Crawford, "Distractions, distractions: does instant messaging affect college students' performance on a concurrent reading comprehension task?", CyberPsychology & Behavior 12 (2009)
Paul Kirschner and Aryn Karpinski, "Facebook and academic performance", Computers in Human Behavior 26 (2010)
Gloria Mark, Daniela Gudith, and Ulrich Klocke, "The Cost of Interrupted Work: More Speed and Stress", CHI 2008 (and, on the dubious provenance of the "23 minutes", the trail published on the oberien.de blog, 2023)
Anthropic, "How we built our multi-agent research system" (2025), "Claude Code: Best practices for agentic coding" (2025), and the Claude Code agent teams documentation (2026)
METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (2025)