Parallel Agents & the Rotating Door

The Economics of Idle Time

Watch yourself work with a single coding agent and time where your attention actually goes. You write a tight prompt for a small, exact piece of work. The agent runs for a couple of minutes. You glance at the diff, re-prompt, and wait again. Even at this fast grain, half your time is spent watching a spinner — and if you let runs stretch longer, the idle fraction only grows. Idle human time is the waste product of agentic coding, and it appears at every run length.

That ratio is the entire argument for parallelism. A well-scoped agent task needs you at exactly two moments: the prompt, where you load the task with context and constraints, and the review, where you judge what came back. The stretch in between belongs to the machine. If you only ever run one agent, you have bought a very expensive tool and left it idle for most of your day — except the idle resource is not the agent. It is you.

Stacking agents inverts the arrangement. Instead of one task with long human-idle gaps, you interleave several tasks so that your engaged moments — prompts and reviews — line up back to back, and the machine-time gaps overlap each other. Your role shifts from typist to orchestrator and reviewer. The binding constraint on your throughput stops being how fast you can write code, or even how fast one agent can, and becomes two things:

• Review bandwidth — how many diffs per hour you can genuinely read, understand, and judge, without your standards slipping.
• Context-switching cost — how quickly you can drop one task's mental model and fully load another's. This cost is real and it compounds; the techniques later in this module exist mostly to pay it down.

Be honest about what the multiplier multiplies. Six parallel agents give you roughly six times the task throughput — six diffs landing per unit time instead of one. They do not give you six times the quality of thought. All of the thinking still happens at the two human moments: the design decisions and constraints go in at prompt-time, and the judgment is applied at review-time. An agent running unattended is executing your last prompt, not thinking new thoughts on your behalf. If your prompts are vague, parallelism ships six vague implementations instead of one. Parallelism amplifies whatever you put in — which is exactly why the rest of this module is about what you put in.

The Rotating Door

The house technique for sustained parallel operation has a name, and the first thing to understand about it is the timescale: this is a game of minutes and seconds, not twenty-minute waits.

Short Runs, Tiny Reviews

The unit of work is deliberately small: one piece, described exactly, one to five minutes of agent time. At that grain, review collapses to a one-minute chunk — and often nearly disappears. That is not recklessness; it is the payoff of three habits working together:

• You described exactly what you want. The prompt is not "improve the billing page" — it is the specific function, the specific behavior, the files to touch. When the specification is exact, the diff has almost no room to surprise you.
• Your codebase is the showcase. The code you reviewed carefully early in the project — plus your CLAUDE.md — is the pattern the model imitates. Once the first slice of a system is right, every later slice is "do that again, for Y," and the model copies your established shape. You review hard at the start of a pattern, then coast on it.
• You direct piece by piece. Small pieces mean each prompt carries one decision. You are never untangling a 2,000-line surprise, because you never asked for one.

