The Thin Orchestrator Owns the State: When Multi-Agent Coordination Pays Off and When It Collapses
Multi-agent systems look elegant on architecture diagrams and expensive in production logs. A lead agent plans, subagents fan out, results merge, and the final answer looks smarter than any single model could produce. Then the bill arrives, the traces refuse to reconcile, and two agents have quietly made contradictory assumptions about the same artifact.
The 2025–2026 evidence is clearer than the hype. Anthropic’s multi-agent Research system outperformed a single Claude Opus 4 by 90.2% on their internal research evaluation. Cognition’s “Don’t Build Multi-Agents” argued the opposite for coding work, where parallel writers create conflicting implicit decisions. Both are correct once you look at the shape of the work rather than the number of agents.
Start with the dependency graph, not the agent count
Before you spin up a second agent, draw the work. Tasks fall into three rough shapes:
Independent parallel threads. Research across sources, document review, or analysis that does not edit a shared artifact. Subagents can run with isolated context windows and return compressed summaries. Anthropic’s Research feature works this way: a lead spawns 3–5 subagents that search in parallel, each using multiple tools inside its own context.
Sequential pipelines. Each step depends on the previous output. Coding, configuration generation, or any flow that mutates shared state. Parallel agents here tend to make implicit decisions that conflict. Cognition’s example is classic: one subagent builds a Flappy Bird background, another builds the bird, and neither knows the other’s assumptions.
Review or maker-checker loops. One agent drafts, another evaluates against explicit criteria, with a hard iteration cap and a human handoff. This is often the cheapest quality lever and does not require full peer-to-peer negotiation.
A simple rule from both camps: split only where the work splits naturally. If the subtasks are independent and the value of the result justifies roughly 15× chat-level token spend, multi-agent can pay. If steps are tightly coupled or writes must stay consistent, keep a single agent (or single writer) and give it skills or tools instead.
The thin orchestrator pattern
Meta’s Engineering team published a concrete production fix in October 2026. They had built a general agent that knew every domain for data-pipeline configuration work. In demos it worked. In production it started hallucinating and cross-contaminating concepts as context grew. Success fell to 10–20% without per-task prompt engineering.
Their fix was architectural, not prompt-level. They replaced the all-knowing agent with a 1,300-line thin orchestrator that performs zero domain work. It classifies intent, gathers required fields, runs reliability checks, and delegates. It never reasons about code, never generates configurations, and never touches the codebase. Fourteen specialist subagents each hold isolated domain knowledge. New use cases are added as workflow templates that resequence the same specialists rather than new agent code.
Measured result: configuration prep dropped from three to four days by hand (or roughly a day under an earlier system) to under an hour. Roughly two-thirds of changes landed without significant human edits.
Orchestrator owns: sequencing, admission, field completeness, reliability gates, audit trail, and the shared workspace.
Specialists own: domain reasoning inside bounded contexts.
Shared state lives outside any single prompt: plans, status, owners, blockers, dependencies, and final artifacts written to durable storage that every participant can read.
This matches the practical advice from several 2026 architecture reviews: keep the coordinator thin so it does not become a bottleneck or a source of silent drift. Reconciliation steps that check each handoff against the original brief catch the compounding errors that otherwise surface only at the end.
Shared workspace and durable handoffs
Passing full conversation history between agents is both expensive and lossy. Prefer a shared workspace that holds the current plan, intermediate artifacts, and explicit contracts for what each worker must return.
Practical fields for a handoff card between agents or between an agent and a human:
- Objective and success criteria — what “done” looks like for this slice.
- Inputs and provenance — links or IDs to source material, not summarized claims alone.
- Output contract — exact format, required fields, and what must not be changed.
- Tools and permissions — the narrow set this worker may call.
- Budget and stop conditions — token or dollar ceiling, max iterations, or confidence threshold that triggers escalation.
- Audit pointer — trace ID or workspace path so a later reviewer can reconstruct the path without re-running everything.
Writes stay single-threaded. Multiple agents can contribute analysis or review; one designated writer (or a deterministic merge step) produces the mutable artifact. This is the pattern Cognition later noted still holds for parallel-writer swarms while allowing multi-agent intelligence on read-heavy or review-heavy work.
Cost, failure modes, and gates
Anthropic measured multi-agent systems at roughly 15× the tokens of a normal chat and single agents at about 4×. Token usage alone explained 80% of performance variance on one benchmark. The economic rule is simple: only use the pattern when the task value covers the multiplier and when parallel exploration actually improves the outcome.
Common failure modes to instrument:
- Silent drift. Downstream agents treat upstream output as ground truth. Add a reconciliation check against the original brief at each major handoff.
- Context exhaustion relocated, not removed. Fan-out compresses worker outputs; chains accumulate errors. Monitor both.
- Orchestrator overflow. If the lead tries to do domain work, it starts hallucinating. Keep it thin.
- Loop or budget runaway. Enforce pre-call limits and a circuit-breaker path that surfaces to a human rather than letting the swarm continue.
- Conflicting implicit decisions. Especially on any shared mutable state. Prefer single-writer plus review.
A2A (Agent2Agent) protocol and MCP complement each other: A2A for agent-to-agent discovery and task delegation across process or team boundaries, MCP for tool access inside an agent. Both now sit under the Agentic AI Foundation, which reduces some of the earlier fragmentation.
A minimal production checklist
- Map the dependency graph. If most edges are sequential and tight, stay single-agent with skills.
- If parallel independent work exists and value justifies cost, introduce a thin orchestrator that owns state and sequencing only.
- Give each specialist an isolated context, an explicit output contract, and a narrow tool set.
4. Persist plan, status, and artifacts to a shared workspace with provenance.
5. Keep writes single-threaded; use maker-checker or human gates for quality.
- Enforce hard budgets, loop detection, and reconciliation checks before any side-effecting step.
- Evaluate on full trajectories and critical user journeys, not just final answers. Measure cost per successful outcome, not tokens alone.
Multi-agent coordination is not a default upgrade. It is a deliberate architectural choice that pays when the work is parallel, the orchestrator stays thin, and the shared state stays visible. Everything else is usually more expensive and harder to debug than a well-equipped single agent.
References & Community Insights
- Anthropic Engineering: How we built our multi-agent research system — https://www.anthropic.com/engineering/built-multi-agent-research-system
- Cognition: Don’t Build Multi-Agents — https://cognition.com/blog/dont-build-multi-agents
- Meta Engineering: The Thin Orchestrator — https://engineering.fb.com/2026/10/19/ml-applications/thin-orchestrator-ai-agent-architecture/
- AI Engineer talk with Anthropic on Flows:
- A2A samples and protocol: https://github.com/a2aproject/a2a-samples
- Recent practitioner notes on when single agents with skills outperform swarms (Anthropic Applied AI guidance, late 2026)
The pattern is not new in systems design. Thin routers, isolated specialists, and explicit contracts have kept distributed systems honest for decades. Agents simply make the cost of ignoring those constraints more visible, faster.
Want to implement this in your business?
Mapki designs bespoke AI agents, custom workflow automations, and tool-agnostic integrations tailored specifically to your existing ERP, CRM, and databases.
