July 27, 2026
Multi-Agent Orchestration: The Bottleneck Is Never Agent Count — It's Review Capacity
We tightened our own multi-subagent convention after real merge conflicts. What three current sources and our own practice reveal about the limits of parallel AI agents.
More parallel AI agents don't mean more throughput. They just shift the bottleneck from code generation to review — and human review capacity doesn't scale the same way. That's not a marketing platitude; it's a lesson we learned the hard way this May, when two subagents working in parallel in one of our repos edited the same file region independently, committed separately, and produced a semantic conflict at merge time that neither agent could have seen, because neither knew the other existed.
The consequence: a mandatory worktree-isolation convention.
Since May 21, 2026, our repos follow one rule: whenever two or more subagents work in parallel, each one gets its own `git worktree`, an explicit base branch, and disjoint file ownership. The mandatory pattern is simple — `git fetch origin`, then `git worktree add ../repo-{stream-slug} -b claude/session/feat/{stream-slug} origin/master` (or `origin/main`, depending on the repo's convention) for every stream. That parenthetical isn't a footnote: across our own multi-repo landscape, some projects default to `master`, others to `main`. An agent that pulls the wrong base builds on stale state — and nobody notices until the merge fails. Before every PR push, a smoke-test gate (`npm run typecheck && npm run build`) must pass. No agent pushes past a red pipeline.
Independent practitioner reports describe the same mechanism.
A guide published by Augment Code in April 2026 on git worktrees for parallel AI agents describes exactly this pattern: worktrees give each agent a fully isolated filesystem without duplicating the repository — preventing file conflicts, context contamination, and lock contention when multiple agents work in the same repo simultaneously. The guide gives a concrete figure: as of mid-2026, teams reliably run four to eight concurrent worktrees per developer — beyond that, the bottleneck is no longer the agents but the review (Augment Code, "How to Use Git Worktrees for Parallel AI Agent Execution," augmentcode.com, April 7, 2026). Worktree isolation solves a technical problem — file and merge conflicts — but it does not solve the actual bottleneck: task decomposition, dependency tracking, and who ultimately decides which of several parallel proposals gets merged.
Why orchestration hits a human limit, not just a technical one.
In "The Code Agent Orchestra" (March 26, 2026), Addy Osmani describes what separates productive developers from overwhelmed ones: those who coordinate multiple agents successfully do it asynchronously — each agent gets a clearly scoped area of responsibility and reports back when done, rather than the human running in lockstep. Exactly two weeks later, on April 7, 2026, Osmani followed up in "Your parallel Agent limit" with an uncomfortable observation: human cognitive bandwidth doesn't parallelize. The agent generates in parallel, but evaluating, deciding, trusting, and integrating stay single-threaded on the human side. Osmani cites the experience of running four agents at once and being wiped out by 11am — not because the agents were slow, but because every additional parallel thread creates another decision that has to be routed, merged, and verified. Osmani calls this the "orchestration tax": you can supervise more agents than you can deeply understand — but supervision without understanding is exactly where comprehension debt builds up.
What this means for SMEs introducing multi-agent workflows.
The common planning logic treats capacity as a function of agent count: "If we run ten agents in parallel, we get ten times the work done." That's the wrong yardstick. The right question is how much review capacity is available, and how it's distributed across the parallel streams. Three recommendations from our own convention and the sources cited above translate directly:
- Fix disjoint file ownership before starting. Don't hope agents won't collide — assign the split explicitly before the first agent launches.
- An explicit, documented base branch per stream. Especially in multi-repo environments with inconsistent branch conventions (`master` vs. `main`), this isn't a nice-to-have — it's the most common failure source.
- A hard gate before merge. Typecheck and build must pass before an agent's output is even presented for review. That filters out the cases where human review time would be least well spent.
What can't be solved directly is the human limit itself. Anyone planning to scale parallel agents from two to eight should plan in advance who carries the added review load — not discover afterward that no one does.
Are multi-agent systems always the better choice?
No. The sources cited here agree that multi-agent orchestration works where tasks genuinely decompose into independent, parallelizable pieces — separate features, separate file areas, separate test suites. Where tasks depend heavily on each other or touch the same code area, parallelism produces more coordination overhead than it saves. That's why our own convention explicitly ties worktree isolation to the condition "2+ subagents working in parallel" — a single agent doesn't need that overhead.
How many agents should a team run in parallel?
Based on the sources cited here: as many as there are disjoint, independently reviewable work streams — and no more than one person can honestly review in a day. Four to eight concurrent worktrees per developer is the order of magnitude reported in practice as of mid-2026; the limiting factor is almost always review, not infrastructure.
Does orchestration tooling replace code review?
No — none of the three sources cited here claim that. Worktree isolation and base-branch discipline prevent technical conflicts. They don't prevent the need for someone to verify that what an agent built is actually correct. Skipping that step just shifts the risk from "merge conflict, visible immediately" to "wrong behavior in production, visible late" — which is structurally worse.
If you're setting up a multi-agent convention for your own development environment — including review-capacity planning instead of raw agent count — we support that as part of our development engagements: digital-opua.ch/kontakt.
Sources
Addy Osmani: "The Code Agent Orchestra — what makes multi-agent coding work," addyosmani.com, March 26, 2026 — https://addyosmani.com/blog/code-agent-orchestra/ · Addy Osmani: "Your parallel Agent limit," addyosmani.com, April 7, 2026 — https://addyosmani.com/blog/cognitive-parallel-agents/ · Augment Code: "How to Use Git Worktrees for Parallel AI Agent Execution," augmentcode.com, April 7, 2026 — https://www.augmentcode.com/guides/git-worktrees-parallel-ai-agent-execution