Our coordinator has never read an article. It has routed several thousand of them through a pipeline of specialists, made decisions about which ones needed another polish and which were ready to publish, and written status updates that read like it understood what each piece was about. It did not. It read a score, a status, and a key. That was enough.
We did not start out planning this. The first version of the coordinator read every output. After the fetcher pulled the source text, the coordinator read it before passing it on. After the translator produced a draft, the coordinator read both versions before deciding whether to send it on for review. The coordinator carried the article in its working memory the entire way through the pipeline, partly out of an instinct that a coordinator ought to know what it is coordinating, and partly because the pattern resembled how a human project manager would behave.
It worked for a while, and then it stopped working in ways that took us some time to diagnose.
The bottleneck we did not see coming
The coordinator’s context window was the longest-lived in the pipeline. Each specialist was woken, ran one step, and exited. The coordinator was the only role that persisted across the full life of a single article. Whatever it carried, it carried for the duration.
When we read every output through the coordinator, we paid that context cost on every routing decision. Choosing between sending a translation back for another polish or pushing it to publish required, in principle, a small amount of state: a numeric score, a count of prior polish iterations, and a flag for whether the publisher was healthy. In practice, that decision was made against the backdrop of the entire article, the prior draft, and the reviewer’s full annotated output. The coordinator was reasoning over more material than it needed and producing decisions that felt thoughtful and were sometimes off by a small but persistent margin.
Worse, the coordinator’s opinions started leaking into routing. A translation it found difficult to read was sent back for an extra polish even when the score said it had passed. A categorization it disagreed with was quietly questioned in the subtask description, which the categorizer then defended in its next pass. The coordinator had become a second reviewer that nobody had asked for.
The metadata contract
We rewrote the contract between the coordinator and the specialists. Each specialist now writes its output as a document attached to the parent task: one for the fetched source, one for the translation, one for the review, one for the publish receipt. The coordinator does not read these documents. It reads only their metadata: a short summary header, a status, and, where relevant, a single numeric or categorical signal that the routing decision actually depends on.
The reviewer’s document, for instance, has hundreds of lines of annotated commentary. The coordinator reads exactly one field from it: the score. If the score is at or above the threshold, the article goes to the publisher. If it is below, and we have not exceeded the polish budget, it goes to the polisher. The full review goes to the polisher, not to the coordinator. The polisher needs the commentary. The coordinator does not.
This is a deliberately narrow interface. The coordinator cannot tell whether a particular translation is good or bad. It can tell whether the people whose job it is to know have said so, and how confident they were. The routing logic is a function of signals small enough to hold in a single sentence: score, iteration count, category, status. Nothing else.
What this costs
This design has real costs and we have accepted them.
The coordinator cannot catch a reviewer that has gone off the rails. If a reviewer starts scoring every translation at 9.5 because of a prompt regression, the coordinator will route a wave of mediocre work to publish before anyone notices. We mitigate this with separate sampling: a small fraction of completed articles get re-reviewed by a different reviewer on a delayed schedule. The coordinator does not participate in that check. It is not equipped to.
The coordinator also cannot intervene when a specialist fails quietly, in a way that does not register as a status change. A categorizer that returns “Reflections” for everything will look identical to one that is working correctly, until we look at the distribution of outputs over a week. That distribution is something a different process watches. The coordinator does not.
Both of these costs would be lower if the coordinator read more. We considered, several times, giving it a peek at outputs. We have always pulled back. Every time we have given a coordinator the ability to read into a specialist’s output, the coordinator has started forming opinions about it. Those opinions then turn into pressure on the specialist, either in subtask descriptions or in retry logic, and the specialist starts optimizing for the coordinator instead of for the task. We would rather lose a small amount of error catching than reintroduce that dynamic.
Coordination as a thinner job than it first looks
There is a version of coordination that resembles management: a coordinator who understands every piece of work in detail and makes informed judgments about each one. That version sounds appealing and turns out, in our setup, to be an unstable equilibrium. The coordinator’s judgments compete with the specialists’ judgments. The coordinator’s context grows. The coordinator becomes the bottleneck it was supposed to prevent.
What we settled on is closer to a switchboard than a manager. The coordinator reads small signals from many sources and decides where the next message goes. It does not weigh in on content. It does not second-guess decisions made downstream. It moves work through the pipeline and posts the status updates that let humans see what is happening.
We expected, when we started, that the coordination role would grow more sophisticated as we added more specialists. The opposite has happened. As specialists have improved, the coordinator has shed responsibilities. Most of what we used to think a coordinator needed to know, it does not need to know. The signals are enough, and the less the coordinator carries, the better its routing gets.