One Agent or Fifteen? The Real Guide to Multi-Agent System Architecture

Split into multiple agents only when one agent provably can't hold the task — when the work breaks into independent sub-tasks that each need their own context window, their own tools, and can run in parallel without stepping on each other. The canonical shape is orchestrator-worker (a "supervisor" agent that plans and delegates, plus subagents that each explore one branch). Everything else — agents that hand a task back and forth one message at a time, "teams" that share a single chat — is usually theater. In June 2026, Anthropic reported a multi-agent research system beating a single agent by 90.2% on their internal eval, but at roughly 15× the token cost. Cognition (the Devin team) published the opposite advice — "Don't Build Multi-Agents" — because parallel agents make conflicting decisions when they don't share context. Both are right. The real skill isn't wiring up fifteen agents; it's knowing which jobs deserve more than one, and engineering the context they share. This guide is the architecture, the communication patterns, the memory layer, and the honest "when one agent wins" section.

why "multi-agent" became a marketing word

Open any agent demo from the last six months and you'll see a swarm: a "researcher," a "writer," a "critic," a "manager," all chatting in a group thread. It looks impressive. Then you put it in front of real traffic and it falls apart — the writer ignores what the researcher found, the critic contradicts the manager, and the whole thing burns tokens arguing with itself.

The community has a name for this gap: "deployed, not demoed." A multi-agent system that wins a screen recording is a different artifact from one that survives a week of production. The demo optimizes for looking autonomous. Production optimizes for being correct, cheap, and debuggable — three things that get harder, not easier, with every agent you add.

Here's the uncomfortable truth that both camps agree on: most "agents" in production are one model, one loop, a handful of tools. Adding agents multiplies your failure surface — more context to keep in sync, more places for a hand-off to drop information, more token cost per task. You only earn that complexity back when the task genuinely parallelizes. So before any architecture, the real question is whether you need a second agent at all.

the one decision that actually matters: split or stay single

There's a single test for going multi-agent, and it's not "is the task complex." It's: does the work decompose into sub-tasks that are independent enough to run in parallel, each needing a different context?

Research — "find everything about X across 30 sources" — is the textbook multi-agent fit: you can fan out, explore independent leads in parallel, and merge. Coding is the textbook anti-fit: every edit depends on the last one, so parallel coding agents step on each other. That's exactly why Anthropic chose multi-agent for research while Cognition argues against it for coding agents like Devin. Same year, opposite advice, and neither is wrong — they're describing different task shapes.

If your task looks more like coding (tightly coupled, sequential), stop here and build one good agent. If it looks like research (parallel, independent), read on.

the supervisor pattern, the one that survives production

The pattern that actually ships is orchestrator-worker, also called the supervisor pattern. One lead agent owns the plan; it spawns subagents, each with its own context window and tools, to work independent branches in parallel; the subagents return condensed findings; the lead reconciles them into one answer.

                 ┌────────────────────────┐
   user query →  │   LEAD / ORCHESTRATOR  │  plans, decomposes, delegates
                 └───────────┬────────────┘
            ┌────────────────┼────────────────┐
            ▼                ▼                 ▼
      ┌──────────┐    ┌──────────┐      ┌──────────┐
      │ subagent │    │ subagent │      │ subagent │   own context window,
      │  (web)   │    │  (docs)  │      │  (code)  │   own tools, run in parallel
      └────┬─────┘    └────┬─────┘      └────┬─────┘
           └───── condensed findings ────────┘
                           ▼
                 ┌────────────────────────┐
                 │   LEAD reconciles →     │  final answer + citations
                 └────────────────────────┘

Why this shape and not a free-for-all group chat? Three reasons:

• Each subagent gets a clean, focused context. It isn't drowning in the other agents' chatter — it sees its branch and its tools. This is the single biggest lever on quality.
• Parallelism is real. Independent branches run at the same time, so wall-clock time drops even as total token cost rises.
• One writer, one source of truth. The lead is the only thing that assembles the final answer. No two agents fight over the output.

In a minimal form, the lead is just an agent whose "tools" are other agents:

# Pseudocode — the supervisor loop, framework-agnostic
def lead_agent(query):
    plan = llm_plan(query)                  # decompose into independent subtasks
    results = run_parallel([                 # fan out — each gets its own context
        subagent(task=t, tools=tools_for(t))
        for t in plan.subtasks
    ])
    return llm_synthesize(query, results)    # one writer reconciles everything

