Two Ways to Fan Out Five Coding Agents — One Wastes Four of Them, the Other Conflicts at 41.7%

Redundant and divisive fan-outHover to explore

A tool category arrived this year without anyone naming it very loudly, and the interesting thing about it is not what it does well. It is what it quietly leaves to you.

This article works from Orca, the MIT-licensed parallel-agent environment from Stably AI, and ArshTechPro's explainer published 20 September 2026; the AgenticFlict dataset by Daniel Ogenrwot and John Businge; Xu, Subramanian and Karthik's study of concurrent agent pull requests; and Daniel Vaughan's analysis of that study. Section 8 says which numbers I trust and how far. The fan-out distinction, the seam argument and every recommendation are mine.

1. What actually shipped

The agent development environment — ADE, and yes, we are one letter from IDE on purpose — is a desktop application that does not contain a model. It contains a fleet.

Orca is the one that broke out. It is MIT-licensed, ships on macOS, Windows and Linux with a mobile companion, and its own pitch is blunt: "Run Codex, ClaudeCode, OpenCode or Pi side-by-side — each in its own worktree, tracked in one place." It supports something like thirty named CLI agents and, in practice, any of them. When I checked the repository on 22 September it sat at roughly 75,000 stars; reviews written over the summer quote figures nearer 60,000, so the curve is steep enough that whatever number you read is already wrong.

The mechanism is a git primitive that has been sitting there since 2015 and suddenly has a killer application:

This is good engineering and it solves a genuine irritation. If you have ever wanted to start a second task while an agent grinds through the first, you know exactly which problem is being solved here.

2. The distinction the interface hides

Here is the thing that made me want to write this. The tool offers one gesture — fan this out across five agents — and that single gesture covers two completely different operations.

Redundant fan-out is the demo. One prompt, five agents, five worktrees, five attempts at the same task. You read the five diffs, keep the best one, and delete four branches. Orca's own copy describes it: fan one prompt across five agents, compare the results, merge the winner.

Divisive fan-out is what you graduate to. Five different tasks, five worktrees, five agents, and at the end you want all five. Nothing is discarded, because discarding was never the point — the point was to do five things in the time of one.

They look the same in the interface. They are opposites.

Redundant fan-out is a lottery ticket, honestly priced. You spend five times to get one result, and you know going in that four fifths of the spend is thrown away. The reviewer quoted in the coverage puts it plainly: running Claude Code three times in parallel uses three times your quota. There is no hidden cost because the waste is the visible part.

Divisive fan-out is where the hidden cost lives. It looks thriftier — nothing discarded! — and that is exactly why people migrate to it, usually within a week of installing the thing.

3. What happens when five branches try to land

Three pieces of 2026 empirical work bear on this, and read together they tell a coherent story.

How common is concurrent agent work already?

Xu, Subramanian and Karthik went through 33,596 agent-authored pull requests across 2,807 repositories. With exact temporal overlap, 79.4% of agent PRs were co-active with another agent PR, in 40.2% of repositories. Widen the window to a week and it is 95% of PRs across 53.4% of repositories.

Divisive fan-out is not a frontier practice somebody might try. It is the default condition of any repository with agents in it.

How often does that output collide?

The AgenticFlict dataset from Daniel Ogenrwot and John Businge is the broad one: over 142,000 agent pull requests from more than 59,000 repositories, of which 107,000+ were replayed through deterministic merge simulation. The result: 27.67% — over 29,000 PRs — produced textual merge conflicts, spanning more than 336,000 distinct conflict regions.

The comparison that gives it teeth: prior studies of human-authored pull requests generally land in the 10–20% range. Agent contributions are conflicting at something like one and a half to two and a half times the human rate.

Does it matter which agents?

This is the finding that reframes the product. Xu and colleagues ran merge simulations on 747 PR pairs and split them:

• Same agent, different branches — 19.8% textual conflict rate (95% CI 16.8–23.2%)
• Different agents — 41.7% (95% CI 33.1–50.9%)

