Parallel Coding Agents Aren't 5x Faster: You're the Real Bottleneck

9 A.M., Five Agents Launch at Once

Picture a scenario. At 9:00 a.m., you launch five coding agents across five worktrees and five terminals, each responsible for one task. Forty minutes later: two have finished and are waiting for your review; one got stuck on an error at 9:15; one asked you a question about the database schema at 9:07 and hasn't moved since; and the fifth, as far as you know, is still running.

The agent that asked a question spent 33 minutes waiting for you to notice its prompt. The delay has nothing to do with typing speed — you have five places to look, but only one pair of eyes.

Tools have made launching agents extremely cheap. Claude Code's agent view lists all the background sessions you've started, across all projects. Cursor 2.0 shipped an agent-management sidebar on October 29, 2025, plus the option to "run up to eight agents in parallel on a single prompt." Launching agents is cheap, but none of this makes you read diffs any faster.

When Simon Willison documented his own parallel agent setup, he captured the limit in a single sentence: "The natural bottleneck here is my own speed at reviewing the results." He still runs multiple agents, but he's very precise about what he gets from it: "I can only focus on reviewing and landing one meaningful change at a time." What parallelism actually buys you is more low-load work happening simultaneously — especially research and proof-of-concept work.

That's the honest version of the parallel-agent pitch. Five agents give you five workers. They don't give you five reviewers, five people to answer "should I drop this column?", or five people to approve shell commands. There's only one of those, and it's you.

The Queue Math Isn't on Your Side

Every agent runs the same loop: work, get blocked on a question or permission prompt, wait for you, work again. While waiting it does nothing, but the clock keeps ticking.

Two results from queueing theory fit this scenario perfectly. Little's law says that in a stable system, the average number of items equals the arrival rate times the average time each item spends in the system: L = λW. Read it in terms of agents: the number of agents idling while waiting for your response equals how often they ask you questions times how long each wait lasts. Run more agents and λ rises. If W doesn't fall, more agents sit idle at any given moment.

Kingman's formula estimates wait times in a single-server queue. Its first factor is ρ/(1−ρ), where ρ is how busy the server is. You are that server. At 50% busy the factor is 1, at 80% it's 4, at 90% it's 9. Wait times climb slowly at low load and skyrocket near the top.

The second factor in the formula grows when arrivals bunch up, and agent questions tend to bunch up. Five agents launched in the same minute may hit their first decision points at nearly the same time.

This is a rough model. Humans aren't servers with a fixed service rate, but the shape holds: your fifth agent makes you wait more than your second did.

Little's law was proven by MIT professor John Little in 1961 and is one of the most fundamental and robust results in queueing theory: in a stable system, the average number of items in the system L equals the arrival rate λ times the average time each item spends in the system W, i.e., L = λW. Its beauty is that it relies on almost no distributional assumptions — whether service times follow an exponential distribution or an arbitrary one, the relationship holds as long as the system is stable. As a result it's widely used in call centers, hospital emergency rooms, manufacturing assembly lines, and network traffic analysis. Applied to the parallel-agent scenario, you interpret "arrival rate" as how often agents ask you questions and "sojourn time" as how long each agent waits for your response; the product is the average number of agents idling while waiting for you at any given moment. This means: with response speed held constant, doubling the number of agents roughly doubles the number of agents idling waiting for you, rather than keeping it flat.

