Stop the Line. Ten Agents Passed Every Test. It Still Broke.

Ten desks writing in parallel. One door into main.

Pull up a chair. Today on r/ClaudeCode, somebody asked the most modern question in software right now:

“Running multiple Claude agents in parallel: how do you get their work into main?”

The question is not “how do I get agents to write code?” That part is solved, shipped, and honestly a little addictive. The question is the landing: ten agents finish, ten branches sit there glowing green, and main — the one branch everybody shares, the one that has to keep working — still takes exactly one change at a time.

Spawning the agents is a fun afternoon. Landing their work is the rest of your week.

And this is no longer a party trick. Anthropic relaunched Claude Code Projects around parallel cloud sessions, each thread on its own branch. OpenAI’s Codex shipped subagents for parallel work. Other tools run five agents at once across isolated worktrees (separate checkouts — we will get there). Writing just went parallel, everywhere, at once. Merging did not get the memo. So let us plan the merge.

One checkout cannot host ten agents

First, the mistake almost everyone makes on day one: three terminals, all opened in the same repository folder, three agents told to start fixing things.

Picture a kitchen with one cutting board and three chefs. Elbows everywhere, one knife, everybody chopping on top of everybody else’s onions. That is your repository folder with three agents in it. And notice: this is not a prompting problem or an intelligence problem. It is a plain, boring filesystem problem.

A working directory (the folder of checked-out files you actually edit) holds exactly one state: one branch checked out, one staging area (git’s holding pen where changes wait before they become a commit), one set of files on disk. Agent A edits a file; Agent B reads that same file mid-edit and builds on a half-finished thought. Agent C stages its work and quietly sweeps A’s unfinished edits into its own commit. They are not collaborating. They are overwriting each other in turns and calling it teamwork.

One desk, one worker. If you want ten workers, you need ten desks.

One worktree per agent

The desk already exists, and git has shipped it for years: the worktree.

A worktree is a second (third, tenth) working directory attached to the same repository. One repository keeps the history, the branches, the config — all of it shared. Each worktree gets its own files on disk, its own staging area, and its own checked-out branch. Same warehouse, separate workbenches.

# from your main checkout — one desk per agent, one branch per desk
git worktree add -b agent/auth ../wt-auth main
git worktree add -b agent/billing ../wt-billing main
git worktree add -b agent/tests ../wt-tests main

git worktree list # see every desk and what it is holding
# when an agent is done and merged:
git worktree remove ../wt-auth
git worktree prune # clears desks deleted by hand

Two details matter. -b agent/auth creates the branch and checks it out in the new folder, starting from main — always fresh main, never another agent’s branch, unless you enjoy inheriting half-landed work. And git itself enforces one branch per desk: it refuses to check out a branch another worktree already holds. The isolation is not a pinky-promise convention. The tool enforces the important half of it.

Claude Code will build the desk for you:

claude --worktree auth-fix

That creates a worktree at .claude/worktrees/auth-fix/, on a new branch named worktree-auth-fix, and starts the session inside it. By default it branches from your remote’s default branch; a setting (worktree.baseRef) can branch it from your current local work instead. A subagent can be handed its own worktree automatically — put isolation: worktree in its frontmatter (the little config block at the top of its definition file). When a session ends clean, its worktree is removed; when there is work in it, you get asked. Your repository needs at least one commit first — worktrees branch from history, and an empty repo has none.

Now the gotcha that will waste your first hour: a worktree is a fresh checkout. Your .env file (your local secrets and settings — deliberately never committed) is not in it. Your installed dependencies are not in it. The agent’s tests will fail, loudly, for reasons unrelated to the task. Claude Code has a bandage: a .worktreeinclude file lists gitignored files, like .env, to copy into every worktree it creates. Dependencies you still install per worktree — or script into the setup, once, before agent number two ever starts.

Parallel desks, one door: worktrees feed the queue, the queue feeds main.

Green alone, broken together

Desks solved. Everyone writes in peace. Now the part the thread is actually about.

Git can see a textual conflict — two branches editing the same lines of the same file. It flags it, you resolve it, life moves on. What git cannot see is the semantic conflict : two changes that never touch the same line and still break each other.

The classic shape, as an illustrative pair: Agent A renames a function and updates every caller it can see. Agent B, at its own desk, writes a new feature that calls the function by its old name. Both branches pass every test — on B’s base the old name still exists; in A’s world the rename is complete. Merge both, and the build falls over. Nobody made a mistake. The combination is the mistake.

The longer branches live, the wider this gap grows — every desk is working from a photograph of main that gets older by the hour. So the first rule of agent branches is not about tools at all: small and short-lived. One single-purpose change per agent, landed the same day it was written. A week-old agent branch is not a branch; it is a fork with good intentions.

Agents made writing parallel. Main is still a single door — and somebody has to hold it.

One door into main: the merge queue

So: many writers, one door. You can let everyone shove — merge whenever your own checks go green, fastest click wins — and discover semantic conflicts the traditional way, in production’s waiting room. Or you put a queue at the door.

A merge queue is exactly what the name says: pull requests (proposed changes, waiting for review and checks) line up in order, and the queue lands them one at a time — but not blindly. For each entry, the queue builds the future main: the latest main, plus every pull request queued ahead of yours, plus yours, and runs the full required checks on that combination. Land only if the combination passes. If yours fails, it is removed from the queue, the entries behind it are re-tested without it, and the line keeps moving. One bad change costs its author a trip to the back of the line — it does not block everyone else’s afternoon.