Deep review still exists — for new patterns, risky surfaces, and anything money- or security-adjacent (the review module's tiers apply). But in the steady state of well-patterned work, the touch per agent is a minute, not five.

N Is a Function of Run Length

How many agents can you rotate? Divide the run length by your touch time. If your touches take about a minute, the math looks like this:

The last row is the key insight most people miss: a long run is not a bigger version of a short run — it is a different kind of lane. Kick off a throwaway or highly complex build that needs ten minutes, and those ten minutes are not waiting time. They are room for roughly three full cycles of three short agents. The long lane finishes on its own schedule; you were never watching it.

Shift-Stacking: Match Pace to Importance

The full skill is running lanes of different cadences at once — call it shift-stacking. Two rules govern it:

• The more important the work, the shorter the runs.Serious, production-grade work gets small pieces, exact prompts, and your attention in tight 20-second intervals — you are close to the metal, steering constantly. Throwaway POCs and big exploratory builds get long runs and almost none of your attention. Pace is how you spend attention, and attention goes where consequence is.
• Stack lanes until idle time is zero. A typical stack: four agents grinding long POC builds in the background while you do serious foreground work in short cycles on one or two more. Every time anything finishes — foreground slice or background build — there is already a next touch queued. No spinner-watching, ever.

A concrete ten-minute window: at 0:00 you launch the long lane (a 10-minute POC build) and immediately prompt three short agents on production slices. They come back at the 2-3 minute mark; you touch each for under a minute and re-prompt — that is cycle one. Cycles two and three fill the rest of the window. At 10:00 the POC lands and gets its skim. Twelve short touches, one long lane, zero idle seconds — and the important work got eleven of the twelve touches.

Running N Agents Without Conflicts

The cadence is the human half of the technique. The engineering half is making sure six agents writing code simultaneously never corrupt each other's work. Every parallel-agent horror story — clobbered files, tangled branches, an agent "helpfully" resolving another agent's merge conflict — traces back to skipping one of four rules.

Isolation: One Working Copy Per Agent

Two agents must never share a working directory. Full stop. Even agents assigned to disjoint files will collide on build artifacts, lockfiles, generated code, and git's own index. Give each agent its own working copy and its own branch: a git worktree per agent is the lightweight default, a separate clone if your tooling demands full isolation. Each agent works, commits, and pushes on its own branch as if it were the only developer in the repo. Merging into main happens later, deliberately, by you — isolation means integration is a decision, not an accident.

Decomposition: Tasks That Cannot Conflict

Worktrees prevent filesystem collisions; they do not prevent merge conflicts. If agent 2 and agent 5 both rewrite the same service, the conflict is merely deferred to merge time, where you pay for it with interest. The real defense is upstream, in how you slice the work: decompose along module, service, or file-ownership boundaries so that no two in-flight tasks touch the same files. One agent in the billing service, one in search, one in the docs pipeline, one in test infrastructure — parallel by construction.

You already know this skill. It is exactly how you chop a project for a team of six humans: find the seams, assign ownership, keep interfaces stable while people work behind them. Teammates who cannot conflict, agents that cannot conflict — the same decomposition instinct, applied at a faster cycle time. Engineers who were good at splitting epics across a team are reliably good at splitting work across agents, because it is the same muscle.

When Tasks Must Touch Shared Code

Sometimes the seams do not cooperate: two tasks both need to modify the same interface, the same config, the same core module. Do not parallelize them and hope. You have two clean options:

• Sequence them. Run task A to completion, merge it, then prompt task B against the updated main. The door keeps rotating — B simply enters the rotation one lap later, and some other independent task takes its slot in the meantime.
• Extract the shared change first. If A and B both need a new parameter threaded through a common interface, that threading is its own task: run it alone, merge it, and now A and B are independent again and can run in parallel against the new interface. This is the interface-first sequencing every senior engineer already uses on human teams — land the contract, then parallelize the consumers.

One Integration Point: You

The final rule is about who merges. You merge. You resolve conflicts. Agents never merge each other's branches, never rebase onto each other's in-flight work, never "fix" a conflict they encounter with another agent's changes. An agent resolving a merge conflict is making silent semantic decisions about code written under two different sets of intentions — yours at two different prompt moments — with full context on neither. Integration is where parallel streams become one system, and it is precisely the kind of judgment-heavy, low-volume work that belongs at the human bottleneck on purpose. Keep it there.

Keeping N Contexts Straight

The agents will not be the weak link. You will. Six parallel agents means six mental threads: six task intents, six sets of constraints, six half-remembered decisions about what you told each one. The characteristic failure is context bleed — reviewing agent 4's diff while still mentally inside agent 2's task, approving code because it looks like what you vaguely remember asking someone for. Context bleed does not feel like failure while it is happening; it feels like moving fast. It shows up later, as merged code that answers a question you asked a different agent.

The mitigations are unglamorous and they work:

• One task per agent — never two half-tasks. An agent carrying "finish the retry logic and also look at that logging thing" is two contexts stuffed into one slot, and its review moment forces you to load both at once. If a second task occurs to you mid-run, it goes to the backlog, not into a running agent's lap.
• Keep a visible board. Even a plain text file: one line per agent — name, task, branch, status, what you expect back. Update it at every prompt and every review. The point is that your working memory is not the system of record; the board is. When agent 3 finishes, you read line 3 before you read the diff.
• Name agents by their task. Six terminals named "agent 1" through "agent 6" invite bleed; terminals named rate-limit, billing-webhook, flaky-tests load the right context the instant you look at them. Match the branch names to the same slugs.
• Write the next prompt before reviewing the finished agent. Keep a short queue of pre-written prompts drafted during dead air. When an agent finishes, its next assignment already exists — so the rotation never blocks on you reconstructing "what was I going to have it do next?" from memory, and the review gets your full attention instead of competing with prompt-drafting.

And one rule above the others: the review moment is sacred. Before you judge a diff, fully load that agent's context — reread your prompt to it, check the board line, recall what you expected the shape of the change to be. Thirty seconds of context-loading before reading the first hunk is the difference between reviewing and skimming. If you cannot spare the thirty seconds, you are running too many agents.

When Not to Parallelize

The Rotating Door is a technique for a particular shape of work: independent, well-scoped, reviewable tasks. Plenty of real work is not that shape, and forcing it through the door wastes more than it gains. Know the boundaries:

• Deeply dependent tasks. If task B needs task A's design — B consumes the interface A defines, or B's approach depends on what A discovers — then running them in parallel just means B is built on a guess. Sequence them, or extract the shared contract first as its own task. A dependency chain is a pipeline, not a pool.
• Exploratory work where you need to learn from each step. When the next question depends on the last answer — a spike into an unfamiliar system, evaluating an architectural direction — the human learning between steps is the actual product. Parallelizing exploration produces six answers to questions you no longer would have asked. Run one thread, stay in it, learn.
• Debugging that needs sustained attention. A hard bug is a single evolving hypothesis in your head. Rotating away to review four other diffs mid-investigation destroys exactly the state that makes the investigation converge. Pause the door — or shrink it to the one or two background tasks that cost you nothing — and give the bug your full residency.
• Anything above your review bandwidth. This is the hard ceiling. Six agents producing code you cannot genuinely review is not 6x productivity — it is six times the unreviewed risk, entering your codebase at six times the speed. Every line still merges under your name and your judgment. The Reviewing AI Code module covers what a real review of agent output looks like; the Rotating Door only works when every rotation includes one.

The through-line: parallelism amplifies your judgment; it cannot replace it. Six agents make a strong engineer dramatically more productive and make an absent reviewer dramatically more dangerous. Which one shows up at the door is decided by you, one review at a time.

Finding Your Number

There is no magic number — N is the output of the run-length math above, and your touch time is personal. Calibrate the way you would calibrate anything: start low, add load, watch the right gauge.

• Start with two. Two agents already teach the core skills — worktree hygiene, the board, pre-written prompts, clean context switches — at a pace where mistakes are cheap.
• Add one agent at a time. Run at each level for at least a day before adding the next. The gauge you watch is review quality, not throughput. Throughput will climb with every agent you add right up until well past the point where you should have stopped — it is the wrong instrument. Review quality degrades first, and it degrades before you feel busy.
• When review quality slips, back off one. Not to zero — one. The level below your break point is your sustainable number for that task mix.

Three signals tell you that you are over capacity:

Your number is personal and task-dependent, and it moves. Deep in a codebase you know, on well-decomposed feature work, you might hold six or seven comfortably. In an unfamiliar service, on risky surfaces, three might be honest. The senior move is not running the biggest number — it is knowing your current number, saying it out loud, and adjusting it without ego when the task mix changes.

Knowledge Check

Test your understanding before moving on.