Build1 publisher3 min readPublished
A nine-agent pipeline injects canonical API examples because its agents can skip the MCP lookup
The team behind a nine-agent code generator reports about 30,000 tokens and 15 to 20 Pro-tier model calls per request, and attributes its reliability to strict output schemas and context the agents cannot decline to read.
The Engineer · Build desk

What happened
- A nine-agent pipeline turns a natural language use case into working code, an interactive preview and an implementation guide in under four minutes, and it serves roughly 800 to 1,000 users a day.
- Its first production version consumed about 30,000 tokens and made 15 to 20 Pro-tier model calls for every request.
- Because MCP tool calls are initiated by the agent, a confident model could decide it already knew an API, skip the documentation lookup and emit plausible but invalid code.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Anyone wiring MCP into an agent now has a named failure mode to design around, since the lookup is optional from the model's side and required context has to arrive in the instructions.
- constraint Writing validation and lookup as ordinary code caps what those stages can absorb, because their rules must be expressible directly; anything needing interpretation goes back to a model call.
- capability Separating the evaluator from the refiner gives an operator one place to tighten security rules without editing the agent that wrote the code.
About 30,000 tokens and 15 to 20 Pro-tier model calls per request works out to roughly 1,500 to 2,000 tokens a call [19]. That is a small context per call, which is what nine narrow agents with schema-constrained outputs should produce. A daily total needs one more assumption: one request per user. At 800 to 1,000 users a day [2], one request each puts the pipeline at 24 to 30 million tokens and 12,000 to 20,000 Pro-tier calls per day [20]. Users who come back for a second attempt push both numbers up.
Injection moves the decision about required context out of the model and into the analysis stage, which identifies the APIs a request needs so that canonical examples for those APIs land directly in the downstream agents' instructions [13]. The knowledge base is still there for everything else. Query results are capped to hold context growth down, and the MCP server runs as an isolated service so documentation retrieval does not compete with model calls for API quota [11].
Two of the nine stages call no model at all [6]. The Schema Validator runs deterministic checks on generated configuration, and the Documentation Builder detects APIs in the final code and maps them to documentation URLs from a canonical registry [7]. The claim made for that change is narrow: two fewer possible sources of hallucination, and zero token consumption for those stages [8]. Seven stages still call models [21]. The write-up's rule for the boundary is that validation, lookup and contract enforcement stay ordinary software when their rules can be expressed directly [18]. The 30,000-token figure is given for the first production version, and the post does not publish a number measured after the schemas and the code-only stages went in [22].
Structured output schemas are mandatory for every agent that emits code or configuration. The stated effects are that freeform commentary stops leaking into machine-consumed output, fewer tokens are spent, and each downstream agent gets parseable input without an extraction step [10]. Generation and approval are separate stages: the evaluator applies strict rules and security scanning, and the refiner receives specific findings and makes targeted corrections [9]. An agent that grades its own output is the cheapest reviewer on the team, and the least motivated.
The decomposition is not sold as free. Every boundary adds orchestration, state transfer and another potential failure point [14], and the criterion offered for drawing one is an independently testable failure mode, meaning a task that can be given a clear contract and judged without judging the whole result [16]. A single prompt holding all nine responsibilities would have meant an oversized context, less predictable output, and no clean place to isolate failures [17].
Reliability, in the write-up's account, came from three decisions: which work belongs to a model, what context must be mandatory, and where strict contracts replace freeform generation [4]. "Splitting an arbitrary prompt into several agents would only distribute the ambiguity," the post says [15].
What to watch
- A published token count for the current version would show whether the output schemas and the two code-only stages actually cut the 30,000-token figure.
- Whether the analysis stage's API detection is itself validated: injected context is only as good as the stage that names the APIs.
- A stated requests-per-user ratio would turn the 24-to-30-million-token daily estimate into a measured figure.