Shipping is merging

The usual belief about parallel work is that it helps only when a task decomposes into independent pieces, so the way to use many agents is to find work that splits cleanly and give each agent a piece. We build tools for directing many agents at once, we run our own projects on those tools, and running them corrected the belief. Almost any work can be split, because splitting is copying: git hands every contributor a complete copy of a codebase that cannot be edited in parallel in place, and the contributions come back as merges. What decides whether parallel work counts is at the other end. A merge is the step that folds one branch of work back into the trunk, meaning the single current version of the thing being built, and the question that predicts whether a group of parallel agents will accomplish anything is whether a merge path exists from each branch back to the trunk, not whether the task looked parallelizable at the start.

The two halves of this arrangement are now priced very differently. Opening a branch costs a model call: every prompt starts a new line of work, an agent will carry the line as far as its tools allow, and the number of open branches is limited only by willingness to pay for compute. Merging did not get cheaper, because a merge was never made of labor. To merge a branch someone has to read it, judge which part of it is worth keeping, and fold that part into the trunk without breaking what is already there, and each of those is judgment exercised in sequence. When one half of an operation becomes cheap and the other half stays expensive, the queue forms in front of the expensive half. Anyone who runs agents has seen the symptom: branches, drafts, and near-finished artifacts accumulate, and the thing being built does not move.

Dozens of branches of one deliverable

One of the businesses we run has a render pipeline that produces a crafted deliverable, and at one point we pointed agents at it in parallel. The agents generated dozens of branches of the same deliverable, each branch a complete working copy that explored a different layout, a different animation, a different structural idea. Every branch contained something worth keeping, and no branch was complete. For a while the pile of branches felt like progress, because the pile kept growing. By the only measure that mattered it was standing still, because nothing had been merged, and the deliverable itself was unchanged.

The work got done when the merging began. A single reviewer went through the branches in sequence, took from each the piece that survived judgment, composed the kept pieces into one deliverable, and discarded the rest knowingly. The parallel phase produced the raw material in hours. The finished deliverable came out of the merge, and only out of the merge.

Amdahl’s law

That merge ran in sequence, and it had to, because each merge changes the trunk that the next branch lands on. It was also where taste entered the system: reading each branch, deciding what was worth keeping, composing the kept pieces into something coherent. Amdahl’s law, from parallel computing, says that the speedup available from adding processors is bounded by the fraction of the work that has to run in sequence, and in agent work the fraction that has to run in sequence is the merge.

The bound is easy to work out with real values. Suppose a deliverable takes ten hours of drafting and one hour of merging. One agent takes eleven hours. Ten agents draft in parallel in one hour, and the merge still takes one hour, so the total is two hours. A hundred agents draft in six minutes, and the merge still takes one hour, so the total is sixty-six minutes. The ceiling is a speedup of eleven times, and no number of additional agents raises it, because the merge hour does not shrink when agents are added.

Every gain past that ceiling has to come from the serial side, and the serial side offers two levers:

• The merge can be made faster. Written rules and automated checks can judge a branch before a person sees it, so the person’s hour is spent only on what the checks cannot decide.
• The branches can be made more mergeable. An acceptance condition declared before the branches open tells every agent what the trunk will admit, so fewer branches come back unmergeable.

What the serial step cannot be is removed. One trunk means one ordered sequence of admissions into it, and the admission decision is where the owner’s judgment lives, so handing the whole decision to another agent does not speed the system up; it gives away the property that made the trunk worth converging on. Large engineering organizations already measure at the join: Anthropic, among others, counts progress in merged pull requests rather than opened ones.

What a merge admits

A merge is an acceptance decision, and an acceptance decision needs an acceptance condition, meaning a statement of what must be true for a branch to enter the trunk. Merging without one still lowers the branch count, but the trunk it produces is drifting rather than converging, because each admission moves it and nothing decides the direction. The condition cannot be produced by more thinking. The information that separates a good condition from a plausible one lives outside the system, in what failed, what got a reply, what the world pushed back on, which is the same reason a search loop needs a judge outside itself. The order is therefore fixed: contact with the world first, then the condition, then the convergence.

There are also two different ways a branch count falls, and from the outside they look identical. In the first, branches are simply closed: the work inside them is discarded, the trunk receives nothing, and the person has practiced abandoning. In the second, each branch is visited, the part that survives judgment is carried into the trunk, and the rest is discarded knowingly. At agent scale the difference is most of the value, because agent-produced branches are usually partially good: a branch that fails as a whole still contains a section, a structure, or a decision that won. An acceptance rule that admits or rejects whole branches therefore throws away most of what the parallel phase paid for. A convergence is measured by what the trunk gained, and a falling branch count over an unchanged trunk means the branches were abandoned rather than harvested.

The merge queue

Convergence also has to be funded, because generation fills whatever room it is given. A loop that can afford one more draft will produce one more draft, since generating is the cheap operation and selecting is the expensive one, and a search that keeps widening after it has stopped resolving anything is paying to postpone the selection. The device that stops it is a resource limit: a deadline, a token budget, a spend cap. A blockchain calls the same device a gas limit, a budget that halts a computation when it is spent, and the useful refinement for agent work is to reserve the last share of the budget for the merge, because a plan that spends its whole budget opening branches has arranged, structurally, never to collapse them.

The artifact for managing the work changes with the prices. A task list controls what gets started, and it was the right control artifact when starting work was the expensive act. A merge queue controls what is admitted to the trunk, in what order, against what acceptance condition, and nothing leaves it except by entering the trunk or being discarded knowingly. The popular multi-agent frameworks are built for the other end: their design surface goes to coordination, to which agent acts next and how agents talk to each other, and a first-class concept of merging results back into one thing is mostly absent, which matches how most agent work is still run.

A queue also makes the liability visible. An unmerged branch charges interest: the trunk moves underneath it while it waits, so the cost of integrating it grows with its age. We call the accumulated liability merge debt, and the number we watch is the age of the oldest unmerged branch. The same accounting answers the scaling question people actually ask, which is how many agents a single operator can direct. The number is not set by attention during the parallel phase, because directing that phase costs little. It is set by the operator’s merge throughput, and every branch opened beyond that throughput is debt on the day it is opened.

An agent system can run searches that are wide, patient, and nearly free, and what the searches return is raw material. The system that turns the material into a built thing is engineered around the join: an acceptance condition declared before the branches open, a budget whose last share is reserved for the merge, and a queue out of which the only exits are the trunk and the knowing discard.

Everything upstream of that queue runs at the speed of the agents, and the system as a whole runs at the speed of the merge.