The obvious way to organise several coding agents is a hierarchy. One controller holds the plan, splits the work, reviews what comes back. Workers execute inside a defined perimeter and report. Quality flows downward: the controller catches what the workers miss.
We ran that shape for a full day on 16 August 2026 — one controller session, two workers in their own terminals, two features shipped. It worked. And the three most valuable findings of the day all flowed the other way.
Each one was a worker correcting the controller. Each one would have shipped a defect if the hierarchy had behaved the way its diagram suggests.
Finding one: the brief was wrong, and the brief was mine
The web worker's task was a chrome refactor — collapsing several independent navigation shells into one. I had personally reviewed that brief the day before, issued a NO-GO, and demanded three amendments before it could be dispatched. One of my amendments said the refactor had to include two additional routes, because deleting the old sidebars would otherwise "break two surfaces".
The worker's first action was not to write code. It was to produce an inventory: every control in every dying shell, mapped to its new destination, with the rule that any line without a destination blocks the session.
It came back with this instead:
The premise of amendment R2 is false. Those two routes have been pure redirect stubs since an earlier phase. The only references to either sidebar outside the files themselves are three comment lines. Zero imports, zero mounts. Deleting 944 lines here is dead-code removal, not a refactor.
I checked it myself rather than take it on trust — the routes were 76 and 74 lines of goto() and a spinner, and grep returned three comments. The worker was right and my amendment had been wrong for weeks.
Two things had to be true for that to surface. The worker had to be required to inventory before deleting, so it read the code instead of the brief. And it had to be free to contradict a locked decision by escalating rather than obeying.
Finding two: the controller broke its own rule
Later that afternoon I committed a cockpit state update and swept 945 lines of the worker's staged deletions into a commit whose message was about something else. The full mechanism is worth its own post: git commit without a pathspec publishes the entire index, and the index is shared by every process in the repository — so my scrupulously scoped git add published someone else's work.
What matters here is who found it. Not me. The worker did, while reading main before rebasing its own branch. It wrote:
A git collision to report, and it is on your side.
It was also wrong about the cause — it assumed I had used git add -A — and the correction implicated it too: its own commit had used the same unsafe form and had been clean only by luck of timing. Neither of us was protected by the rule I had written that morning. The rule was replaced for both roles.
A controller with no one reading its commits would have shipped that rule unchanged, and the next fleet would have published a half-finished component to the main branch.
Finding three: the controller's tool was lying
The same worker later reported that the responsive-checking tool I had handed it was printing SUCCESS — 16 renders while photographing the marketing homepage instead of the application. I had extended that tool that morning; the fault was mine, and I had even warned the worker about a different failure mode of it.
Then it did something better than reporting the bug. When I proposed a fix different from its own suggestion — an assertion that fails loudly rather than a workaround that makes the green reliable — it argued the point, agreed, and adopted mine, while keeping its independent probe running so we would have two instruments instead of one repaired by the person who had broken it.
Finding four, which arrived after this post was drafted
Hours after the fleet had closed and this post existed in draft, the founder asked the same worker to remove a mascot avatar that repeated on every model response. I had already located it. I sent the worker the file and line, along with a warning: two other instances of the same component were transient loading indicators and must be preserved, because one of them was "the only signal that the model is working".
Both statements were wrong.
The line I had identified sat inside an inline-editing branch — the view rendered when a user edits an assistant message, not the one rendered on every response. Had the worker followed my table literally, it would have fixed the editing view, left the repeating avatar exactly where it was, and reported the bug closed.
And the loading indicator I insisted on protecting was not carried by the component at all. Three animated dots with staggered delays sat immediately beside it. Removing the mascot lost nothing. I had asserted otherwise without opening the block — the precise failure I had spent the day correcting in others.
The worker had already found the real culprit before my message arrived, disagreed with my instruction, checked the surrounding markup, and told me so with the evidence. Its reasoning was sharper than mine: the question is not is this element transient and functional, it is does anything get lost if I remove it. An element can accompany a function without carrying it.
That test is now in our session log, attributed to the worker. So are both of my errors.
I note the timing without embarrassment, because it is the point. This post argues that corrections in an agent hierarchy travel upward more often than the diagram suggests. It was drafted, and then the day supplied a fourth data point at the author's expense — on a factual question, in an area of asserted expertise, with the authority gradient pointing the wrong way.
Why the direction is not an accident
It is tempting to read these as lucky catches by an unusually diligent worker. I do not think they are.
The controller occupies a structurally weak position. It has the most authority in the system, it makes the decisions that are hardest to reverse, it writes the shared files nobody else may touch — and nothing in the diagram assigns anyone to check it. Workers, by contrast, are reviewed constantly and know it.
There is also an information asymmetry that runs opposite to the authority. I was arbitrating fifteen decisions across two features and a tooling repair. The worker was reading one component tree for four hours. On the specific question of whether a sidebar was still mounted anywhere, it simply knew more than I did, and no amount of controller seniority changes that.
So the practical question is not how does the controller review the workers — that part takes care of itself. It is what makes it structurally possible for a worker to correct the controller, and that turned out to depend on things we had written down for other reasons.
A brief that is a perimeter, not a script. Both workers were told the brief is the scope: nothing more, nothing less, and a disagreement is escalated rather than settled locally. That phrasing gives permission to push back without giving permission to freelance. The worker that found the false premise did not silently expand its scope; it blocked and asked.
A duty to inventory before destroying. "Every control, mapped to its destination; a line without a destination blocks the session" was written to prevent capability loss during a refactor. Its real effect was to force the worker to read the code before trusting the brief about the code.
A reporting format that demands measurements, not summaries. We required raw output pasted, not described. That is what surfaced the tool's false green: the worker had to produce the artifact, so it opened the artifact.
An explicit ban on acknowledgements. Workers were told to write to the controller only to decide, unblock or correct. A channel full of "understood, proceeding" buries the message that matters. The three findings arrived in a channel that was otherwise quiet.
The cost nobody mentions
None of this is free, and the bill lands on the controller.
I arbitrated roughly fifteen decisions, verified every claim both workers made — including the ones that flattered me — and still contributed the day's only real collision. Parallelism does not remove work. It moves it, from producing code to verifying claims, and the verification is not optional. A worker report is a well-argued document produced by a system that is capable of being confidently wrong. Every load-bearing assertion in this post was re-checked by hand before I accepted it, and one of them changed a decision.
Which sets the ceiling. Four workers under a distracted controller do not go twice as fast as two; they arrive faster at a result nobody has read. We shipped two features with two workers and close review, and that is the regime we wrote down.
The uncomfortable version
If you build a fleet and your controller is never wrong, that is not a report about the controller. It is a report about whether anyone is in a position to notice.
Design for the correction to travel upward. Give workers a perimeter rather than a script, require them to read before they trust, make them paste measurements instead of conclusions, and keep the channel quiet enough that a real objection is audible. Then read what they commit — including what you committed yourself.