The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do

Meta engineers described how they rebuilt AI agents that onboard data columns across the company's recommendation systems, a job that touches three code repositories, three programming languages, and up to six pipeline stages. Their first design, one agent loaded with every schema and rule, worked in demos and then started hallucinating in production.

The fix was a roughly 1,300-line orchestrator that does no domain work at all. It classifies the request, collects required fields, runs reliability checks, and hands the job to one of 14 specialist agents, each with isolated context. Only the delegation step uses language-model reasoning.

Meta says configuration prep for a new column went from three to four days by hand, and about a day with its earlier config-driven system, to under an hour. About two-thirds of the system's changes land without significant human edits.

This is the kind of post we wish more companies wrote. It names a failure, explains it, and shows the fix with numbers. The core finding is counterintuitive and, we think, correct: past a certain point, more context makes an agent worse. Meta's single agent mixed up naming conventions between subsystems and borrowed code patterns from the wrong data source. An alternative single-agent setup reached 70 to 80 percent success only when an engineer hand-wrote a prompt for each task, and fell to 10 to 20 percent without that help. That is not a prompting problem. It is architecture.

The design principle we would underline is the boundary between deterministic and probabilistic work. Deciding which specialist handles a request is routing, so Meta does it with fixed rules, not a model. Each workflow is a template, a state machine that sequences existing agents. When a new use case arrived, pipeline migration, the team wrote a new template and no new agent code. Knowledge files load at run time, so an update takes effect the next session without redeploying the router.

We think this pattern travels well. Most agent failures we see in the wild come from one model being asked to plan, route, remember, and execute all at once. Shrinking the job of the central component also shrinks the blast radius when something goes wrong. A failed specialist gets retried or escalated; it does not corrupt everything downstream.

The caveats: this is a single internal use case, measured by the team that built it, and the outside accuracy figure it leans on comes from a preprint, not a settled result. Two-thirds landing without significant edits also means a third still needs real human work. And the pattern trades generality for depth. It shines on well-understood, repeatable workflows, less so on open-ended problems.

Where this leads if it scales is mostly good news: more reliable automation of tedious engineering work. The quieter risk is what Meta mentions last, automated loops that propose changes to agent knowledge from production failures. Meta says human review gates those changes. We would want that gate to stay firmly closed by default.

Meta's pipeline is config-as-code: Python configurations generate C++ code that feeds data processing services and analytics systems. The orchestrator follows a fixed seven-step protocol for every request, and the team maintains more than 25 knowledge files organized by workflow domain. Meta cites a Mount Sinai preprint that found orchestrated multi-agent systems held far higher accuracy than single agents on large task batches.