Thirty merges and nothing on the screen

On the morning of day four, at 06:45, I opened the preview of the app. Nothing had changed since the afternoon before. Overnight, the agents had merged 30 pull requests, every deploy had run, and CI was green. Three of the merges were features, and none of them added a screen.

By 07:40 the team had a new shape. This chapter is about what went wrong with the org chart from the previous chapter, and what replaced it.

More agents, fewer features

The numbers had been pointing the same way for two days. As the team grew, it merged more pull requests and fewer features.

The five features on day three had all been opened the day before. The four screens the proof of concept needed had been open for more than 30 hours. 51 pull requests of tests were waiting for the one agent allowed to write the code that would make them pass.

What went wrong

I read the data with the Orchestrator before deciding anything. The data pointed at the way I had organised the work, more than at the agents.

An assembly line. A screen passed through five roles. Each role woke up once an hour, so each handoff could cost up to an hour. Each review finding or QA failure sent the screen back down the line. One screen's pull request reached 247 commits and about 150 comments, and it still had not merged.

The team made its own work. QA and design filed real but minor findings, such as contrast problems in Windows high-contrast mode across 21 components. Each finding became an issue, a test, a build and a QA pass.

Guardrails that cost more than they saved. The hook that kept each role in its lane refused ordinary commands, and DevOps spent most of the night fixing it.

Rules that agents did not follow. The evening before, I had added a rule that said "don't stop after one item". Overnight, every role still woke up, did one item, and stopped. A rule in a document did not change how the agents worked.

The tool was only part of the problem

My first reaction was to ask whether another agent tool would do better. Within one session, Claude Code already supports agents that keep working, helpers that run in parallel, and agents that wake up on an event, such as a failed check. The team used none of these at scale. Between sessions the options were thinner. Scheduled routines ran at best once an hour, and separate sessions could not message each other directly. My design leaned on exactly that weak part.

A team topology problem

Looking back, the failure has a name. In 1968, Melvin Conway observed that organisations design systems that copy their own communication structure. The book Team Topologies, by Matthew Skelton and Manuel Pais, builds on that idea. It shapes teams around the flow of work through the product, so that each team owns a slice of it from end to end.

I did the opposite. The product lives in one repository and grows in vertical slices, where a screen comes with its data and its logic. The team was split by step instead: spec, design, tests, build and QA. The organisation, the product and the architecture pointed in different directions, and every screen had to cross all of them.

The root cause is that I treated the agents as people, and built an organisation designed for people. In Give the agent superhuman work, I argued that agents should get work that no human would take on. The same applies to how they are organised. Agents that work at a superhuman pace need their own model, and finding it is a large part of this journey. In Team Topologies terms, the owners below are stream-aligned teams, each one following one stream of work, and DevOps works much like a platform team.

Conway's law is about communication, and communication is where agents are weakest today. Most tools help agents talk to people, or help people read what agents write. Few give agents a channel to talk to each other. My agents talked the human way, with updates in Linear and comments on GitHub, read by roles that woke up once an hour. Asynchronous work is fine when there is also a way to synchronise, and here there was none.

The owners model fits that limit. Each owner holds a whole slice, so most of the coordination happens inside one agent's context, and only the platform and QA cross between slices. It is a workaround for today's tools, and I don't expect it to last. Protocols for agents to talk to each other exist, such as A2A, now run by the Linux Foundation. They connect agents across products more than they help one team of agents work on the same code. A product built for that, with events, shared state and points where agents synchronise, is a gap I expect someone to fill soon. I wrote more about it in a reflection, Agents need their own way to talk.

The reset: owners instead of steps

At 07:00 I wrote down the priority: "We're at a very early stage where we need a workable POC, not a prod app." Getting things done came first. By 07:40, the team had moved from steps to owners.

The slices follow the product: the customers' side, the side of the suppliers being assessed, and the platform underneath. Design polish waits until the proof of concept works.

The change itself was messy. The Orchestrator and DevOps both edited the plan by message, their messages crossed twice, and the team model changed three times in 30 minutes. One writer per decision would have avoided that.

The first hour after

At 09:00 I typed a prompt into each session: keep going between check-ins, run helpers in parallel, and rewrite your own routines. Within the hour, all four screen pull requests had new commits, nine pull requests had merged, and QA had started an end-to-end test of the whole flow.

A typed prompt did in one hour what the written rule had not done in a night. One hour is not a result, and the next entries in the log will show whether the new shape holds.

What I learned

1. Measure what a person can see. Merged pull requests hid that nothing shipped. A screen that works in the app is harder to fake.
2. Start with owners, not a pipeline. A role per step multiplies handoffs, and each handoff waits for the next wake-up.
3. Add agents only when the work splits cleanly. A split by step did not. A split by slice of the product does.
4. Steer with checks, and leave room. Agents followed what I typed and what failed in CI, and drifted from what sat in a document. Deterministic checks are the way to steer them, but the role guard showed that too many checks block the work.
5. Keep agents on the product. A guardrail that keeps the team fixing its own tooling costs more than it protects.

The balance in the last lesson is the hardest part. Rules and checks give control, and the value of an agent comes from what it decides on its own. With too few checks the agents drift, and with too many they spend the night fighting their guardrails. I suspect the product that finds this balance, whether it calls itself a harness or a software factory, could become the best in its class and the next big step in this field. More in the reflection The sweet spot between rules and freedom.

What others found

Lauren Tan, an engineer at Cursor, publishes the agent skills she uses every day aspstack. Its guide and principles reach most of the same lessons, often in sharper words.

The last row corrects my own conclusion. Separation of duties is still useful, at the point where a change is judged. My mistake was to spread it across every step of the building.

We differ on one point. Her guide says that "five narrow PRs beat one fat one", and my reset merges a screen in one pull request, whatever its size. For a proof of concept I chose speed, and I expect to move closer to her rule later. She also works with far more tokens and compute than a one-person project, so I take ideas from her setup without copying it.

The bottom line

Separation of duties works for people, because each check catches the others' mistakes. Spread across every step, with agents that wake up once an hour, it turned each handoff into a wait, and the waits added up to a night with nothing to show.

The fix was to give each agent a whole piece of the product and to count what I could see. It is my best answer for now. This field moves fast enough that a best practice can be out of date within a week, so I expect to change the model again.

Thirty merges and nothing on the screen was an early and cheap way to learn how not to organise agents.

Further reading

• Melvin Conway, How do committees invent? (1968)
• Matthew Skelton and Manuel Pais, Team Topologies
• Lauren Tan, pstack
• Give the agent superhuman work