Nothing to merge.

The setup

Six agents, one goal: each adds a command to a shared dispatcher, and the finished repo has to pass an integration test that exercises every command. The same model runs every arm; the only thing that changes is how the agents share the code. We compare two architectures, and keeping them separate is the whole point: conflating them is the easiest way to lie with this data.

• One shared file (every agent edits the same dispatch.py): with no coordination, or with git worktrees (a branch per agent, merged at the end).
• No shared file at all (the decomposed architecture): each agent writes its own fragment in parallel, and a deterministic step assembles them. No agent ever touches a file another agent touches.

We also tried an exclusive lock (claim the file, make everyone else wait). We do not chart it, because the result is structural rather than empirical: a lock serializes by construction, so six agents take turns on one file and you pay roughly six times the cost of one. You cannot out-run parallelism by taking turns. "Don't lock" is the easy part. The interesting question is what to do instead.

At a glance

Methodology: Same model (claude-sonnet-4-6) for every row; 6 agents, 3 trials, median wall-clock to a correct integrated result. The decomposed row is a different, easier task (no shared file, ~3.8x fewer tokens), so its time is not a like-for-like merge; the apples-to-apples comparison is the two shared-file rows. Only trials where every agent completed cleanly are counted (rate-limited trials are discarded and retried). merge_conflicts is a git-merge-only counter (n/a otherwise) and is N-1 by construction within worktrees, so it tracks merge order, not severity. Raw data and code: regente-benchmarks.

Time, by architecture

The main result. The chart keeps the two architectures apart on purpose: the left group is the honest, same-task race on one shared file; the right group is the decomposed approach, which is a different and easier job.

No coordination was fastest, and it stayed correct. Capable agents re-read a file right before they edit it, so even six of them writing to one dispatch.py converged with no lost work. The corruption that coordination is supposed to prevent did not happen on this additive task. Worktrees were also correct, but slower, and the gap is almost entirely the integration tax: 77% of the worktrees time was running the merges and having a language model resolve each conflict, not the agents doing the work.

The merge tax grows with the fleet

Why worktrees get worse at scale. Add agents and the worktree merge conflicts climb roughly one per agent. No coordination on the shared tree stays at zero lost work the whole way.

The decomposed architecture: nothing to merge

The real lever. Instead of editing a shared file at all, each agent writes its own new fragment in parallel, and a deterministic step (no language model) assembles them. The pieces are independent, so there is nothing to conflict over, nothing to lock, and nothing to merge. It is fast, but be precise about why: it is a different, easier job, and the agents did measurably less work to do it.

This is the old drop-in / conf.d / plugin-discovery pattern, and the CRDT idea that commutative operations converge without coordination at write time. The lesson is the architecture: design contributions so there is nothing to merge.

The honest boundary

• The decomposed number is a different task. It never edits the shared file, so it measures "no contention because the architecture removed it," not "a faster merge." That is the point, but it is not a like-for-like race against the shared-file arms.
• Decomposition only helps the additive case. New handlers, routes, exports, dependency entries, and config decompose cleanly. Two agents rewriting the same lines of existing logic do not. There you still need a real merge or a lock, and coordination's value is correctness and a clean audit trail, not raw speed.
• The conflict counter measures order, not severity. A git merge only runs in the worktrees arm (others report n/a), and within it the count is N-1 by construction. The load-bearing merge-tax signal is integration time and resolver cost.
• Small study, clean trials. One model, an additive task, six agents, three trials. Concurrent agents on a single account are themselves rate-limited, so we only count trials where every agent completed cleanly.

Update: we built the merge claim, and measured the real engine

Update, June 17, 2026

We shipped the merge claim into Regente's engine and re-ran the benchmark on the REAL engine (the pre-edit hook, the MCP server, real claims), not a script. The task is mixed and realistic: six agents each add a command to one shared dispatch.py (additive), and two of them also add a guard to the SAME shared _validate function (a genuine conflict). Same model every arm, graded by the same tests, three trials run round-robin so every arm shares the same single-account rate-limit conditions.

The merge claim fixed the old lock. Regente's exclusive lock used to be the slowest approach by far, around 474s, because it serialized the whole file. The merge claim lets the fleet add to the shared registry in parallel and orders only the one conflicting function, so the real engine lands a correct, fully integrated result in about 167s, faster than git worktrees (210s), with zero merge-resolution tokens. Git worktrees spent roughly 1 million tokens having a language model resolve the conflicts; Regente runs no resolver because there is nothing to merge. Every command and both _validate guards survived, with no clobbered work and a signed log of who changed what.

The honest part

Two things we will not dress up. First, no coordination still wins outright here. Even on the shared _validate, the free-running agents re-read before writing and produced a correct result, fastest (72s) and cheapest ($1.70) of all. On a shared tree, capable agents self-heal; we could not make them lose work, and we will not engineer a task just so they do. Second, coordination is not free in tokens. Regente's agents spend extra turns claiming and handing off, so its total cost came in highest, around $3.00 a run. The merge claim removes the worktree merge tax, but the coordination protocol has a cost of its own, and on this task that cost was larger than the merge tax it saved.

So the position is unchanged and now measured on the real engine. Regente's value is removing the git-worktree merge tax and giving you an enforced, audited, contention-free way to run a fleet on one tree: faster than worktrees, with no merge-resolution cost, no lost work, and a signed audit trail. It is not a way to out-run free-running agents, because on a shared tree they already self-heal. Coordination earns its keep on safety and governance, and when self-heal fails (truly simultaneous writes, untrusted agents, or isolated checkouts), not as a way to be cheaper than doing nothing.