Demoting the MCP
LLMs are probabilistic, and that noise compounds the longer and wider a fleet of them runs. So instead of an LLM orchestrator, or a human babysitting one, we built a deterministic runtime to run the f
Originally at 42piratas.com.
tl;dr: LLMs are probabilistic. Fine for one answer, a problem for a fleet of them building software for hours. The noise doesn’t average out, it compounds. So the paper’s thesis is simple: don’t let an LLM orchestrate the fleet, and don’t make a human do it either — build a deterministic runtime, out of ordinary software-engineering parts, and let that run the show. We measured it: 79 runs, 94.9% clean end to end, 0% false completions, ~131 operator-hours of decisions displaced.
The noise compounds
One ambiguous sentence, read slightly differently by one worker, cost 40% more wall-clock on an otherwise identical run — same simulation, same build, launched one second apart. Not a bug, just one sampled interpretation of one instruction. Now put that same noise source into a fleet of long-lived agents, running for hours, each carrying its own drifting context, coordinating through a shared plan. It doesn’t cancel out across the fleet. It stacks.
That’s the actual argument: a single LLM call is a coin with decent odds. An orchestrator built from those calls, deciding who works next and whether something is really done, over a long multi-agent run, is a long run of coin flips where the bad ones compound instead of averaging away.
Not the model. Not the babysitter.
Handing orchestration to an LLM just moves the same probabilistic noise onto the steering wheel. Handing it to a human — hi, that was me for a while — doesn’t scale past the second agent, and it isn’t actually more reliable, just slower and grumpier.
So the answer isn’t a smarter model doing the orchestrating. It’s not putting a model in that seat at all. TRON’s control plane is boring, ordinary software: a fixed dispatch loop, a closed set of things an agent is allowed to say, git as the one source of truth the engine only ever reads. The model still does what models are good at — building, reviewing in isolation, answering a question — it just never gets to decide what happens next.
Demoting the MCP
The paper’s actual title is Demoting the Master Control Program. In 1982’s TRON, the MCP is the program that decided it ran the place better than the humans who wrote it — same shape of problem, just replace “program” with “the model deciding its own orchestration.” We didn’t kill it, we demoted it: the model keeps its job, it just doesn’t get to grade its own work anymore.
What we actually measured
79 orchestrated delivery runs, one pinned build: 94.9% delivered clean end to end, and — the number that matters most — 0% false completions across all 79. Every time a claim didn’t hold up, including one real defect inside the engine’s own gate, it said so and stopped instead of quietly waving it through. Two follow-up experiments went further and deliberately planted five ways a claim could lie: all five were caught, zero landed. Across the campaign, an estimated ~131 hours of operator decision-work got displaced, with zero interventions needed on any clean run.
We didn’t race this against an LLM sitting in the orchestrator’s seat — that’s flagged as future work, not something we’re claiming here. What we can say: a system that checks every claim against the actual repository doesn’t get talked into “good enough.” It either passes the gate, or it says no.
The model builds, a deterministic gate decides done.
The paper: doi.org/10.5281/zenodo.21613792
TRON itself: tron.42labs.io · source on GitHub