Worth noting honestly: in the wild, cross-agent overlap is still rare — only 0.5% of co-active pairs involved different agents, in 122 of 2,807 repositories. The 41.7% figure is what happens if you do it, measured on a small sample. The ADE's entire value proposition is making the rare thing easy.

4. Git's conflict classes are organisational failures wearing technical names

Break down what those conflicts actually are and the picture stops being about version control. From Vaughan's analysis of the study, the conflicting pairs split three ways:

Only the first is a merge problem. The other two — roughly 42% combined — are structural, cannot be resolved mechanically, and are not really conflicts between branches at all. They are conflicts between two plans, discovered at the worst possible moment, after both plans have been fully implemented.

An add/add conflict is especially telling. Two agents independently concluded a file needed to exist, invented it, and neither knew about the other. No amount of merge tooling fixes that. The fix is upstream, in what you told them.

And note where these conflicts land: 84.4% of conflicted files were source code, not lock files or dependency manifests. This is not the tedious-but-mechanical conflict you resolve by taking theirs. It is the kind where you have to understand both sides.

5. Every number above is a floor

This is the part I would underline if I could only keep one paragraph.

All of these rates are textual conflicts only. The authors say so directly: the figures are a conservative lower bound that excludes build failures and semantic conflicts. Which means they measure the cases where git stopped and told you.

The dangerous case is the other one.

Worktrees isolate at the filesystem level. They do not coordinate at the semantic level, and two branches can touch entirely disjoint files and still contradict each other — through route tables, barrel exports, shared type definitions, configuration, database schemas, or a plain assumption about how something behaves.

So the honest reading of 27.67% is: that is the share where the problem announced itself. Nobody has measured the share where it did not, and it is not zero.

6. The unit of parallelism is the seam, not the task

Here is the reframe I would actually build on, and it is not about tooling at all.

Every ADE invites you to answer the question how many agents should I run? with a number drawn from your budget or your machine. Five feels right. Five is what the marketing shows. But the real constraint has nothing to do with quota:

A seam is a module with a stable interface, a service behind an API contract, a migration that only adds, a component nobody else imports. If your codebase has four genuine seams, four agents is the ceiling. Running eight means four of them are writing against assumptions the other four are concurrently changing, and you will discover which ones at merge time, at the rates above.

This explains something that otherwise looks like a paradox: teams with well-factored codebases report parallel agents working beautifully, and teams with a tangled one report chaos, and both are running identical software. The tool is not the variable. The seam count is.

It also gives the honest answer to should we adopt this? If you have three seams, buying a fleet manager for twelve agents is buying capacity you cannot use. The work that unlocks parallelism is the same boring modularity work it always was — which is an unsatisfying conclusion, and I think a true one.

7. What I would do this week

Five things, in order, none of which require you to stop using any tool you like.

1. Measure your own collision rate before scaling the fan-out.

   You do not need a study; you need git merge-tree. Take the branches your agents produced over the last month, replay every pair against their merge base, and count how many conflict. That number is yours — it reflects your codebase's seam structure, not the industry's average. If it is well under 19.8%, your partitioning is better than typical and you can push the fan-out wider. If it is over 40%, adding agents is adding rework.

2. Run the conflict check during the work, not after it.

   A merge simulation is cheap enough to run on a hook every time an agent writes a file. Two agents heading for the same lines is information that is worth a great deal at minute three and almost nothing at hour two, once both have built on top of the collision.

3. Partition by file set, explicitly, and write it down.

   Before a fan-out, name which paths each task may touch — and treat an agent reaching outside its set as a signal that the task was scoped wrong, not as a thing to wave through. AGENTS.md is the right place for the boundaries that hold across tasks; see what the top repositories actually put in theirs.

4. Merge sequentially, and re-run rather than resolve.

   Land one branch, rebase the next onto the new base, and when it conflicts, hand the agent the rebased base and let it redo the change rather than hand-resolving a conflict between two things you did not write. The agent resolving its own work against current reality is a better outcome than you adjudicating between two plans you were not party to.

5. Prefer one agent across many branches over many agents across many branches.

   19.8% against 41.7% is the single cheapest decision in this whole article. Keep the multi-agent comparison for redundant fan-out, where you are picking a winner and discarding the rest — there, divergent style is the entire point and costs you nothing, because only one branch ever lands.