The numbers, and the catch. Anthropic reported their orchestrator-worker research system (a Claude Opus 4 lead directing Claude Sonnet 4 subagents) outperformed single-agent Opus 4 by 90.2% on their internal research eval. They also found that token usage alone explained about 80% of the performance variance — most of the win is simply that more agents let you spend more tokens, in parallel, across more context. The catch: it cost roughly 15× the tokens of a normal chat. That economics only makes sense for high-value tasks where being thorough is worth real money. Don't put a 15× multiplier on "summarize this email."

how agents actually talk to each other

This is where most multi-agent systems quietly fail. The naive design has agents pass each other one chat message at a time — agent A sends agent B a sentence, B replies a sentence. It feels natural and it's a trap. By the time information has been compressed into a one-line hand-off three times, the original intent is gone, and two agents are now confidently acting on different versions of the truth.

Cognition's hard-won rules from building Devin cut straight to this:

• Share context, and share full agent traces — not just the final message. A subagent should see the reasoning that led to its task, not a stripped one-liner. Dropped context is the #1 cause of conflicting decisions.
• Keep writes single-threaded. Multiple agents reading is fine; multiple agents writing to the same state in parallel is how you get incoherent output. Let extra agents add intelligence (analysis, options), but route the actual actions through one writer. This is the "single writer" principle, and it's why the supervisor — not a peer group chat — is the durable pattern.

So in practice, agents don't really "converse." The lead hands each subagent a rich, self-contained brief (the goal, the relevant trace, the tools, the boundaries). Subagents don't talk to each other at all — they report back up. Less conversation, more delegation. The most reliable multi-agent systems look less like a meeting and more like a manager handing out sealed assignments.

shared memory as a filesystem, not a chat log

Once you have multiple agents, "where does the shared knowledge live?" becomes an architecture question. Stuffing everything into one giant prompt doesn't scale — you blow the context window and bury the signal. The pattern gaining ground in 2026 is to treat agent memory like a filesystem.

