Meta Engineering team @Meta_Engineers published Agent architecture practices: "Thin Orchestrator," an architectural choice to make Agents more reliable
A central main Agent "performs worse the more it knows"; this is not a prompt problem, it's an architecture problem!
The Meta team initially automated the data column onboarding process of their recommendation system with a single "all-powerful Agent": it loaded all domain knowledge, schemas, code generation rules, routing logic, and validation requirements at once. The result was that it worked normally in demos but began producing hallucinations in production. The specific symptom was knowledge cross-contamination: applying subsystem A's naming conventions to subsystem B, and using code generation patterns meant for one data source on the wrong object.
This phenomenon has empirical support: they cite research from Mount Sinai showing that multi-Agent orchestration systems maintained 65.3% accuracy on batches of 80 tasks, while single Agents managed only 16.6%, with token consumption reduced by up to 65x. The reason is that task isolation prevents context from interfering with each other; beyond a certain context threshold, more knowledge actually degrades performance.
Solution: a two-layer architecture with strict responsibility boundaries
Layer one: a deterministic thin orchestrator (about 1,300 lines of code) with zero domain work. It routes 20+ workflows to 14 specialized Agents and itself only does three things: intent classification, collecting necessary fields, and running reliability checks. It never reasons about code, never generates configurations, and never touches the codebase.
Layer two: 14 context-isolated specialized Agents, such as the schema management Agent, the population Agent (responsible for code generation across 10 data sources), and the validation Agent. The key design is that no single Agent sees the whole picture; this is deliberate.
Each request follows a fixed 7-step protocol: read the sub-Agent instruction file → check for duplicates → collect user fields → auto-infer (such as repo type) → reliability gate check → delegate to sub-Agent → process results. Steps 1–5 and step 7 are entirely deterministic logic; only step 6 involves LLM reasoning, and that reasoning happens in an isolated environment that loads only its own domain knowledge.
The most valuable engineering insight: reuse templates rather than add new Agents
They separate "what to do" (workflow templates) from "how to do each step" (sub-Agents). Templates are deterministic state machines, for example:
· Column onboarding: Schema → Validation → Population → Testing
· Event onboarding: Schema → Population → Validation → Testing → Event handling
· Pipeline migration: Assessment → Planning → Population → Validation → Monitoring
When supporting the entirely new capability of pipeline migration, they only needed to add one template that rearranges existing Agents, "zero new Agent code, full production capability." All sub-Agents share a unified structure (knowledge sources, pre-collection checklist, workflow steps, error-to-solution mapping), so the 15th Agent is structurally identical to the first, and adding new capabilities becomes templated work.
Knowledge is loaded on demand at runtime rather than embedded: 25+ knowledge files are organized by domain, each typically a few thousand tokens. Updates take effect automatically in the next session, and the same file can serve multiple platform implementations.
Blog link
https://engineering.fb.com/2026/10/19/ml-applications/thin-orchestrator-ai-agent-architecture/