Why Your AI Agent Should Know Less The Thin Orchestrator Pattern That Scaled at Meta

The Counterintuitive Fix: Give Your Agent Less to Do

Most teams building production AI agents start the same way: one smart agent loaded with every schema, rule, and pattern it might need. It demos beautifully. Then production happens — and it starts hallucinating.

At Meta, this exact failure mode appeared while automating data column onboarding across recommendation systems spanning three code repositories, three languages, and up to six pipeline stages. The first attempt was a single agent stuffed with all domain knowledge. Past a certain context threshold, more knowledge made it worse, not better. The agent cross-contaminated concepts — applying field naming conventions from one subsystem to another, or using a code generation pattern meant for a different data source.

A preprint from the Windreich Department of AI and Human Health at Mount Sinai backs this up: orchestrated multiagent systems hit 65.3% accuracy on 80-task batches where single agents collapsed to 16.6%, while cutting token usage up to 65-fold. The mechanism is task isolation preventing context interference. Meta was experiencing the inverse: one agent drowning in its own knowledge.

This analysis is based on Meta Engineering's published writeup — see the 근거자료 for the full production details.

The Architecture: A Deterministic Router + Isolated Specialists

The system splits into two layers with a hard boundary between them:

1. A thin orchestrator (~1,300 lines) that performs zero domain work. It classifies intent, gathers required fields, runs reliability gates, and delegates. It never reasons about code, never generates configs, never touches the repo.
2. Fourteen specialized subagents, each a complete domain expert with an isolated context window. The schema agent knows config registries. The population agent knows code generation for 10 data sources. The validation agent knows build systems. No agent sees the full picture — that's the feature.

The orchestrator runs a fixed 7-step protocol on every request:

# Fixed protocol — steps 1-5 and 7 are deterministic, only step 6 uses LLM reasoning
def handle_request(user_request):
    # 1. Load the target subagent's instruction file
    instructions = load_subagent_instructions(classify_intent(user_request))

    # 2. Duplicate check — does the target already exist?
    if target_exists(user_request):
        return early_exit("Target already exists")

    # 3. Gather required fields from the user
    fields = collect_required_fields(user_request, instructions.checklist)

    # 4. Auto-discover what can be inferred (repo type, existing configs)
    inferred = auto_discover(fields)

    # 5. Reliability gate: active warnings, required reviewers
    gate = reliability_check(fields, inferred)
    if not gate.passed:
        return escalate(gate.reason)

    # 6. Delegate to the subagent — the ONLY LLM reasoning step
    result = subagent.execute(context=fields + inferred)

    # 7. Surface results and errors deterministically
    return confirm_or_report(result)

Workflow Templates, Not New Agents

The second key insight: separate what needs to happen from how each step is done. The orchestrator defines phase ordering via deterministic state machines that constrain the LLM's decision space:

When Meta needed pipeline migration — a completely new use case — they wrote zero new agent code. They wrote a new workflow template that resequenced the existing 14 subagents. Each subagent follows a uniform structure (knowledge sources, pre-gathering checklist, step-by-step workflow, discovery patterns, troubleshooting), so the 15th subagent looks structurally identical to the first. Knowledge files (25+) load on demand at execution time, not embedded in the orchestrator — an update takes effect on the next session with no redeployment.

The Limits and Caveats

This pattern is not a free lunch, and Meta's writeup is honest about the trade-offs:

• You trade generality for depth. About two-thirds of system changes land without significant human edits — but that's because each subagent is narrowly scoped. A request that falls outside any workflow template has no path through the system until you write one.
• Upfront design cost is real. Defining 14 clean domain boundaries, uniform subagent structure, and deterministic reliability gates is significant architecture work. The payoff arrives at scale, not on day one.
• The deterministic boundary must be drawn explicitly. For every component, decide: is this a routing decision (deterministic) or a reasoning task (probabilistic)? Mixing them is how heavyweight orchestrators fail — when a fat orchestrator hallucinates, the error propagates downstream: wrong agent, wrong fields, skipped reliability checks.
• It doesn't fix bad subagents. Isolation contains failures; it doesn't make a specialist correct. You still need validation and human review gating any automated knowledge updates.

Where to Go Next

The compositional thesis predicts scaling means adding workflow templates and knowledge files — not rebuilding agents. If you're building production agents, start by auditing your orchestrator: if it's making domain decisions, it's doing too much. Push that reasoning into isolated subagents and keep routing deterministic. For a look at how a data foundation layer supports agentic systems, see Beyond the Model: How Pantone Built an AI-Ready Data Foundation for Agentic Creativity.

The Bottom Line

The most important component in Meta's AI agent system is the one that does the least work. A thin orchestrator leaves little room for hallucination because routing and reliability steps don't rely on LLM reasoning — they follow a fixed protocol. The creativity happens downstream, in isolated, domain-scoped contexts where risk is minimized and failures are contained.

Keep your orchestrator thin and your specialists deep, and the whole system becomes more reliable. If you're theming UI components while you build out your agent dashboards, the CSS relative colors and OKLCH animation theming guide pairs well with this architectural mindset — deterministic tokens, isolated concerns.