OpenViking (open-sourced by ByteDance's Volcano Engine team, ~15K★) is the clearest example. It exposes context — memory, resources, skills — under a viking://{scope}/{path} URI scheme that agents browse with familiar verbs like ls and find. The key idea is tiered loading: every piece of context is stored at three levels of detail.

An agent browses L0 abstracts to find what's relevant, reads L1 for the ones that matter, and only pulls the full L2 when it actually needs the detail — addressed by URI, like opening a file. That's how you give a team of agents a shared, large knowledge base without forcing every agent to carry all of it in-context. It maps cleanly onto the supervisor pattern: subagents write condensed findings to the store; the lead reads the abstracts and drills in only where it must.

The takeaway isn't "use this exact library." It's the principle: shared agent memory should be addressable and progressively loadable, not a single ever-growing transcript every agent has to re-read.

the under-discussed key: a curator that manages signal-to-noise

Here's the insight most "add more agents" advice misses. The bottleneck in agent systems usually isn't context capacity — it's context quality. Long-horizon tasks accumulate noise from verbose tool outputs and environment dumps, and the model gets "lost in the middle." Adding agents without managing that noise just gives you more agents drowning in junk.

The fix is a curation sub-agent — a small, cheap model whose only job is to prune noise and keep the reasoning anchors before the expensive model sees the context. The 2026 research paper "Escaping the Context Bottleneck: Active Context Curation for LLM Agents via Reinforcement Learning" (the ContextCurator approach) pairs a frozen, powerful TaskExecutor with a lightweight policy model trained via RL to aggressively prune environmental noise while preserving the sparse facts that matter downstream. The results:

A 7B curator (built on Qwen-2.5-7B) held its own against using gpt-4o as the curator — you don't need a frontier model to do the pruning. This is the architectural move that's still under-discussed: in a multi-agent system, one of your most valuable "agents" isn't a domain expert at all — it's a cheap gatekeeper that decides what the expensive agents are allowed to see. Better signal-to-noise beats more agents almost every time.

when one agent plus good tools just wins

Most of the time, you don't need any of the above. A single agent with a well-designed tool belt beats a swarm on cost, latency, and debuggability. Reach for one agent when:

• The task is sequential. Each step depends on the last (coding, multi-step transactions, anything stateful). Parallel agents would just step on each other.
• It fits in one context. If the whole job fits comfortably in one window, splitting it adds coordination overhead for no gain.
• Latency or cost is tight. One agent is one set of token bills and no cross-agent round-trips.
• You need to debug it. One loop, one trace. A swarm's failure is "somewhere in the message routing," which is a miserable place to live at 3 AM.

The honest move that's more on-trend in 2026, not less: there's a real backlash against over-engineered agent systems — teams quietly ripping the AI swarm back out and shipping one solid agent. Going multi-agent is a capability, not a status symbol. If a single agent with three good tools does the job, that is the senior decision. (If you're still choosing the agent layer itself, see my framework comparison; if you've never built the basic loop, start with your first agent in pure Python.)

five ways multi-agent systems break (and the fix)

• Pitfall: a peer group chat instead of a supervisor. Agents converse as equals and make conflicting decisions. Fix: orchestrator-worker. One lead plans and reconciles; subagents only report up.
• Pitfall: thin hand-offs. Passing one-line messages strips the context, so the next agent acts on a guess. Fix: share full traces and self-contained briefs, not summaries (Cognition's rule).
• Pitfall: parallel writers. Two agents mutate the same state and you get incoherent output. Fix: single-threaded writes — extra agents add intelligence, one writer commits actions.
• Pitfall: context as one giant transcript. Every agent re-reads everything and the signal drowns. Fix: addressable, tiered memory (OpenViking-style L0/L1/L2) and a curation sub-agent.
• Pitfall: multi-agent for a single-agent job. You pay ~15× tokens to make a coupled task worse. Fix: apply the split test honestly; default to one agent until it provably can't hold the task.

how I actually run agents in production

My default is not a swarm. Most jobs I ship are one agent, a tight set of tools, and good observability around it. I only reach for multi-agent when a task genuinely fans out — research, broad data gathering, anything where independent branches explore in parallel — and even then it's strict orchestrator-worker: one lead that plans and synthesizes, stateless subagents that each get a sealed brief and report back. Shared state lives in an addressable store, not in a 200K-token prompt every agent re-reads. A cheap model curates tool output before the expensive model ever sees it. And every agent — single or sub — runs sandboxed, because every tool an agent can call is an attack surface (security checklist here), with full tracing so a 3 AM failure has a place to look (monitoring here). The architecture is boring on purpose. Boring is what survives production.

what's next — and when to walk away

If you're about to build a multi-agent system, run the split test first. Sequential, coupled, fits-in-one-window? Build one excellent agent and walk away from the swarm — that's the senior call. Genuinely parallel and context-hungry? Use orchestrator-worker, share full context down, keep writes single-threaded, make memory addressable, and put a cheap curator in front of your expensive model. Then budget for the token bill before you commit, because thorough is worth 15× only when the task is.

Sources

1. Anthropic — "How we built our multi-agent research system" — orchestrator-worker architecture, the 90.2% improvement over single-agent, the ~15× token cost, and token usage explaining ~80% of performance variance. https://www.anthropic.com/engineering/built-multi-agent-research-system Retrieved June 16, 2026.

2. Cognition — "Don't Build Multi-Agents" (Walden Yan) — the "share full traces" and single-threaded-writes ("single writer") principles, and the case against parallel agents for coupled tasks. https://cognition.ai/blog/dont-build-multi-agents Retrieved June 16, 2026.

3. OpenViking (ByteDance / Volcano Engine), GitHub — the viking:// URI scheme and the L0/L1/L2 tiered context-loading model for shared agent memory. https://github.com/volcengine/OpenViking Retrieved June 16, 2026.

4. "Escaping the Context Bottleneck: Active Context Curation for LLM Agents via Reinforcement Learning" (arXiv 2604.11462) — the ContextCurator/TaskExecutor split, WebArena and DeepSearch numbers, and the 7B-vs-gpt-4o curator result. https://arxiv.org/abs/2604.11462 Retrieved June 16, 2026.

Designing a multi-agent system — or trying to figure out whether you even need one? Start a project — I architect and build AI agents, MCP servers, and agentic systems that run on your own server, with the right number of agents: not a demo, the version that survives production.