Multi-agent systems that build software usually coordinate their agents through a language model: an orchestrator reasons in prose about who works next, whether a task is done, and when to involve a human (the operator). This puts a probabilistic component on the control path of a system whose value depends on reliability, and holds orchestration state inside a process that cannot be safely interrupted. Recent work argues the inverse for a single workflow — fix an explicit blueprint and confine the model to bounded steps (Qiu et al., arXiv:2508.02721). We lift that paradigm to the harder problem of orchestrating many concurrent, long-lived agentic builders, and present TRON, a deterministic finite-state orchestrator: a fixed dispatch loop advances every block by table lookup over a closed, lint-validated vocabulary, and the model never chooses the next step. The claim is the paradigm, not the artifact — a deterministic control plane is built to design out the coordination, long-horizon, and self-verification failures that published work attributes to LLM-routed orchestration — a design claim we ground in that failure literature, not in a head-to-head baseline (§15) — while keeping the operator in contact through an agent they can talk to. Its central invariant: the model builds, but a deterministic gate decides done — we trust neither the agent's report nor the commit.
We report a pre-registered campaign of 74 orchestrated delivery runs on one immutable engine build (three ablation arms, a wide-parallelism arm, and a main @2 configuration run to a clean target of 30, at 34 attempts), plus a separate post-hoc 5-run PROJECT-04 extension (15 blocks, seven dependency layers, nearly twice as wide and ~40% deeper). The headline reliability configuration — PROJECT-03 main @2 — delivered 30 of 34 clean (88%, an optional-stopping estimate); across all 74 campaign runs — which also fold in ablation and wide-parallelism arms, where walls are rare at this scale — 70 were clean, and the fixed-build extension delivered 5/5 — every declared block built, landed, and re-validated on trunk with zero operator intervention, each product passing separate in-house probes. The four non-clean runs are reported in full — and three never touched the engine's decision path: two were our own test harness leaking state between trials and one was an external API outage. The fourth was a real engine defect (since fixed with regression tests), and even then the engine refused to fake a result. Every one failed safe — the orchestrator escalated rather than close work it had not done, and under the operator-dark protocol the run terminated there. The gate's rejection behavior is shown directly by six by-construction false-done fixtures — five seeded shortcuts and one trunk-only defect, on the fixed pin (v0.0.30) with engine, gate, and vocabulary unmodified — all six rejected, none landed. Across the 79 delivery runs no worker ever attempted to close work it had not done, so the 0-of-79 false-completion count is observational — evidence about worker behavior, not the gate under fire; the gate's strength is the 6-of-6 (a small adversarial sample — rule of three bounds the miss rate only at ≤50%). No clean run needed the operator; the only pages were those four. When reality misbehaved, the system said so instead of faking green. Beyond our own benchmarks, the same runtime delivered clean on two MIT 6.5840 labs the course specified and tested — MapReduce and the full Raft lab, 2 of 2 — a first check that gate-decided done transfers to acceptance criteria we did not write (reported separately, not pooled into the campaign rates; §15).