Four Minds, One Repo, Part 2: The Inheritance

The first four agents built a voting machine.

The next four inherited it.

Eight minutes into their run, it refused to count their first election.

By the end of the afternoon the machinery had rejected a second election as invalid, failed an integrity audit, and needed three repairs, one of which quietly broke something else. In between, the same four agents chose, built, tested and shipped an unrelated product in under fifty minutes.

By the time the third team arrived, the voting machine was gone. An agent had retired it, and I hadn’t asked it to.

This is the second chapter of Four Minds, One Repo. The first asked whether four autonomous coding agents could organise themselves well enough to deliver anything. This one asks what happens when a new team inherits the tools the last team left behind.

The voting machine meets its successors

In run 1 the agents built Tally, a small Python library for counting ranked ballots. For run 2 I gave it back to them as their constitution. Every major decision (what to build, which stack, when to stop) went through a slate, four committed ballots and a Borda count run by Tally. No hand-counted results allowed.

The four seats were Claude Code on Opus, Codex on GPT Sol, and two OpenCode sessions running DeepSeek and GLM. Same rules as before: 120 minutes, no product owner, no human answering product questions.

The first count failed on three invisible bytes. Codex had written its ballot from PowerShell, which put a UTF-8 byte-order mark at the front of the file, and the adapter refused to read it. GLM, acting as scribe, fixed the reader rather than the ballot. Changing the ballot would have meant a second commit, and the rules said one commit per ballot.

A close election

There were four proposals: a Git history replayed as a timelapse, a “weather forecast” for a repository, a departure planner for chaotic mornings, and Lantern, a tool that turns a folder of Markdown notes into one offline HTML file you can email to someone.

Lantern won 9 to 8 over Repo Weather. First preferences split two and two. Claude and GLM wanted the weather report; Codex and DeepSeek wanted Lantern.

Lantern is a Markdown-to-HTML knowledge garden: competently built, thoroughly tested, and about as revolutionary as that description sounds. The team knew it. Claude’s criticism named the existing tools that already do this, and DeepSeek’s response conceded the point and narrowed the pitch.

The more interesting question is why the safe option won. Borda rewards the candidate nobody ranks last. Lantern was nobody’s last choice: it was easy to explain, easy to demonstrate and hard to fail. Repo Weather was stranger and riskier. A ranked vote among four careful agents, told to weigh feasibility, chose the project least likely to embarrass anyone. I suspect human committees would recognise that.

Four agents, four lanes

This is the part I was hoping to see, and it is easy to miss.

In run 1 the agents stepped on each other. Overlapping work in the shared tree broke the command-line entry point, two golden tests failed until one agent restored it, and another agent threw its own work away.

In run 2, DeepSeek wrote an interface contract with four lanes before anyone touched product code: parser and link graph for GLM, rendering and the command line for Claude, the Markdown renderer for itself, the browser viewer for Codex. It revised the contract 56 seconds later. Nobody started coding until all four had acknowledged the same version, about sixteen minutes in.

Then the lanes started reviewing each other. Claude found that a crafted link could inject a script into the generated page. DeepSeek fixed it, and the independent observer confirmed the fix about eighty seconds after confirming the bug. Codex found three more defects in other people’s lanes. When GLM tried to edit a file DeepSeek was holding, the coordination tooling refused the edit. GLM worked on its own tests while DeepSeek finished.

That is not four agents writing Python faster. It is four agents behaving like a team.

The bureaucracy fights back

Meanwhile, the voting machine kept demanding attention.

The second election, on the technology stack, was rejected outright. GLM, as scribe, set the ballot deadline almost nineteen minutes out. The rules capped it at five, and GLM had read elapsed time from the board’s relative timestamps. All four ballots were already cast. Slates are immutable and ballots get one commit each, so the election could not be repaired, only abandoned and re-run. The four uncounted ballots are preserved in a folder called abandoned.

The final audit failed next. Codex’s ballots had Windows line endings on disk and Unix line endings in Git. The recorded fingerprints matched the files on one machine and nowhere else, so a clean checkout could not reproduce the result.

DeepSeek repaired that, and the repair made the tool’s own integrity check blind to the same kind of change. Codex caught it. The observer proved it by deliberately altering a protected file and watching the check pass anyway. DeepSeek repaired the repair. The vote results never changed through any of this.

They built themselves a bureaucracy. Then they found out how much work a bureaucracy takes to maintain. They shipped anyway.

Fifty minutes, seventy left

At 48 minutes the team voted, four to nothing, that Lantern was complete. The Python and JavaScript tests passed from a clean checkout (the browser tests were skipped there), the decisions audited, the documentation was honest about every limitation. Then everyone stopped, with seventy minutes still on the clock.

The commit log shows the bureaucracy’s footprint. Of 94 commits, 37 were about slates, ballots, endorsements and final statements. Sixteen touched product code or tests. That ratio is not a measure of wasted effort, since one feature commit can be worth twenty bookkeeping ones. But it shows how much of the shared record went to administering the democracy.

So was the governance expensive, or just verbose? It finished early either way. What it did not do was push anyone to use the spare hour on something better than a safe product.

What the next four inherit

Run 3 is already running, and run 4 is being prepared. There’s now an independent observer auditing the run and another AI agent live-blogging it from outside the participants’ board. Apparently my solo software factory has acquired a press department.

Run 3 inherits different machinery.

I chose the new decision rule: one proposal, written together, that all four must endorse before any code is written. There is no vote to fall back on. Claude, preparing the run, decided on its own that Tally no longer fit a rule with nothing to rank, and built a small consent checker instead. I had not asked it to replace Tally. It also had not seriously evaluated whether Tally could be adapted. The mission changed as well: the team must find a specific customer who might plausibly pay, and show how its product differs from the closest alternatives.

Some of run 2’s lessons became tools rather than instructions. A Git hook now refuses the kind of commit that swept up another agent’s staged files twice in run 2, once after written guidance said not to. The consent checker tolerates byte-order marks and line endings by design.

The first four agents built a voting machine. The next four used it, broke it, repaired it and exposed its limitations. The third four are already working with different machinery, including a replacement that an agent decided to build without being asked.

Notes on the evidence. Times and counts come from the run’s Git history and the independent observer’s executed checks. Minute estimates from the agents’ own debriefs are their estimates. The observer’s continuous watch started about fourteen minutes after the clock, so the earliest events rest on committed records. Run 1 and run 2 differ in more than the voting tool (the Claude model, the decision phase length and the product criterion changed too), so the coordination improvement cannot be credited to any single change.