Kingman's formula is an approximation proposed in 1961 by British mathematician John Kingman to estimate the average wait time in a single-server queueing system (a GI/G/1 queue). It decomposes wait time into a product of several factors, the most critical being ρ/(1−ρ), where ρ is the server's utilization (the fraction of time it's busy). When utilization rises from 50% to 80%, this factor jumps from 1 to 4; as it approaches 95%, it reaches 19 and wait times explode. Another factor in the formula reflects the variability of arrival and service times: the more bunched the arrivals, the longer the waits. This explains why, with a fixed amount of human capacity (a single server), simply adding agents causes wait times to deteriorate nonlinearly — you keep pushing utilization higher, and the high range is exactly where waits grow fastest.

Every Context Switch Costs More Than the Answer

This model treats answering a question as a fixed cost. It isn't, because every answer begins with recalling what that agent was doing.

Chris Parnin and Spencer Rugaber studied exactly this problem for programmers. In "Resumption Strategies for Interrupted Programming Tasks," they analyzed 10,000 recorded programming sessions from 85 programmers. They found that "only 10% of programming sessions began coding activity within a minute" and that only 7% of sessions edited anything before navigating elsewhere in the code. Returning to a task usually means walking around the code first to rebuild context.

With five agents, you do this all day. Agent 2's question is about a schema you last thought about forty minutes ago. Agent 4's diff touches a module you haven't opened all week. Every jump makes you pay the resumption cost again. And that study measured programmers returning to their own code; an agent's diff is someone else's code, which is rarely easier.

There's another trap here. Gloria Mark, Daniela Gudith, and Ulrich Klocke tested interrupted work in their CHI 2008 paper "The Cost of Interrupted Work: More Speed and Stress." People finished interrupted tasks in less time with no difference in quality, but the abstract names the price: "People compensate for interruptions by working faster, but this comes at a price: experiencing more stress, higher frustration, time pressure and effort."

That study looked at office tasks. My worry for agents is what "working faster" turns into. Faster approvals. A glance at a permission prompt. Merging a diff you only half read. The queue gets shorter, and you pay in stress or review quality.

Chris Parnin and Spencer Rugaber's study was published at the 2009 IEEE International Conference on Program Comprehension (ICPC). By recording 85 programmers across roughly 10,000 programming sessions, they systematically analyzed how programmers resume tasks after interruptions. The core finding: resuming an interrupted programming task isn't instantaneous — it requires a series of "navigation actions": reopening files, scrolling to relevant locations, re-reading context, and rebuilding a mental model of the problem. Only about 10% of sessions resumed coding within a minute of an interruption, and only 7% edited anything before navigating elsewhere in the code. This means the resumption cost is fundamentally a "context-rebuilding cost," strongly tied to how long you've been away from the task and how familiar you are with that code. For multi-agent scenarios, this cost means every switch amounts to a cold start for your working memory.

Limit Agent Count, Then Serve the Longest-Waiting First

Only run as many as you can review. Not as many as your machine, your plan, or your tools allow. If you can only review one meaningful change at a time — as Willison describes himself — then one or two agents is your number for code you intend to merge, plus research tasks you can ignore for an hour. Everything else goes into a queue, and the next task only starts when a slot frees up. This also saves quota. Claude Code's agent view documentation notes that "running ten agents in parallel burns through quota roughly ten times as fast as running one."

Unblock first, review second, and unblock the longest-waiting first. A finished agent has its work already on disk. Waiting another ten minutes costs nothing. A blocked agent loses all ten of those minutes. So unblock first: answer questions, approve or reject commands, then review completed work while the unblocked agents keep running. Among blocked agents, handle the one that's waited longest. This minimizes the worst-case wait.

Notification pushes violate both rules at once. They fire for what just happened, so the agent that pinged you last gets your attention, and the one that asked half an hour ago doesn't.

Gloria Mark, Daniela Gudith, and Ulrich Klocke published their study at CHI 2008 (the top conference in human-computer interaction). They experimentally compared interrupted and uninterrupted office workers on task completion time, quality, and mood. The conclusion: interrupted people did finish tasks in less time with no significant drop in output quality, but they reported higher stress, frustration, time pressure, and effort. In other words, people compensate for the time lost to interruptions by "speeding up," at the cost of higher mental load. The takeaway for agent scenarios is that passing review faster doesn't mean judging more accurately — it may just mean trading higher cognitive pressure for a shorter queue.

What This Looks Like in Hermes IDE

I develop Hermes IDE, so read this section with that caveat in mind. Hermes lets Claude Code, Codex, and other CLI agents run side by side, each in its own terminal and worktree. You set the cap. Hermes helps with the second rule: seeing who's waiting and for how long.

Each session shows a status: working, needs approval, asked you, done, error, or idle. When Hermes is only guessing at a status, it says so. A false "working" makes a blocked agent look busy, and that agent silently drops out of your queue.

An attention inbox counts the agents blocked on you. ⌘I (Ctrl+Shift+I on Windows and Linux) jumps to the longest-waiting agent. You answer in that agent's own terminal. Hermes never answers permission prompts for you and never types in a terminal itself. Notifications fire when an agent is blocked or done, and skip the session you're looking at.

Hermes isn't the only tool tracking who's waiting. Claude Code's agent view has a "Needs input" status, a top line counting sessions awaiting input, and terminal tab titles like "2 awaiting input." If all your agents are Claude Code, that may be enough, though its docs label agent view a research preview.

Cursor's eight-agent mode runs one prompt across multiple agents, so you're comparing multiple attempts at the same task — a different kind of work. Hermes is for when your agents come from different vendors and you want a unified inbox.

It's a desktop app for macOS, Windows, and Linux, free to download, with source visible under BSL 1.1, and unaffiliated with Nous Research, Anthropic, OpenAI, or any agent vendor.

How Much Can You Actually Review?

Think back to last week. Count how many agents were blocked longer than they worked. That number will guide your cap better than any tool's maximum. What's your cap, and what's stopping you from adding more agents?

The queue is both a tooling problem and a habit problem. In the systems you build, the queue is the software: workers pulling tasks, retries running twice, consumers needing idempotency, plus sagas and outboxes spanning services.

One-line Summary

Parallel agents are bottlenecked not by the machine but by you — limit the count, unblock first, serve the longest-waiting first, and you won't waste compute or wreck review quality.

Paragraph Summary

When you run multiple coding agents in parallel, the real bottleneck is your own speed at reviewing results, answering questions, and approving commands — not how fast the agents run. Drawing on Little's law and Kingman's formula, the author explains why adding agents leads to more idle waiting, since you're the single-server queue and waits grow nonlinearly at high utilization. Interruption-resumption research further shows programmers need over a minute on average to rebuild context, and that interrupted work gets done faster but with more stress and worse judgment. Two practical strategies follow: run only as many agents as you can review, and prioritize unblocking the longest-waiting first. The article closes with a look at the author's Hermes IDE and how session-status tracking and an attention inbox can manage the parallel-agent queue.