- Meta Engineering says its AI agents became more reliable once the coordinating layer stopped reasoning and only routed work and ran checks.
- The lesson is to decide which steps must be predictable and which can use AI judgment. The results are Meta's own, from one pipeline.
- Before funding agent projects, ask which decisions are fixed rules, which are left to a model, and what a wrong answer can reach.
Most teams building an AI agent start by making it the smartest thing in the room. They load it with all the domain knowledge: schemas, rules and patterns. Meta Engineering says that approach has a limit. In a post published October 19, its engineers describe how an agent that knew everything started to hallucinate in production.
When knowing more made the agent worse
Meta's team was automating the onboarding of data columns across its recommendation systems. Adding one column touches code in three repositories written in three languages. The column then moves through as many as six pipeline stages that must agree with each other. Their first design was one agent loaded with all the domain knowledge.
It worked in demos. In production, the engineers say, performance got worse past a certain amount of context. The agent mixed up concepts. It applied naming conventions from one subsystem to another. It used a code pattern meant for one data source on a different one.
Meta also tried a second single-agent approach. Its success rate was 70 to 80 percent when an engineer wrote a custom prompt for each task. Without that help, it fell to 10 to 20 percent. The team concluded this was an architecture problem, not a prompting problem.
How the thin orchestrator works
The orchestrator is the part that receives a request and decides who handles it. Meta's is about 1,300 lines long. It routes more than 20 workflows to 14 specialist agents and does no domain work itself. It does not write code or touch the codebase.
It follows a fixed protocol for every request. It reads the right specialist's instructions, checks whether the target already exists, fills in what it can infer, and checks for active warnings or required reviewers. Then it hands the job to a specialist and reports the result. Meta says only one step in that protocol uses a large language model, and it runs inside an isolated specialist.
Each specialist sees only its own slice of knowledge. A population agent for one data source never sees another source's patterns, so it has no way to pick up the wrong one. Meta treats this narrow view as a deliberate design choice.
Workflows are written as templates, which are fixed sequences of specialists. Column onboarding runs schema, validation, population, then testing. Pipeline migration reuses the same pool of agents in a different order. Meta says supporting migration needed a new template and no new agent code. Knowledge lives in more than 25 files loaded when a specialist runs, so an update takes effect in the next session.
The idea: decide what may be uncertain
This shows a different way to think about agent risk. The question is less how smart the agent is than which decisions are allowed to be probabilistic. Choosing who handles a request is routing, not reasoning. Meta's rule is not to spend a language model on it.
The reason is containment. Meta's engineers see the central coordinator as the point where an error has the widest reach. If it errs, it can send work to the wrong specialist, gather the wrong inputs or skip a reliability check. Steps after it then build on that error. A fixed router moves the uncertainty out to the edges, where a failure stays inside one specialist.
Think of a hospital switchboard. It works because it sends the call to the right department, not because it can treat patients. Meta has built that principle into software.
What the numbers show, and what they do not
Preparing the configuration for a new column once took an engineer three to four days by hand. Meta says its earlier system, driven by configuration files, cut that to about a day. The thin orchestrator does it in under an hour. About two-thirds of the system's changes land without significant human edits.
These are Meta's own figures from one internal pipeline. The post does not describe an independent measurement. The two-thirds figure also means roughly one-third of changes still need significant human edits.
Meta points to outside work that points the same way, a preprint from Mount Sinai. Its authors tested coordinated multi-agent systems against single agents. With 80 tasks per batch, the coordinated systems held 65.3 percent accuracy. Single agents dropped to 16.6 percent. Token use fell by as much as 65 times. The authors credit the separation of tasks, which kept context from interfering. These are the preprint's results, not Meta's.
Questions to put to your team
If your company is funding agents, ask for a map before a demo. Which steps are fixed rules, and which are left to a model's judgment? Does the coordinating layer make domain decisions it should not?
Ask what each specialist can see. If one agent holds everything, a single wrong inference can carry into every system it touches. Ask what happens when a step fails. Meta says its orchestrator retries or escalates, and its improvement plans keep human review as the gate for changes.
Ask whether a new use case needs a new agent or a new sequence of existing ones. If every request means new agent code, the agents may be too tightly tied to single jobs.
Meta's engineers land on a paradox: the component that does the least work is the one the system leans on most. For leaders, the practical version is simple. Put the intelligence where errors are easy to contain, and keep the junction boring.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Meta Engineering.
