Day 1 of 10
Day 1 of 10. There is a lot written about what AI agents can build. There is almost nothing written about how you wire several of them together without them destroying each other's work.
Originally published on LinkedIn — read the original.
I run gooolll.com, a live football data platform. Forty-six competitions, 114,000 matches, records back to 1930, scores syncing within a minute of a goal. It was built in eleven weeks by a crew of seven AI agents and one person who has a full-time job.
This series is the wiring. Not the demo.
The important thing about that split is what it is not split on.
It is not split by skill. A is perfectly capable of writing front-end code. A does not write front-end code - because the agent that authors a change should never be the agent that declares it safe.
The lanes are drawn around what an action can break. Not around what an agent happens to be good at.
The roster grew as failures appeared.
Q exists because closures were being reported that had not been verified. F exists because security work kept getting done by whoever happened to notice it needed doing. Neither was in a plan.
That is a less impressive origin story than "I architected a seven-agent system," and it is the true one. Every lane in that list is a scar.
Your instruction goes to C, which measures it and never assumes. C dispatches to the lane owner with the facts attached. The agent authors the change but does not apply it. Q gates it independently and returns one of three verdicts: PASS, FAIL, or UNPROVABLE NOW. Then I run the SQL by hand, the lane owner deploys the code, and C re-verifies on production.
Three things hold that together, and each gets its own article this week.
Everything routes through the coordinator. Agents never hand work to each other directly. That looks like pure overhead until the night two agents built the same fix in parallel and one commit went in the bin. (Article 2.)
Nothing an agent writes goes live on its own. Database changes are authored as migrations and executed by me, by hand. Code is deployed by the lane owner, never by the coordinator, because the agent that asked for a change should not be the one shipping it. (Article 3.)
Verification is independent and has three verdicts. Q checks by a different method than the builder used, and may answer "unprovable now." "Probably fine" is not available. (Article 4.)
I execute every SQL statement. I approve every scope change, every cost, everything that alters what users see or what the product promises. Nothing that touches the database moves without me.
I am not apologising for that. Seven agents can carry an enormous amount of build, review and distribution. What they cannot yet carry is the decision about which risk is acceptable - and a system that is fast, confident and blind to its own boundaries should not also hold the deploy key.
Over the next nine days I am going to describe the failures, not the features.
Because the interesting finding from eleven weeks of this is not that agents can build a website. It is that when they get it wrong, they are almost never lying.
Across seventeen documented errors in a single session, not one was a fabrication. Every one was a true measurement of the wrong thing.
That turns out not to be an agent problem at all. It is the same failure that took gooolll.com blank for a day, the same failure that made my content pipeline invent transfer fees, and the same failure that had me misreading my own signup numbers for six weeks.
We start tomorrow with the night that two agents wrote the same fix.
Day 2: Why a hub and not a mesh.