Five Agents Built It on the Wrong Branch

I split the mesh feature into five clean pieces and dispatched five agents to build them on branch m3-mesh. Parser, exporter, cache, UI, tests. Disjoint files, no overlap, a textbook partition. They all came back green. Every one of them did its piece correctly.

Every one of them committed it to master.

Not because they disobeyed. Because m3-mesh did not exist. It never had. I had read "on branch m3-mesh" off a stale header and repeated it in five dispatches, and five agents inherited the same wrong premise and did exactly what I said, which was the wrong thing, five times, in parallel, correctly.

Operating Conditions

The dispatch looked disciplined. Five agents, one feature, partitioned by file so no two would touch the same code. That is rule five, partition before you dispatch, and I had done it. Parser to one, exporter to another, tests to a third. On paper, no collision possible.

What I had not checked was the one thing every agent depends on and none of them owns: which branch the repo was actually on. I supplied that from memory and from a session header that said Current branch: m3-mesh. Both were stale. A /release-qt run earlier had left HEAD on master, and the m3-mesh branch I thought I had created was never created. The header had not caught up, and I did not re-check, because "which branch am I on" felt like a fact, not a variable.

Failure Modes

The stale header. "Current branch" is displayed, cached, remembered. It is not re-read at the moment you act. Mine said m3-mesh. HEAD said master. The display and the pointer had drifted apart, and I dispatched off the display. Five agents, one shared wrong premise, five commits on the wrong branch.

The drifting checkout. Suppose the branch had existed. You still are not safe, because the checked-out branch is a single mutable pointer, and any parallel process can move it. One sibling running git checkout mid-flight and HEAD is somewhere else than it was when you gave the order. The agents commit wherever HEAD points at commit time, which is not necessarily where it pointed at dispatch time. The branch is shared mutable state, same as the HEAD and the index before it. This is the whole series in one sentence again.

Split brain, as a bonus. Twice I have had two agents pick up the same bug, #517, form two different theories, and each commit a complete, internally consistent fix. Both correct. Both incompatible. Neither knew the other existed. I found out at the merge, which is the most expensive place to discover that "partitioned by task" is not the same as "partitioned by file."

Root Cause

The swarm commits wherever HEAD points, and HEAD is not where the header says.

"Which branch am I on" is not a fact you read once and carry. It is shared mutable state, and a dispatch is a bet that it has not changed since you last looked. Every agent trusts that state, none of them verifies it, and all of them inherit whatever it happens to be at the instant they commit. Partitioning by file protects you from two agents editing the same lines. It does nothing about five agents committing correct, disjoint work onto the same wrong branch, because the branch is upstream of the partition. You can divide the work perfectly and still point all of it at the wrong target.

Proposed Fix

Re-check the branch at dispatch time, not from memory. Immediately before you spawn anything, read it from the repo, not from a header:

git branch --show-current

If that does not say what you expect, stop. Do not dispatch off a remembered branch, a header, or a value that was true five minutes ago. The one second this costs is cheaper than five agents building on master.

Give each agent its own worktree and branch. Rule one, again, because it dissolves this failure too. If agent A works in its own checkout on agent-a, "which branch" is not shared and cannot drift out from under it. There is no single pointer for a sibling to move.

Partition by file, and check for shared targets. Disjoint files is the floor, not the ceiling. Before dispatch, ask whether two tasks could resolve to the same branch, the same output, the same commit target. If they can, that is not parallel work. That is one job you have not finished decomposing.

Verify where it landed. After the agents return, look before you trust: the feature should be on its branch and git log --oneline master should be clean. "Done" told you five commits exist. It did not tell you they are where you wanted them.

System Status

Four posts, four mechanisms, one missing thing. A shared HEAD that let an amend land on a stranger's commit. A cleanup that deleted the branch out from under a real commit. And now a branch pointer that drifted while five agents trusted a header. Different failures. The same hole in the middle of the room where a coordinator was supposed to stand.

There is no coordinator in a swarm. It commits where HEAD points. It lands where you tell it. It trusts what you trust, including your stale idea of which branch exists. Nobody in that pool of agents is checking the premise, sequencing the merges, or holding the map of where everything is, because that was never their job. It is yours. Coordination is a job, not a vibe, and running five agents does not fill the chair. It just makes the empty chair more expensive.

That is the diagnosis this series was built to deliver. The next post is the prescription: the actual system I run so the chair is never empty.

Tell me your version. Five agents, one wrong branch, or two fixes for one bug. Where did the premise drift, and when did you find out? The mechanism is the part that transfers.

Further Reading

• A Swarm Is a Distributed System, Not a Team (Part 1): the shared-state model all four mechanisms share.
• The Amend That Landed on Someone Else's Commit (Part 2): a shared HEAD, at the commit.
• It Said Done, and Deleted the Branch (Part 3): a branch ref that vanished under a real commit.
• How I Run Three Agents Without Losing My Mind: the prescription, the whole index card.