- 有时，给一个AI agent 所有它需要的知识是错误的方法。
在Meta，我们通过保持我们的数据管道agents的管线层故意变薄，在效率和准确性方面取得了显著的改善：它引导工作并执行可靠性检查，而专业的agents则进行域推理。
我们分享我们自己的过程与见解
我们建造了1300条线的管弦乐器，将20+工作流程引导到14个专业AI agents. 它本身执行零域工作。 这才是重点。
当我们首次部署AI agents在Meta的推荐系统上载数据列自动化时——这个过程跨越三个代码寄存器，三个编程语言，以及多达六个必须保持同步的管道阶段——我们做了大多数团队所做的：我们造了一个聪明的agent，知道一切
它在示范。 在生产中，它开始产生幻觉。
校对：Soup 它给了中央agent 做更少。 我们称这为薄的管弦乐器模式：一种拥有测序和可靠性检查的路由器，将每个域的决定留给专家。
问题：更多背景，更糟糕的结果
我们的管道是配置-as-code: Python配置驱动 C++ 代码生成，它为数据处理服务提供素材，它充斥分析系统。 登入一个单一数据栏，需要在配置登记册、后端服务和数据管道之间协调变化，每一栏在数据到达之前最多经过六个阶段。
我们的第一种方法是装满所有域知识的AI agent，配置计划，代码生成规则，管道的路由逻辑，验证要求，以及10+数据源的人口模式。
agent拥有它所需要的一切。 这就是问题所在。
超越一定的上下文门槛，更多的知识退化，而不是业绩的改善。 agent将交叉污染概念，将字段命名惯例从一个子系统应用到另一个子系统，或者在从另一个子系统输入数据源时使用一个代码生成模式。 来自西奈山温德里希人工智能和人类健康部的预告显示，经过精心策划的多剂系统在80个任务批次中拥有65.3%的精度，单agents下降至16.6%，同时将象征性使用量减少至65倍。 作者将此归咎于设计对任务的孤立，从而防止了上下文的干扰。 我们正在经历逆向，一个agent溺水在自己的知识。
我们还评估了另一种单agent方法。 它的成功率为70-80%，每个任务手动快速工程：一名工程师必须为每项具体工作设计一套定制系统。 没有这种握手，成功率下降到10-20%. 这不是一个迅速的工程问题。 是个建筑设计
方法：有专家工作者的微小路由器
我们把系统分成两层：
- 一个执行零域工作的决定性管弦乐手。 它分类意图，收集所需字段，进行可靠性检查，以及代表给合适的专家。 它从不解释代码的理由，从不生成配置，也从不触及代码库。 这是路由器。
- 14个专业副剂，每个都有一个完整的领域专家，背景孤立。 一个计划管理agent知道配置注册。 一个人口agent知道如何为10个数据源中的每个源生成代码。 一个验证agent知道构建系统和质量检查。 没有agent看到全景。 而不是虫子。
管弦乐团对每一项请求都遵循固定的7步协议：
- 阅读相关子代理指令文件。
- 检查目标是否已经存在(防止重复)。
- 收集用户需要的字段。
- 自动发现可以推断的东西(存储类型、现有配置)。
- 对主动警告或要求的审查员进行可靠性门检查。
- 代表到副代理具有充分的背景。
- 处理结果和表面错误，确认成功。
第1至第5和第7步是决定性的。 只有第6步涉及大语言模型(LLM)推理，它发生在一个只有其域知识加载的孤立子剂内。
What We Built：工作流程模板，不是新 Agents
一种建筑方面的见解是将需要发生的事情与每个步骤的履行方式区分开来。 管弦乐手通过工作流程模板定义相位顺序——决定限制LLM决定空间的状态机器：
- 登机列：Schema验证人口测试
- 登机事件：Schema人口验证测试事件处理
- 管道迁移：评估规划人口验证监测
每个工作流程模板在不同序列中重复使用相同的14个子剂集合。 当我们需要支持输油管迁移时，我们写了一个新的工作流程模板，将现有的agents排序不同。 零新agent码。 全面生产能力。
每个副剂都遵循一个标准化的结构：
- 知识来源：运行时要加载哪些域名文件(通常每个域名几千个)。
- 收集前核对表：主持人必须在代表团之前收集哪些资料。
- 分步工作流程：特定域的执行计划。
- 发现模式：如何在单曲中找到相关的代码模式。
- 解决问题：常见故障的误差与解析绘图。
这种统一意味着添加一个新的副剂是模板化的工作，而不是绿地工程。 第15副剂在结构上与第一种完全相同。
知识文件在亚剂执行时按要求加载，而不是嵌入在管弦乐器中。 我们维护按工作流程域排列的25+知识文件。 当更新一个知识文件时，下一个会话会自动使用最新的版本——不需要管弦乐器更改。 同样的知识文件服务于我们agent的多个平台执行。
结果
一个新列的配置准备需要三到四天的人工操作，还有大约一天的时间来使用我们早期的配置驱动系统。 薄的管弦乐系统在一个小时之内完成。
大约三分之二的系统改变土地，它的到来是通过交换广域知识，一个刻意的建筑选择。 管弦乐团是一般的；副剂是专家的。
为什么这能奏效(为什么重量级的兽医不起作用)
传统的方法是使管弦乐团成为最聪明的组成部分——给它所有上下文，让它有理由知道该做什么以及如何去做。 这在它不起作用之前是可行的，它在最需要它的时候就停止了。 在规模上，有复杂的多步骤工作流程，跨越不同的子系统。
薄的管弦乐手之所以工作，是因为它使建筑边界与计算边界相一致：
- 决断性的决定是决定性的 “哪个子代理人处理此事？” 是一项路线决定，而不是一项推理任务。 不要用LLM来做。
- 环境隔离防止交叉污染。 数据源A的人口agent从未看到数据源B的模式。 这不可能是错的。
- 失败被控制。 如果副剂失效，管弦乐团会重复或升级。 失败不会破坏管弦乐家的状态或其他子代理人的背景。
- 系统在每一层独立改进。 一个更好的模型可以同时改进所有14个副剂。 知识文件更新立即生效。 新工作流程模板解锁新能力而不触摸agents. 没有单一的部件具有全部重量。
如何应用到您的 AI Agents
这种模式并非专门针对数据管道。 任何团队建筑生产AI agents都可以受益：
- 把路线和推理分开如果你的管弦乐手在做领域决定，征途应当确定：关键词匹配，意向分类，野外集合。 将所有域推理推进到孤立的子剂中。
- 设计副剂作为结构统一专家。 每个副代理人应具有相同的结构：知识源，所需投入，执行步骤，错误处理。 这使得增加了新的能力模板化的工作，而不是结构变化。
- 使用工作流程模板，而不是新的agents，以扩大规模。 当您需要新的使用大小写时，首先询问：我能用不同的顺序排序现有的 agents吗？如果您无法跨工作流程重复使用 agents，您的 agents 与特定使用案例过于搭配。
- 在运行时装入知识，而不是在建设时装入知识。 将知识嵌入管弦乐器，每次更新都需要重新部署。 按要求上载，更新立即生效，遍及所有平台。
- 明确划定决定因素/概率边界。 对于每个部分，请决定：这是一条路线决定(决定)还是一条推理任务(概率)？管弦乐器应位于一边，副剂应位于另一边。 别把它们混为一谈。
对细管弦乐器最强的论据是替代的失败模式。 当一个重量级的管弦乐手产生幻觉时，错误会蔓延到下游的一切：它会沿着错误的agent，收集错误的字段，或者跳过可靠性检查。 因为它的路线和可靠性步骤并不依赖于LLM推理。 它遵循固定的协议。 创造力发生在下游，在孤立的、有域范围的环境中，其中将幻觉风险降至最低，并控制故障。
接下来是什么
我们正在扩大这个架构，组成论预测这将奏效，因为缩放意味着添加工作流程模板和知识文件，而不是重建agents. 我们也在探索系统如何从生产使用中不断改进，使用自动反馈循环来识别故障模式
反直觉的教训：我们AI agent系统中最重要的组成部分就是最不起作用的。 保持你的管弦乐手和专家的深度，整个系统变得更加可靠。
鸣谢
这项工作是一项团队努力。 参与这项工作的其他一些人包括：马尼·布尚、拉胡尔·马利阿克卡尔、贾伊哈、查克拉帕尼·库马尔、维韦克·蒂瓦里和阿曼达·殷。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
- Sometimes, giving an AI agent all of the knowledge it needs is the wrong approach.
- At Meta, we’ve seen notable improvements in efficiency and accuracy by keeping the orchestration layer of our data pipeline agents deliberately thin: It routes work and enforces reliability checks, while specialized agents do the domain reasoning.
- We’re sharing our own process and insights, plus how any team can apply this to their production AI agents.
We built a 1,300-line orchestrator that routes 20+ workflows to 14 specialized AI agents. It performs zero domain work itself. That’s the point.
When we first deployed AI agents to automate data column onboarding across Meta’s recommendation systems — a process spanning three code repositories, three programming languages, and up to six pipeline stages that must stay in sync — we did what most teams do: We built one smart agent that knew everything.
It worked in demos. In production, it started hallucinating.
The fix wasn’t better prompts or a bigger context window. It was giving the central agent less to do. We call this the thin orchestrator pattern: a router that owns sequencing and reliability checks, and leaves every domain decision to specialists.
The Problem: More Context, Worse Results
Our pipeline is config-as-code: Python configurations drive C++ code generation, which feeds data processing services, which populate analytics systems. Onboarding a single data column requires coordinated changes across configuration registries, backend services, and data pipelines, and each column moves through up to six stages before its data arrives.
Our first approach was a single AI agent loaded with all domain knowledge, configuration schemas, code generation rules, pipeline routing logic, validation requirements, and population patterns for 10+ data sources.
The agent had everything it needed. That was 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% accuracy at 80-task batches where single agents fell to 16.6%, while reducing token usage up to 65-fold. The authors attribute this to the design’s isolation of tasks, which prevented context interference. We were experiencing the inverse, a single agent drowning in its own knowledge.
We also evaluated an alternative single-agent approach. Its success rate was 70-80% 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-20%. This wasn’t a prompt engineering problem. It was an architectural one.
The Approach: A Thin Router With Specialist Workers
We split the system into two layers:
- A deterministic orchestrator that performs zero domain work. It 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’s a router.
- Fourteen specialized subagents, each a complete domain expert with isolated context. A schema management agent knows configuration registries. A population agent knows how to generate code for each of 10 data sources. A validation agent knows build systems and quality checks. No agent sees the full picture. That’s the feature, not the bug.
The orchestrator follows a fixed 7-step protocol for every request:
- Read the relevant subagent’s instruction file.
- Check if the target already exists (prevent duplicates).
- 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 1–5 and 7 are deterministic. Only step 6 involves large language model (LLM) reasoning, and it happens inside an isolated subagent with only its domain knowledge loaded.
What We Built: Workflow Templates, Not New Agents
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’s decision space:
- Column Onboarding: Schema → Validation → Population → Testing
- Event Onboarding: Schema → Population → Validation → Testing → Event Processing
- Pipeline Migration: Assessment → Planning → Population → Validation → Monitoring
Each workflow template reuses the same pool of 14 subagents in different sequences. When we needed to support pipeline migration, a completely new use case, we didn’t build new agents. We wrote a new workflow template that sequenced existing agents differently. Zero new agent code. Full production capability.
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.
This uniformity means adding a new subagent is templated work, not greenfield engineering. The 15th subagent looks structurally identical to the first.
Knowledge files are loaded on demand at subagent execution time, not embedded in the orchestrator. We maintain 25+ 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 our agent.
Results
Configuration prep for a new column took three to four days by hand and about a day with our earlier config-driven system. The thin orchestrator system does it in under an hour.
For broader context: About two-thirds of the system’s changes land without significant human edits. It gets there by trading generality for deep domain knowledge, a deliberate architectural choice. The orchestrator is general; the subagents are specialists.
Why This Works (And Why Heavyweight Orchestrators Don’t)
The conventional approach is to make the orchestrator the smartest component — give it all the context and let it reason about what to do and how to do it. This works until it doesn’t, and it stops working exactly when you need it most — at scale, with complex multi-step workflows, across heterogeneous subsystems.
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. Don’t use an LLM for it.
- Context isolation prevents cross-contamination. The population agent for data source A never sees data source B’s patterns. It can’t hallucinate the wrong one.
- Failures are contained. If a subagent fails, the orchestrator retries or escalates. The failure doesn’t corrupt the orchestrator’s 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 to Apply This to Your AI Agents
This pattern isn’t specific to data pipelines. Any team building production AI agents can benefit:
- Separate routing from reasoning. If your orchestrator is making domain decisions, it’s 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 you need a new use case, first ask: Can I sequence existing agents differently? If you can’t reuse agents across workflows, your agents 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 it 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. Don’t mix them.
The strongest argument for a thin orchestrator is the failure mode of the alternative. When a heavyweight orchestrator hallucinates, the error spreads to everything 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 don’t 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.
What’s Next
We’re 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. We’re 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.
Acknowledgements
This work was a team effort. Some other people who contributed to this effort include: Mani Bhushan, Rahul Maliakkal, Jae Ha, Chakrapani Kumar, Vivek Tiwari, and Amanda Yin.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.