GitHub ships this built in. Two pieces of setup, and the second one bites everyone once:

1. In the branch protection rule for main, turn on Require merge queue , and pick your merge method.

2. Your CI (the automated build-and-test pipeline) must also run for the queue. In GitHub Actions, that means the merge_group event next to the usual one:
   

name: CI
on:
  pull_request:
  merge_group: # without this line, the queue waits forever
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Forget merge_group and the required check never reports for queue entries — the queue sits there, polite and frozen, and nobody knows why. (On third-party CI, the same job runs on the queue’s temporary branches, which carry the gh-readonly-queue/ prefix.) Yes, CI now runs twice per change — once on the pull request, once in the queue. That is not waste. The first run asks “is this change sound?” The second asks the harder question: “is it sound in the future it is about to join?”

Two honest limits. The queue is a GitHub feature for public repositories owned by an organization, and private ones on GitHub Enterprise Cloud — a personal repo does not get one today, and there the discipline below matters even more. And the queue does not review anything. It orders and re-tests. Approval is still a human job — which brings us to the wall at the end of this post.

Same agents, same code. The only difference is the door.

Landing styleHow main stays greenWhere it breaksEveryone merges when readyEach PR passed on its own baseGreen alone, broken together — conflicts found after landingManual update-and-retest loopAuthors keep rebasing onto latest main and re-running checksHuman babysitting; the fastest click wins, everyone else restartsOne merge queueEvery entry tested on top of all entries ahead of itCosts a second CI run per change; needs the merge_group setup done right

The bottleneck nobody plans for

Here is the number that should be printed on every “we run ten agents now” announcement.

A study of 718 firms — Chen and Stratton’s “Artificial Intelligence in the Firm,” built on engineering telemetry and GitHub data for more than 725,000 workers — found that after coding agents arrived, lines of code per worker rose about 30% and pull requests about 23%. Resolved issues and epics, the study’s measure of actually-shipped work, did not significantly move. The time from opening a pull request to merging it rose 49%. The share sent back for changes nearly doubled. Review comments per pull request rose 35%. The authors’ conclusion fits on a sticky note: code review becomes the bottleneck.

Read that as an operator, not a headline. Generation is now parallel and nearly free. Review — reading a change, holding its context in your head, judging whether it should exist — is still serial, still human, still priced in hours of attention. Ten agents do not produce ten times the shipped software. They produce ten times the review queue, staffed by the same humans it always was.

So budget honestly. The number of agents you can run is not set by your laptop or your API bill. It is set by how many changes your reviewers can read carefully in a day. Keep each change small enough to review in one sitting — if a review takes an hour, the task was too big, and that is a planning failure, not an agent failure. And name the door-holder before you start: somebody owns the queue each day and says “enough desks” when the review pile says so.

Before you spawn agent number six

• One worktree, one branch, one agent — never two agents in one checkout; git enforces the branch half, you enforce the rest.

• Branch from fresh main — never from another agent’s branch; a stale base is tomorrow’s conflict with today’s date on it.

• One reviewable change per agent — small, single-purpose, landed the same day it was written.

• Sort the fresh checkout first — .worktreeinclude for .env, dependencies installed per worktree, before the agent starts, not after its tests fail.

• CI runs on pull_request AND merge_group — or the queue waits for a check that will never report.

• Merge queue required on main — failures leave the line, get fixed, and rejoin at the back. No queue-jumping as a lifestyle.

• A named human owns the door — queue watched, review roster set, agent count capped at what review can absorb.

The whole post on one card — desks, queue, and the review budget.

The takeaway

Parallel is a property of your desks. Serial is a property of your door. The tooling has fully solved the desks — a worktree per agent, a branch per desk, isolation the tool itself enforces. The door is yours to design: one queue, testing every change against the future it is joining, and a review budget you respect like money, because it is.

Ten agents writing code was never the hard part. It just looked like it, back when writing was the slow bit. Plan the door first — then hire the writers.

© 2026 Honey Kiran. All rights reserved.

Honey Kiran · DevOps & Platform Engineering

I write about SRE, Kubernetes, Terraform, and platform engineering — the defaults that bite, the incidents that teach, and the guardrails that hold.

How many agents are you running — and who holds the door into main at your place? Tell me in the comments.

Examples are illustrative — validate in your own environment before running in production.

Disclaimer

• This post describes my personal experience with my own systems and accounts, in my own words. It is a first-person account of what I observed and what I do in my own work — not a statement of any company’s intentions, policies, or internal decisions. Where I do not know something, the post says so.

• I am not affiliated with, endorsed by, or speaking for any company, product, or vendor named in this post. All product and company names are trademarks of their respective owners and are mentioned only to describe the experience accurately.

• Any error messages, documentation excerpts, or figures quoted here are reproduced from my own records or from the public sources linked in the post, believed accurate at the time of writing. Product behavior changes over time; verify against current official documentation before relying on any detail.

• Nothing in this post is professional, financial, legal, or security advice for your specific situation. Examples are illustrative — validate in your own environment before running anything in production.

• Corrections are welcome. If any company named here publishes an official statement, or if any detail is wrong, I will update this post and note the correction. The goal is an accurate public record, not a verdict.