Meta's thin orchestrator: a deterministic router with 14 specialist agents, decoded

Meta replaced a hallucinating do-everything agent with a 1,300-line deterministic router and 14 specialists. Here's how to copy the pattern at small scale.

Picture a platform engineer at a 40-person SaaS company. Over a couple of evenings she built an agent to handle "add a new tracked field" tickets. Each one touches a Python config, a generated TypeScript client and a warehouse model. She gave one agent everything: all three schemas, the naming rules for each repo and the validation steps. It demoed fine. A few weeks into real use, it starts putting the warehouse's naming convention into the TypeScript client, or reusing a pattern meant for one data source on another. Now she rewrites the system prompt for nearly every ticket to keep it on track.

Meta's engineers described that failure in a post on Engineering at Meta dated October 19, 2026. Their single "knows everything" agent for data column onboarding "worked in demos. In production, it started hallucinating." The fix wasn't a bigger context window. It was a 1,300-line orchestrator that "performs zero domain work," routing 20+ workflows to 14 specialist agents. This is an architecture pattern, not a product, and that is why it's useful: you can copy it at the size of your own project.

What it is

Meta's pipeline is config-as-code. Python configurations drive C++ code generation, which feeds data processing services, which populate analytics systems. Onboarding one column spans three repositories, three languages and up to six pipeline stages. The first agent carried all of it: schemas, codegen rules, routing logic, validation requirements and population patterns for 10+ data sources. Meta writes that past a certain context threshold, more knowledge made it worse, and the agent began "applying field naming conventions from one subsystem to another." Meta also tested a second single-agent approach. It reached 70–80% success only when an engineer wrote a custom system prompt for each job, and 10–20% without one.

The redesign, per Meta's post, has these parts. Each maps to a pain from the lede:

On results, Meta reports that configuration prep for a new column fell from three to four days by hand, and about a day with an earlier config-driven system, to under an hour. Meta also says about two-thirds of changes land without significant human edits. To support its diagnosis, Meta cites a Mount Sinai preprint: 65.3% accuracy for orchestrated multi-agent systems versus 16.6% for single agents at 80-task batches, with up to 65-fold lower token use. PPC Land notes it has not reviewed that preprint, so those figures are as Meta reports them. They are not Meta's own production measurements.

Alternatives, each described from its source:

Who it's for

Pick this up if your agent spans several distinct knowledge domains, such as separate repos, languages or data sources, and its mistakes look like one domain's rules bleeding into another. It also fits if the work is batch-style, where getting it right matters more than speed, and you already find yourself hand-tuning prompts per task.

Skip it if your agent does one job in one domain, or it's a short tool-calling loop. Skip it too if the work is latency-sensitive and user-facing, or if each step needs shared context with the others. DEV Community's analysis says the pattern does not fit "when workflows require tight coupling between steps."

Before and after

Before, with one fat agent:

  1. A ticket arrives, and one prompt holds every schema, rule and pattern.
  2. The model decides both what to do and how to do it, in one context.
  3. Output bleeds conventions across domains, so you patch the system prompt.
  4. When it fails, you read the model's reasoning to guess where it went wrong.
  5. A new use case means a longer prompt.

After, with a thin orchestrator:

  1. Plain code classifies the request and picks a workflow template.
  2. The router checks for duplicates, gathers required fields and infers what it can.
  3. A gate checks for warnings or required reviewers before any model call.
  4. One specialist runs with only its own knowledge files loaded.
  5. The router surfaces errors or confirms success. Per Meta, a failed subagent is retried or escalated without corrupting other contexts.
  6. A new use case usually means a new template that reuses existing specialists.

DEV Community makes a related point about debugging: with a thin router, you trace which agent produced the bad output instead of inspecting one model's reasoning about everything.

Try it

Meta has not published a ready-to-run package of this. FOSSWire's headline says Meta "open-sources" the pattern, but its text describes publishing the architecture, and the Meta post's text doesn't point to a repo. Treat a code release as unconfirmed. The smallest real step is to apply Meta's own checklist to an agent you already have:

  1. List every decision your agent makes. Mark each one as routing (deterministic) or reasoning (probabilistic). Move the routing ones into code.
  2. Write one workflow template as a fixed, ordered list of steps.
  3. Split out your first specialist using Meta's five-part structure: knowledge sources, pre-gathering checklist, step-by-step workflow, discovery patterns and troubleshooting.
  4. Move domain knowledge out of the prompt into files the specialist loads when it runs.

If you build the specialists on the Claude Agent SDK, Developers Digest gives these install commands. As of October 17, 2026 the current versions are 0.3.302 for TypeScript and 0.2.168 for Python:

# TypeScript
npm install @anthropic-ai/claude-agent-sdk
# Python
uv add claude-agent-sdk
# or
pip install claude-agent-sdk

It needs Node.js 18+ or Python 3.10+ and an ANTHROPIC_API_KEY or one of the cloud provider switches. The SDK does not load .env files itself. Our read, not a source's: to keep the router thin, call the SDK from your own deterministic routing code rather than letting the main Claude loop decide which subagent runs.

Where it breaks

Who picks this: anyone whose agent is failing because it knows too much across too many domains, and who can afford a few extra calls per run. Who skips it: single-domain agents, latency-critical paths, and teams without the time to write and maintain the knowledge files.

Sources