The Orchestrator Is the Weakest Link

The workers were fine. It was the foreman who kept handing out the wrong blueprints.
- Every construction site, eventually

Two weeks ago I described how I run a fleet, and last week whether it shrank my ticket queue. One main Claude Code session plans, briefs and verifies. Parallel stream sessions each own a ticket end to end in their own worktree. Subagents do the work and never touch git. Review and blast-radius gates stand between every change and a merge. Only three things stop for me.

That post described the design. This one covers what happened when I measured it.

On the one run I measured end to end, the weakest part of the system wasn't a stream. It was the orchestrator: the session that plans and briefs everyone else, the one standing in for me.

Every False Premise Came From the Top

On the first run of the written process, four false premises reached the streams. Every one came from the orchestrator. Every one was caught by a stream. None was caught by the orchestrator itself.

They are worth listing because each one failed in a different way:

An absence claim with no probe. The brief said a repair needed an endpoint that didn't exist. It did exist. It had shipped weeks earlier. That claim reached a decision I made.
A correct measurement with a wrong conclusion. The brief said three jobs needed a timeout setting. Two did. On the third, the setting was invalid, and the orchestrator's own probe output showed why. It read past the column it wasn't looking at.
A stale relayed premise. The brief said a PR had merged with a review gap. A stream refuted that in minutes. Another stream's notes had already refuted it hours before the orchestrator assigned the work.
Intent recorded as fact. I asked whether it was clear to start one more stream. The orchestrator said yes, then wrote that stream down as running. It had never been launched.

None of these is "the model is bad at code." Each one is an unverified sentence written with confidence into a brief that another agent then trusted.

The lessons are specific, and none of them is "be more careful":

An absence claim needs the same proof as a presence claim. "It doesn't exist" is the easiest claim to write and the one nobody checks. One search against the main branch would have caught the worst of these.
Read your own output for the column you weren't looking at. The answer was in a probe the orchestrator ran.
Write premises into briefs as instructions to verify. Not "the gap is real," but "confirm the gap is real before spending a review panel on it." One brief already said that, and that sentence is why no work was wasted on it.

Streams catching the orchestrator is the system working. The fix is not to stop passing premises down. It's to label them as premises.

The Instruments Lied Quietly

The sharpest failure on that run wasn't a claim at all. It was a tool.

The orchestrator watched the streams' status files with a script that looped over a hardcoded list. A stream added mid-sprint was never on the list, so the watcher was blind to it for its whole run. The orchestrator saw no changes and concluded the stream had gone silent for three hours. In that window the stream had written seven entries, covering two review rounds, two re-reviews and a CI diagnosis.

The orchestrator was one answer away from rebasing and merging that stream's branches out from under it. It asked me first, and that question was the only thing that stopped it.

"No change in the watched files" and "not watching that file" produce the same output. That's a null result with no positive control, which is exactly the failure I warned about in the post on agents being wrong a third of the time. This time my own tooling committed it against my own fleet. The fix is small: find the files instead of listing them, and print how many you're watching so the count checks the search.

It wasn't the first time. An earlier session this summer failed the same way, in tooling and coordination rather than code:

A merge detector silently reported "none" for five cycles.
An escalation counter counted its own posts.
A commit landed on another session's branch.

No PR review would ever catch any of these. There's no diff to review. That's why the orchestrator posts me an end-of-day digest of what merged and what it decided without me. It's where coordination failures show up.

A Rule You Don't Put in the Prompt Doesn't Exist

The third group of failures came from what the briefs left out.

Files, but not databases. A review agent's prompt said not to modify any files. It never mentioned databases. The agent dropped a schema in a shared test database, and about 274 objects went with it. "Do not modify any file" read as total to me and as file-scoped to the agent. Verification agents reach for a real database because that's how you actually verify SQL.
Git, from the wrong seat. A code-review agent doing its own before-and-after check ran git restore and destroyed a sibling's uncommitted work in the same tree. The rule now: commit before launching anything that can touch git.
The ticket ratio. The orchestrator wrote six prompts for parallel sessions over two days, and none carried my rule to close more tickets than you open. The three that ran closed 19 and filed 26. As I put it in a reminder to every session: "Close 2, open 3 is NOT a win." The sessions weren't the problem. The prompts were.
The model budget. Weeks later, the same shape again. I'd decided lower-reasoning work should go to a cheaper model. Seven live stream prompts didn't say so.

Some of these rules were already in my config. Others I wrote after the failure. Either way, the fleet didn't have them, because they weren't in the prompt.

That's the rule behind most of the fixes: a rule you hold but don't put in the prompt is a rule the fleet doesn't have. A convention added after the prompt goes out doesn't exist either, unless someone puts it in front of the stream.

The Honest Scorecard

Here are the numbers, as they came out.

The day the process was written down, five streams closed 12 tickets. They also deferred 19 findings, and one of those leaked: a real defect held only in a code comment and a status file, on a ticket that closed with nothing left to track it.

That afternoon, four streams ran the new written process for the first time. They closed two tickets and filed three. Two of those filings were my call, but the ratio is the ratio. Net: plus one. The process records that as a failure, because it is one.

The longer view was worse. As I wrote last week, the fleet was filing about 0.9 tickets for every PR it merged, and the queue was growing.

The code held up. Across those four streams, seven review rounds and two blast-radius passes, the code was clean every time. Every finding was a comment, a docblock, a count or a claim about what a test proved.

So the streams wrote good code, and the gates found what gates find. The failures were in the premises, the instruments and the prompts. That's the orchestrator's job, and no gate was pointed at it.

Point the Refute Pass Upward

The fix I'm adopting is one I already use elsewhere.

In Refute, Don't Review I described handing an agent's verdict to a fresh agent whose only job is to prove it wrong. I've been doing that for the streams' work. I hadn't been doing it for the orchestrator's.

The briefs deserve the same treatment. Before a brief goes out, every factual premise in it should face a "prove this wrong" pass. That goes double for absence claims, and for anything relayed from another session.

If you run even two sessions, you can apply this today:

Write every premise you pass along as something to verify, with the check spelled out.
Before you trust "nothing changed" or "nothing found," make sure your tool can see the thing when it's there.
Name every shared resource in the prompt, not just the files.
Put your standing rules in every prompt, every time. The agent doesn't know what you know.