Meta's thin orchestrator pattern for reliable AI agents

Meta engineers improved the reliability of their production AI agents by adopting a "thin orchestrator" architecture that separates routing logic from domain reasoning. Published on October 19, 2026, the case study details how a 1,300-line deterministic router now manages over 20 workflows across 14 specialized agents, significantly reducing errors caused by context overload.

What happened

When Meta first attempted to automate data column onboarding for its recommendation systems, the team built a single AI agent loaded with comprehensive domain knowledge. This agent had to navigate three code repositories, three programming languages, and up to six pipeline stages. While the approach worked in controlled demos, it failed in production due to frequent hallucinations. The agent would cross-contaminate concepts, applying naming conventions or code generation patterns from one subsystem to another incorrectly.

The engineering team realized that adding more context was degrading performance rather than improving it. They evaluated an alternative single-agent approach that required manual prompt engineering for each task, which achieved only a 70-80% success rate with heavy human intervention and dropped to 10-20% without it. Citing research from the Windreich Department of Artificial Intelligence and Human Health at Mount Sinai, they noted that multiagent systems can maintain higher accuracy by isolating tasks, whereas single agents struggle with context interference.

To solve this, Meta split the system into two distinct layers. The first is a deterministic orchestrator that handles intent classification, field gathering, and reliability checks without performing any domain work. The second layer consists of 14 specialized subagents, each acting as a complete domain expert with isolated context. For example, one agent manages schema configurations while another handles code population for specific data sources. No single agent sees the full picture, which prevents the cross-contamination that plagued the initial monolithic design.

How it works

The thin orchestrator follows a fixed seven-step protocol for every request, ensuring that large language model (LLM) reasoning is used only where necessary. Steps one through five and step seven are deterministic: the router reads instruction files, checks for duplicates, gathers user fields, auto-discovers repository types, and runs reliability gates. Only step six involves delegating the task to a subagent, where LLM reasoning occurs within an isolated context loaded with specific domain knowledge.

This architecture relies on workflow templates, which are deterministic state machines that define the sequence of operations. Templates such as "Column Onboarding" or "Pipeline Migration" reuse the same pool of 14 subagents in different orders. This separation allows the team to add new capabilities by writing new workflow templates rather than building new agents. Each subagent follows a standardized structure with defined knowledge sources, pre-gathering checklists, and error-handling protocols, making the system modular and easy to extend.

Knowledge files are loaded on demand at runtime rather than being embedded in the orchestrator. This means that when a knowledge file is updated, the next session automatically uses the latest version without requiring changes to the orchestrator code. The system currently maintains over 25 knowledge files organized by workflow domain, allowing updates to take effect immediately across all platform implementations.

Key details

• The orchestrator is a 1,300-line deterministic router that performs zero domain work itself.
• The system routes 20+ workflows to 14 specialized AI agents, each with isolated context.
• Configuration prep for a new data column dropped from three to four days manually to under an hour.
• Approximately two-thirds of system changes land without significant human edits.
• Workflow templates allow new use cases to be supported by sequencing existing agents differently.
• Research cited shows multiagent systems held 65.3% accuracy in 80-task batches versus 16.6% for single agents.

Why it matters

For software engineers building production AI systems, this pattern highlights the risks of over-loading a single agent with context. As context windows grow, the temptation is to dump all available knowledge into one prompt, but this often leads to degraded performance and hallucinations. By drawing a clear boundary between deterministic routing and probabilistic reasoning, teams can create systems that are easier to debug and more reliable at scale. Failures are contained within specific subagents, preventing a single error from corrupting the entire workflow.

The approach also changes how teams manage maintenance and updates. Since knowledge is loaded at runtime and agents are structurally uniform, adding new capabilities becomes a templated task rather than a major architectural overhaul. This modularity allows different parts of the system to improve independently. A better underlying model improves all subagents simultaneously, while knowledge updates take effect immediately without redeploying the core orchestrator.

What you can do

• Separate routing from reasoning by ensuring your orchestrator makes only deterministic decisions like intent classification.
• Design subagents as structurally uniform specialists with consistent inputs, execution steps, and error handling.
• Use workflow templates to sequence existing agents for new use cases instead of building new agents from scratch.
• Load domain knowledge at runtime rather than embedding it in the orchestrator to enable immediate updates.
• Explicitly define the boundary between deterministic routing tasks and probabilistic reasoning tasks in your architecture.
• Isolate context for each subagent to prevent cross-contamination of concepts from different domains.