The rule of thumb underneath all five:

Use many agents when you will keep one result, and one agent when you will keep many results. The ADE makes both a single click, which is precisely why the distinction has to live in your head instead.

8. What I would not claim

747 pairs is a small sample, and the cross-agent interval is wide. The 41.7% figure carries a 95% confidence interval of 33.1–50.9%. The direction — cross-agent worse than intra-agent, by a lot — is the finding I would act on. The second decimal place is not.

AgenticFlict's 27.67% is not a prediction for your repository. It is a population rate across 59,000 repositories with wildly different structures, review cultures and agent usage. A well-factored codebase with tight task scoping will sit far below it. It is a reason to measure, not a number to plan with.

The human 10–20% baseline comes from different studies with different methods. Comparing across them is directionally useful and not a controlled experiment. Agent PRs are also typically larger and faster-produced, and some of the gap is surely that rather than anything intrinsic to agents.

I am not claiming the ADE is a bad tool. Worktree isolation is straightforwardly correct and the annotate-and-return-to-agent review loop is the best thing in the category. My argument is about a gap between what it solves and what a founder assumes it solves — not about the quality of what it does.

Star counts are not adoption and are definitely not retention. 75,000 stars in a fast-moving category tells you attention arrived. It tells you nothing about how many of those repositories are still using it in March.

None of this is measured on the semantic conflicts, including by me. I have argued they exist and that the published rates therefore understate the problem. I cannot tell you by how much, and neither can anyone else yet.

The honest summary

Running coding agents in parallel stopped being a hard problem this year. Isolated worktrees, one click, thirty supported agents, MIT-licensed, works on your phone. That part is finished.

Landing what they produce is not finished, is measurably harder than landing human work, and is the half that no ADE claims to solve — because it cannot be solved in the tool. It is downstream of how your code is factored and how precisely your tasks were scoped, both of which were your job before any of this existed.

The pattern is the one that keeps repeating in agentic engineering: the bottleneck does not disappear, it moves, and it moves toward whatever still requires judgment. Generation got parallel. Integration did not, and integration is where the judgment is.

Before you widen the fan-out, count your seams. If the number is smaller than the number of agents you were about to run, you are not buying throughput — you are buying merge conflicts at a documented rate, and paying full price per agent for the privilege.

Sources: Orca on GitHub — the MIT licence, the supported-agent list, the per-worktree isolation model, the fan-one-prompt-across-five-agents description and the star count as of 22 September 2026. ArshTechPro, "Orca Explained", 20 September 2026 — the ADE framing, the worktree-plus-terminal-plus-preview structure, the diff annotation loop and the note that parallel agents multiply consumption. Ogenrwot and Businge, "AgenticFlict" — the 142K pull requests, 59K repositories, 107K merge simulations, 27.67% textual conflict rate, 336K conflict regions, and the 10–20% human baseline from prior work. Xu, Subramanian and Karthik, "AI Agent Pull Requests on GitHub" — the 33,596 PRs across 2,807 repositories, the 79.4% and 95% co-activity figures, the 747-pair merge simulation, the 19.8% and 41.7% rates with their confidence intervals, the 0.5% cross-agent share and the 84.4% source-code figure. Daniel Vaughan, "When Agents Collide", 28 July 2026 — the 57.6% / 26.8% / 15.1% conflict taxonomy and the observation that worktree isolation prevents directory collisions but not merge conflicts. The redundant-versus-divisive fan-out distinction, the mapping of git conflict classes onto partitioning, architecture and specification failures, the seam argument and every recommendation in section 7 are mine. For the bottleneck-moves argument see Anthropic's CI numbers, and for who should be reviewing all this output see hire the reviewer before the coder.

Related Posts

Anthropic's CI Went Up 25x. Watch the Half-LifeSeptember 16, 2026

Hire the Reviewer Before the Coder: Building a Startup Engineering Team When Agents Write the Code (2026)July 31, 2026

The Biggest Repos Wrote 784 Ways to Say 'Don't'. Your AGENTS.md Should TooAugust 22, 2026