The reviewer was checking the paperwork, not the work.

A pipeline of AI agents that had been running fine for months started getting slower. Not suddenly, and not because anything external changed. The same jobs, hitting the same sources, running extraction logic that had been written and working since spring. Median run time roughly doubled over a few weeks, from 5.7 minutes to 12.2. The worst runs were taking fifty.

Then the jobs started failing outright on rate limits. Not because any single task was hard, but because the system had begun generating enough traffic to throttle itself.

Repetition is supposed to make a system like this cheaper. The hard part, working out how to get the data, had been solved months earlier. Something was consuming more every time it ran, and it was not the work.

Stop profiling the workers

The instinct is to profile whichever agent does the heavy lifting, because that is where the time must be going. That instinct is what kept this hidden for six weeks.

Instead of timing anything, I counted raw output volume by role. Four days, 619 agent turns, 4.5 million characters of agent text.

The orchestrator produced 67.8% of it.

The orchestrator fetches nothing. It publishes nothing. It has no tools pointed at the outside world at all. Two thirds of everything the system said was a manager talking about work rather than doing it, at an average of 4.2 review turns per run.

That alone was enough to act on. But one more pass changed my mind about what was actually wrong. I categorised what those review turns were about.

76% concerned the internal consistency of data keys the agents had invented themselves. 3% concerned whether the data was correct.

The reviewer was checking the paperwork, not the work

Seventy-six against three is not a tuning problem. It is a reviewer doing something that pattern-matches to diligence, expensively, on a dimension nobody cared about.

Worse, the paperwork it was enforcing was not a spec anyone had written. The agents had invented those keys along the way, and the reviewer then held them to their own inventions as though they were a contract.

Once you see that split, the runaway is obvious. Each review round produced a list of inconsistencies. The worker went back and repaired them, and repairing them meant re-emitting the whole payload. Every re-emission was a fresh chance to pull in a stale figure, add an explanatory field, or restructure something that had been fine. Payloads grew six to thirteen times over. One lane finished with 800 keys in a single output.

More keys meant more surface for the next review to find fault in, which produced another round, which grew the payload again. Worker rounds per run tripled, from 1.08 to 3.21, and nearly all of the extra rounds were spent on problems the earlier rounds had created.

The review loop was manufacturing the defects it kept discovering.

Where prompt bloat stops being a cost problem

There is a hard edge in here that I found the expensive way.

The orchestrator drives its agents by injecting prompts into a terminal session in chunks. Above roughly 23 KB, those chunks get batched into a single paste and the brief arrives duplicated. Two jobs blocked on exactly this. One at 27,436 characters arrived in three fragments. Another at 23,507 had each of its sections appear twice. The worker halted, produced nothing, and the delivery agent correctly refused to publish nothing.

So past a certain size the bloat stopped being expensive and started being corruption.

The fix is smaller than the diagnosis

I added one setting to the pipeline definition: a per-phase evaluator, answering a single question. When this phase finishes, who judges it?

• Worker phase, judged by the delivery agent. The worker hands its output straight to the agent that has to consume it. No manager in between.
• Delivery phase, judged by itself. It already emits a canonical decision token saying what it did. The pipeline reads that token and terminates on it. No reviewer call at all.
• Orchestrator, plans and signs off. Nothing in between.

The manager still writes the brief and still owns the final verdict. It just no longer stands between two agents perfectly capable of talking to each other.

The principle underneath is the part worth stealing. The right reviewer is the one who has to live with the output. The delivery agent cares whether the data is complete and correctly shaped, because it is the one that has to publish it and the one that fails if it is not. The orchestrator had no such stake, so it reviewed the only thing visible to it, which was structural tidiness. It optimised for what it could measure.

Alongside the routing change I capped the round budget from 10 to 3, and told the orchestrator explicitly that the brief's schema is a ceiling rather than a starting point, with a target of 8,000 characters.

What it did

Measured on one representative job, before and after:

• Delivered result: identical. The same published record either way. This is the control, and it is what makes every other number mean anything.
• Agent chatter per run: 55,998 to 22,595 characters. 33,403 saved.
• The orchestrator's own plan: 12,945 to 5,870 characters. 2.2 times leaner.
• Round trips to done: 3 to 1.

Read that carefully, because it inverts easily. The work did not go down. The talking did. An identical record, produced from a third of the round trips and 2.5 times less agent text, is more work per token rather than less work.

The rate-limit failures stopped as well, because the system was no longer competing with itself for its own quota.

One caveat that belongs on the scoreboard: fleet-wide median run time has not come down yet. 12.8 minutes since the change, against 12.2 before. That is not a contradiction, it is an incomplete rollout. Two pipelines have moved to the new routing and most scheduled jobs still run the old flow. The 2.5 times is a controlled before-and-after on one job, not a claim about the fleet, and I would rather say so than quote an average that has not earned it.

Two things that broke, including a fix I deleted

The reviewer turned out to be the deliverer. Making the delivery agent review the worker's phase created a role conflict I had not thought about. On one run it looked at the worker's output during its review turn, decided the data was ready, and published it right there. Its own delivery phase then ran, found the record already present, and correctly reported a duplicate no-op. The run was filed as "no new data" despite having succeeded perfectly. The data was fine. The label was wrong.

The fix was a prompt-level fence: this is a review turn, not your work turn, do not publish here, you get your own turn immediately after. Cheap, and it holds.

The second fix I wrote, tested and threw away. I built a detector to catch runs mislabeled that way and relabel them, scanning execution logs for evidence that a publish had happened.

It failed its own test. It returned "not delivered" for the known-bad run I had built it for, and "delivered" for a normal run that had published nothing. A sweep across history flagged 18 runs, mostly false positives. The review turn logs a verdict rather than a delivery report, so the evidence I was looking for was never there to find.

I reverted it. A detector that is wrong in both directions is worse than the bug it chases, because now the labels cannot be trusted either way. The cosmetic mislabel stays until I can query the destination API by timestamp and get a real answer.

What to take from it

If you run a multi-agent pipeline, count output by role before you tune anything. The number that mattered here, two thirds of all output coming from the one agent that touches nothing, was invisible until somebody went looking for it.

Then ask what your reviewer is actually reviewing.

Review is not free and it is not automatically good. Adding a checker feels like pure safety. It is not. It is a feedback loop, and feedback loops can run away.

Route reviews to whoever bears the consequence. An agent with no stake in the outcome will review whatever it can see rather than whatever matters.

Managers should plan and sign off, not stand in the middle. That is ordinary organisational design, and it turns out to apply to software agents about as well as it applies to people, for roughly the same reason.