The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do
Short summary
Meta found that a single AI agent loaded with all the domain knowledge hallucinated in production, so they split the system into a deliberately dumb router that only sequences work and runs reliability checks, plus 14 specialist agents that each handle one domain. The result cut column configuration prep from about a day to under an hour, with roughly two-thirds of changes landing without significant human edits.
- A single "know everything" agent degraded past a certain context size, cross-contaminating naming conventions and code patterns across data sources; the fix was giving the central agent less to do, not better prompts or a bigger context window.
- The orchestrator is 1,300 lines and does no domain work: it follows a fixed seven-step protocol where only one step involves LLM reasoning, and that step runs inside an isolated subagent.
- New use cases are added by writing new workflow templates that sequence the existing 14 subagents differently, so pipeline migration needed zero new agent code.
Full summary
Meta's data pipeline team started with what most teams try first: one capable AI agent loaded with all the domain knowledge for onboarding data columns across its recommendation systems. The task spans three repositories, three languages, and up to six pipeline stages that have to stay in sync. In demos it looked fine. In production the agent started hallucinating, mixing naming conventions and code generation patterns across subsystems. Adding more context made things worse past a certain threshold. A single-agent alternative only hit 70-80% success when an engineer hand-crafted a prompt for each job, and dropped to 10-20% without that help. The team concluded this was an architecture problem, not a prompting problem.
Their fix was what they call a thin orchestrator. It is a deterministic router of about 1,300 lines that routes 20+ workflows to 14 specialized subagents and does no domain reasoning itself. It classifies intent, collects required fields, checks for duplicates, runs reliability gates, and delegates. Each subagent holds only its own domain knowledge, so the population agent for one data source never sees patterns meant for another. Knowledge lives in 25+ files loaded at runtime, so updates take effect without touching the orchestrator. The orchestrator follows a fixed seven-step protocol, and only the delegation step involves LLM reasoning, inside an isolated subagent. Workflows are defined as state machines, such as Schema → Validation → Population → Testing for column onboarding, and the same agents get reused in different sequences. When they added pipeline migration, they wrote a new template and no new agent code.
The reported results are concrete. Configuration prep for a new column fell from three to four days by hand, and about a day under their earlier config-driven system, to under an hour now. Roughly two-thirds of the system's changes land without significant human edits. The authors are upfront that this comes from trading generality for depth: the orchestrator is general and the specialists are narrow. They also cite a Mount Sinai preprint reporting 65.3% accuracy for orchestrated multiagent systems on 80-task batches versus 16.6% for a single agent, with up to 65-fold lower token use. For anyone building production agents, the transferable lesson is to keep routing deterministic, keep the orchestrator dumb about the domain, and let failures stay contained within a single subagent.