- Book: Event-Driven Architecture Pocket Guide
- The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
At 9:00 you started five coding agents, one task each, in five worktrees and five terminals. Forty minutes later, two have finished and are waiting for review. One hit an error at 9:15. One asked you a question about the database schema at 9:07 and has done nothing since. The fifth is still working, as far as you can tell.
That fourth agent spent 33 minutes of its morning waiting for you to notice a question. The delay had nothing to do with typing: you had five places to look and one pair of eyes.
The tools made launching easy. Claude Code's agent view lists every background session you've started, across all your projects. Cursor 2.0 shipped on October 29, 2025 with a sidebar for managing your agents and the option to "Run up to eight agents in parallel on a single prompt." Starting agents is cheap now, and none of that made you any faster at reading diffs.
Simon Willison named the limit in one line when he wrote up his own parallel-agent setup: "the natural bottleneck on all of this is how fast I can review the results." He still runs several agents, and he is precise about what that buys him: "I can only focus on reviewing and landing one significant change at a time." What parallelism does buy him is more low-load work running alongside, research and proofs of concept especially.
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 a shell command. There's one of those, and it's you.
Every agent loops through the same cycle: work, get blocked on a question or a permission prompt, wait for you, work again. While it waits, it does nothing, and the clock keeps running.
Five workers, one reviewer. Every question waits in the same line.
The queue math is not on your side
Two results from queueing theory fit this well. Little's law says the average number of items in a stable system equals their arrival rate times the average time each one spends there: L = λW. Read it with agents. The number of agents sitting idle on you equals how often they ask for something times how long each one waits for an answer. Run more agents and λ goes up. If W doesn't come down, more of your agents are idle at any given moment.
Kingman's formula estimates the wait in a single-server queue. Its first factor is ρ/(1−ρ), where ρ is how busy the server is. You are the server. At 50% busy that factor is 1. At 80% it's 4. At 90% it's 9. The wait climbs slowly at first and steeply near the top.
The formula's second factor grows when arrivals bunch up, and agent questions tend to bunch. Five agents started at the same minute can reach their first decision points close together.
This is a rough model. People aren't servers with a fixed service rate, but the shape holds: the fifth agent you add costs you more waiting than the second one did.
Every jump costs more than the answer
The model treats answering a question as a fixed cost. It isn't, because each answer starts with remembering what that agent was doing.
Chris Parnin and Spencer Rugaber studied this for programmers. In Resumption Strategies for Interrupted Programming Tasks they analysed 10,000 recorded programming sessions from 85 programmers. They found that "only 10% of the programming sessions have coding activity start in less than a minute," and only 7% involved no navigation to other places in the code before editing. Getting back into a task usually means walking around the code first to rebuild context.
With five agents you do that all day. The question from agent 2 is about a schema you last thought about forty minutes ago. The diff from agent 4 touches a module you haven't opened this week. Each jump pays 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 a trap here too. Gloria Mark, Daniela Gudith and Ulrich Klocke tested interrupted work in The Cost of Interrupted Work: More Speed and Stress (CHI 2008). People finished interrupted tasks in less time with no difference in quality, but the abstract spells out the bill: "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 with agents is what "working faster" turns into. It's approving faster. Skimming the permission prompt. Merging the diff you read half of. The queue gets shorter, and you pay for it in stress or in review quality.
Cap the agents, then serve the oldest first
Run only as many agents as you can review. Not as many as your machine, your plan or your tool allows. If you can review one significant change at a time, as Willison says of himself, then one or two agents writing code you intend to merge is your number, plus whatever research tasks you can ignore for an hour. Everything else goes in a queue, and the next task starts when a slot frees up. It saves quota as well. Claude Code's agent view docs note that "running ten agents in parallel uses quota roughly ten times as fast as running one."
Unblock before you review, and unblock the oldest first. A finished agent has its work on disk. It loses nothing by waiting another ten minutes. A blocked agent loses all ten. So unblock first: answer the question, approve or reject the command, then review finished work while the unblocked agents run. Among the blocked ones, go oldest first. That caps the worst wait.
Notifications push against both rules. They fire for whatever just happened, so the agent that pinged last gets your attention, and the one that asked half an hour ago doesn't.
Cap what runs at what you can review, and serve the one that has waited longest.
What this looks like in Hermes IDE
I build Hermes IDE, so weigh this section with that in mind. Hermes runs Claude Code, Codex and other CLI agents side by side, each in its own terminal and its own worktree. The cap is your call. Hermes helps with the second rule: seeing who is waiting, and for how long.
Every session shows one status: working, needs approval, asked you, done, error or idle. When Hermes is only guessing a status, it says so. A wrong "working" makes a blocked agent look busy, and that agent drops out of your queue without anyone noticing.
An attention inbox counts the agents blocked on you. ⌘I (Ctrl+Shift+I on Windows and Linux) jumps to the agent that has waited longest. You answer in that agent's own terminal. Hermes never answers a permission prompt for you and never types into a terminal on its own. Notifications fire when an agent is blocked or done, and skip the session you're already looking at.
Hermes isn't the only tool that tracks who is waiting. Claude Code's agent view has a "Needs input" state, a line at the top that counts sessions awaiting input, and a terminal tab title like "2 awaiting input". If all your agents are Claude Code, that may be all you need, though its docs mark agent view as a research preview.
Cursor's eight-agent mode runs one prompt across several agents, so you are comparing attempts at one task, which is a different job. Hermes is for when your agents come from different vendors and you want one inbox for all of them.
It's a desktop app for macOS, Windows and Linux, free to download, source-available under BSL 1.1, and not affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.
How many can you actually review?
Look back at last week. Count the agents that sat blocked longer than they worked. That number is a better guide to your limit than any tool's maximum. What's yours, and what made you stop adding agents? Tell me in the comments.
If this was useful
The queue is a tooling problem as much as a habit, and Hermes IDE is my attempt at the tooling side: one status per session, an inbox of the agents blocked on you, and ⌘I to the one that has waited longest. Download it, and if it saves you a morning, star it on GitHub.
In this post the queue was you. In the systems you build, the queue is software: workers pulling jobs, retries that run twice, consumers that need to be idempotent, and sagas and the outbox for work that spans services. The Event-Driven Architecture Pocket Guide is a short read on those patterns and the traps that come with them. It's one of 8 short books in the Pocket Guides for Developers series, covering agents, RAG, prompts, observability, events, databases and system design: the whole series.
Top comments (0)