The monolithic agent problem at Meta scale
When Meta deployed AI agents to automate data column onboarding across recommendation systems the team built one smart agent that knew everything. The approach worked in demos but in production the agent started hallucinating. The fix was not better prompts or a larger context window. The fix was giving the central agent less to do.
When one agent knows everything it stops working in production
The pipeline processes data columns across three code repositories three programming languages and up to six pipeline stages that must stay in sync. The first approach loaded the single agent with all domain knowledge configuration schemas code generation rules pipeline routing logic validation requirements and population patterns for ten plus data sources. The agent had everything it needed but that became the problem.
Past a certain context threshold additional knowledge degraded rather than improved performance. The agent would cross-contaminate concepts applying field naming conventions from one subsystem to another or using a code generation pattern meant for one data source when populating from a different one. A preprint from the Windreich Department of Artificial Intelligence and Human Health at Mount Sinai found that orchestrated multiagent systems held 65.3 percent accuracy at 80-task batches where single agents fell to 16.6 percent while reducing token usage up to 65-fold. The authors attribute this to the design isolation of tasks which prevented context interference. The Meta team was experiencing the inverse a single agent drowning in its own knowledge.
The team also evaluated an alternative single-agent approach. Its success rate was 70 to 80 percent with manual prompt engineering per task an engineer had to craft a custom system prompt for each specific job. Without that handholding success dropped to 10 to 20 percent. This was not a prompt engineering problem it was an architectural one.
A deterministic router and fourteen specialized subagents
The solution split the system into two layers. A deterministic orchestrator that performs zero domain work and fourteen specialized subagents each a complete domain expert with isolated context. The orchestrator classifies intent gathers required fields runs reliability checks and delegates to the right specialist. It never reasons about code never generates configurations and never touches the codebase. It is a router.
The fourteen subagents each know a domain completely. A schema management agent knows configuration registries. A population agent knows how to generate code for each of ten data sources. A validation agent knows build systems and quality checks. No agent sees the full picture. That is the feature not the bug.
The orchestrator follows a fixed seven-step protocol for every request. Read the relevant subagent instruction file check if the target already exists gather required fields from the user auto-discover what can be inferred repository type existing configurations reliability gate check for active warnings or required reviewers delegate to the subagent with full context handle results and surface errors confirm success. Steps one through five and seven are deterministic. Only step six involves large language model reasoning and it happens inside an isolated subagent with only its domain knowledge loaded.
Workflow templates that reuse the same specialist pool
One architectural insight was separating what needs to happen from how each step is performed. The orchestrator defines phase ordering through workflow templates deterministic state machines that constrain the LLM decision space. Column onboarding follows schema validation population testing. Event onboarding follows schema population validation testing event processing. Pipeline migration follows assessment planning population validation monitoring. Each workflow template reuses the same pool of 14 subagents in different sequences.
When the team needed to support pipeline migration a completely new use case they did not build new agents. They wrote a new workflow template that sequenced existing agents differently. Zero new agent code full production capability. The 15th subagent looks structurally identical to the first because adding a new subagent is templated work not greenfield engineering.
Knowledge at runtime not embedded in the orchestrator
Each subagent follows a standardized structure knowledge sources which domain files to load at runtime typically a few thousand tokens each pre-gathering checklist what the orchestrator must collect before delegation step-by-step workflow the domain-specific execution plan discovery patterns how to find relevant code patterns in the monorepo troubleshooting error-to-resolution mappings for common failures.
Knowledge files are loaded on demand at subagent execution time not embedded in the orchestrator. The team maintains 25 plus knowledge files organized by workflow domain. When a knowledge file is updated the next session automatically uses the latest version no orchestrator changes required. The same knowledge files serve multiple platform implementations of the agent.
Under an hour to prepare a new column
Configuration preparation for a new column took three to four days by hand and about a day with the earlier config-driven system. The thin orchestrator system does it in under an hour. About two-thirds of the system changes land without significant human edits. The system gets there by trading generality for deep domain knowledge a deliberate architectural choice the orchestrator is general the subagents are specialists.
What makes the pattern reliable
The thin orchestrator works because it aligns architectural boundaries with computational boundaries. Deterministic decisions stay deterministic which subagent handles this is a routing decision not a reasoning task do not use an LLM for it. Context isolation prevents cross-contamination the population agent for data source A never sees data source B patterns it cannot hallucinate the wrong one. Failures are contained if a subagent fails the orchestrator retries or escalates the failure does not corrupt the orchestrator state or other subagents contexts. The system improves at every layer independently a better model improves all 14 subagents simultaneously a knowledge file update takes effect immediately a new workflow template unlocks new capabilities without touching agents no single component carries the full weight.
How teams can adopt this structure
Separate routing from reasoning if the orchestrator is making domain decisions it is doing too much routing should be deterministic keyword matching intent classification field gathering push all domain reasoning into isolated subagents. Design subagents as structurally uniform specialists every subagent should have the same structure knowledge sources required inputs execution steps error handling this makes adding new capabilities templated work rather than architecture changes. Use workflow templates not new agents to scale when a new use case is needed first ask can I sequence existing agents differently if agents cannot be reused across workflows they are too coupled to specific use cases. Load knowledge at runtime not at build time embed knowledge in the orchestrator and every update requires redeployment load on demand and updates take effect immediately across all platforms. Draw the deterministic probabilistic boundary explicitly for every component decide is this a routing decision deterministic or a reasoning task probabilistic the orchestrator should be on one side the subagents on the other do not mix them.
The strongest argument for a thin orchestrator is the failure mode of the alternative when a heavyweight orchestrator hallucinates the error spreads downstream it routes to the wrong agent gathers the wrong fields or skips reliability checks a thin orchestrator leaves little room for hallucination because its routing and reliability steps do not rely on LLM reasoning it follows a fixed protocol the creativity happens downstream in isolated domain-scoped contexts where hallucination risk is minimized and failures are contained.
Meta is scaling this architecture to handle an increase in data columns across new pipeline domains the compositional thesis predicts this will work because scaling means adding workflow templates and knowledge files not rebuilding agents the team is also exploring how the system can continuously improve from production usage using automated feedback loops to identify failure patterns and propose targeted improvements to subagent knowledge with human review always gating any changes.
The counterintuitive lesson the most important component in our AI agent system is the one that does the least work keep your orchestrator thin and your specialists deep and the whole system becomes more reliable.