Multi-agent Systems

Anti-pattern: 80% of "multi-agent" is single agent with extra ceremony

Background & mechanics

Cognition's Don't Build Multi-Agents (June 2025) nails the anti-pattern. Core claim: multi-agent failure isn't that agents aren't smart enough — it's that they can't see each other. One subagent decides "refactor this file first, then add the feature"; a concurrent subagent decides "just add the feature without touching structure". Both are internally consistent. At merge time they collide, and the orchestrator can neither judge which is better nor roll back. This implicit decision conflict is the hardest multi-agent failure mode to treat because there's no error, no stack trace — just a result that "looks weird but runs".

Cognition's two engineering principles: (1) Share full context, not summaries — every subagent must see the entire trace (the orchestrator's goal, what other agents have done). Summarization is lossy compression and almost always loses something critical. (2) Actions carry implicit decisions — every tool call implies a judgment ("I chose this path, not the other"). When concurrent agents each make implicit decisions without a negotiation channel, coding/planning/anything-where-each-step-depends-on-the-last is strictly better with a single agent.

This doesn't contradict Anthropic's Research system — their task structure is the opposite: parallel retrieval across 100 web pages, then orchestrator aggregation. Subagents are independent by construction, so the implicit decision conflict problem doesn't apply. Which means the first question when deciding multi-agent isn't "is this task complex?" — it's "do subtasks share implicit state?"

Another often-overlooked anti-pattern: splitting one agent's prompt across multiple agents to "reduce complexity" — the typical example being a "PM agent + Engineer agent + Reviewer agent" sequential pipeline. This split almost never improves quality — it just relocates prompt-engineering complexity from one system prompt to three inter-agent message formats. Papers like MetaGPT (encoding SOPs as agent roles) show what's possible, but require tuning each role's prompt to production quality — which is itself 3× the work of single-agent, and inevitably introduces inter-agent message drift. Unless your product SOP is actually stable enough to encode as roles (rare), single agent is always the baseline.

Hands-on example

The ROI decision tree as 6 self-check questions — if ≥3 fail, multi-agent is over-engineering:

# multi_agent_check.py — sanity check before building
def should_use_multi_agent(task) -> str:
    checks = {
        "parallelizable":
            task.can_split_into_independent_subtasks,
        "low_implicit_state":
            not task.requires_step_n_depends_on_step_n_minus_1,
        "context_truly_overflows":
            task.estimated_tokens > 200_000,  # long-ctx really not enough
        "value_per_query_high":
            task.dollar_value_per_run >= 1.0,  # 15× token only justifies
        "subagent_output_verifiable":
            task.each_subagent_result_can_be_validated_independently,
        "single_agent_tried_and_failed":
            task.has_single_agent_baseline_with_eval_score,
    }
    failed = [k for k,v in checks.items() if not v]
    if len(failed) >= 3:
        return f"❌ Stay on single agent. Missing: {failed}"
    if "parallelizable" in failed or "low_implicit_state" in failed:
        return "❌ Task structure fights multi-agent. Use single agent + long ctx."
    return "✅ Good fit. Start with orchestrator-worker; budget 15× tokens."

Orchestrator-Worker: Anthropic's bet and its real cost

Background & mechanics

Anthropic's June 2025 post How we built our multi-agent research system spells out the pattern. Architecture: user query → Lead Agent (Opus 4) plans, decomposes, spawns N parallel Subagents (Sonnet 4) each researching a different direction → Lead aggregates all subagent findings → produces the final answer. Key numbers: on their internal research eval, this beat single-agent Opus 4 by 90.2%, while consuming about 15× chat token (a typical agent is ~4× chat).

Four engineering constraints that make it actually work:

• (1) Spawn criteria: the Lead can't spawn freely — it must be taught what subqueries deserve a subagent. Anthropic's lead prompt provides judgment criteria for breadth, complexity, parallel payoff. Counter-example: telling the lead "spawn whenever you can" → it spawns a subagent for every search term, token explodes with no quality gain.
• (2) Subagent prompt isolation: each subagent receives a prompt containing the task goal but NOT the work of other subagents — exactly opposite to Cognition's stance. Anthropic's design premise: subagents are already independent (different sub-directions), so cross-visibility would just inject confirmation bias. This design only works on truly parallel tasks; on sequential coding/refactoring it will collapse.
• (3) Aggregation strategy: the Lead doesn't simply concat subagent results — it does a second pass of reasoning: cross-validate, dedupe, surface contradictions, fill gaps. Anthropic stresses that using a stronger model (Opus) for aggregation is critical; a weak aggregator just averages 5 noisy signals into 1 noisy signal.
• (4) Concurrency cap: more subagents isn't better — beyond 5-10 the return curve flattens hard (extra agents just repeat angles already covered), while aggregation complexity rises with N. Anthropic doesn't publish exact numbers but implies 3-7 as the typical range.

How to read the 15× token cost? A chat turn = 1 LLM call; an ordinary agent ≈ 4× because of ReAct loops; multi-agent research ≈ 15× because the lead itself loops (~4×) + each subagent loops (~4×) × N concurrent subagents (~3-5) + aggregation. Which means every query must be worth > $1 to make ROI. Low-value generic tasks on multi-agent is just burning money; research, due diligence, cross-tool inquiry, deep SWE-bench — tasks where one result is worth real money — match.

Hands-on example

Minimal working orchestrator-worker (Anthropic SDK, pseudo-code — grasp the pattern, not the details):

import anthropic, asyncio, json

client = anthropic.AsyncAnthropic()

# ============ Subagent: independently researches one sub-direction ============
async def subagent(task: dict) -> dict:
    # NOTE: prompt only contains the sub-task, not other subagents' work
    msg = await client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=2000,
        system="You are a research subagent. Focus ONLY on the assigned "
               "sub-question. Use search tools. Return: findings + sources.",
        tools=[search_tool, fetch_tool],
        messages=[{"role":"user",
                   "content": f"Sub-question: {task['question']}\n"
                              f"Scope: {task['scope']}"}],
    )
    # tool loop omitted — actually loop until stop_reason='end_turn'
    return {"task": task, "findings": msg.content[0].text}

# ============ Lead Agent: plan + aggregate ============
async def lead_agent(user_query: str) -> str:
    # Step 1: planning — strong model decides whether to split, and how
    plan = await client.messages.create(
        model="claude-opus-4-7",
        max_tokens=1500,
        system="You are a research lead. Decide if this query benefits from "
               "parallel subagents. If YES, output JSON list of 3-7 INDEPENDENT "
               "sub-questions. If NO (task is sequential or simple), output "
               "{\"single\": true} and you'll handle it alone.",
        messages=[{"role":"user","content":user_query}],
    )
    spec = json.loads(plan.content[0].text)

    # Step 2a: doesn't fit splitting → fall back to single agent (most queries)
    if spec.get("single"):
        return await single_agent_run(user_query)

    # Step 2b: spawn subagents in parallel
    results = await asyncio.gather(*[subagent(t) for t in spec["tasks"]])

    # Step 3: aggregation — strong model again; cross-check, do not concat
    aggregation = await client.messages.create(
        model="claude-opus-4-7",
        max_tokens=4000,
        system="You are the research lead synthesizing N subagent reports. "
               "Cross-validate, identify contradictions, fill gaps. "
               "Output: comprehensive answer + confidence notes.",
        messages=[{"role":"user",
                   "content":f"Original query: {user_query}\n\n"
                             f"Subagent findings:\n{json.dumps(results, indent=2)}"}],
    )
    return aggregation.content[0].text

# ============ Cost guard: hard ceiling against runaway ============
# In prod: per-run budget + N_subagent <= 7 + timeout — mandatory

Debate / Cross-check: when multi-perspective actually improves quality

Background & mechanics

Du et al. 2023 (Improving Factuality and Reasoning in Language Models through Multiagent Debate, arXiv 2305.14325) is the paradigm's origin. Mechanism: N LLMs answer independently → each sees the others' answers + reasoning → multi-round iteration produces consensus. The paper showed significant gains over single-answer and self-consistency on MMLU, math, factual QA. The result remains robust in 2026 — when the task has a clear correct answer.

But debate fails in 3 settings:

• (1) Open subjective tasks — "write product copy", "evaluate this business plan" — no ground truth, agents converge on a "mutually acceptable mediocre answer", much worse than letting one agent generate freely and humans pick.
• (2) Same model + same prompt × N — "same-source diversity" is very weak; debate degenerates into self-consistency, and positive bias amplifies in sync (all agents tend toward yes-man, debate makes it worse). For debate to work, you must construct real diversity: Claude vs GPT vs Gemini, or same model but role-prompts strongly opposed ("you are the defender / you are the critic").
• (3) Long-form generation — debate fits "short answer with right/wrong" tasks. Asking agents to debate every paragraph of a 5000-word article almost always degenerates into mutual flattery or stalls.

A higher-ROI "multi-perspective" engineering pattern is asymmetric cross-check: use a different model / different prompt / dedicated verifier agent to audit the main agent's output. Example: main agent uses Claude Opus to write code → verifier agent uses GPT-5 to brainstorm test ideas + find edge cases. This "primary + auditor" structure is more robust in engineering than N-agent debate: clear ownership, controllable cost (2× not N×), independently attributable failures. Constitutional AI's self-review, self-refine, Reflexion are all variants of the same "primary + auditor" structure unfolded along different time dimensions.

One counter-intuitive finding: asking a model to "debate its own prior answer" (self-debate / self-reflection) often works worse than having another agent critique it. The Cognition-style backward rationalization problem: once a model has produced answer A, it tends to defend A and find supporting evidence, not to genuinely question. Self-debate often turns into self-confirmation. So cross-check > self-reflection in reliability terms — the real engineering sweet spot for multi-agent.

Hands-on example

Asymmetric cross-check pattern (primary + cross-vendor verifier) — 2× cost for meaningful quality gain:

import anthropic, openai

claude = anthropic.Anthropic()
gpt = openai.OpenAI()

def primary_solve(question: str) -> str:
    # Primary: Claude Opus answers
    msg = claude.messages.create(
        model="claude-opus-4-7", max_tokens=1500,
        messages=[{"role":"user","content":question}],
    )
    return msg.content[0].text

def cross_check(question: str, primary_answer: str) -> dict:
    # Verifier: cross-vendor + adversarial prompt
    # Key 1: different model (diversity)   Key 2: oppositional role
    prompt = f"""You are a SKEPTICAL reviewer. Your job is to find what is
WRONG with the candidate answer below. Do NOT defend it.

QUESTION: {question}

CANDIDATE ANSWER:
{primary_answer}

Output JSON:
{{"verdict": "correct"|"incorrect"|"uncertain",
  "issues": [],
  "missing": []}}"""
    rsp = gpt.chat.completions.create(
        model="gpt-5", temperature=0.2,
        messages=[{"role":"user","content":prompt}],
        response_format={"type":"json_object"},
    )
    return json.loads(rsp.choices[0].message.content)

def arbitrate(question, primary, review) -> str:
    # Only re-run when verifier finds issues — cost-controlled
    if review["verdict"] == "correct" and not review["issues"]:
        return primary
    # Let primary revise after seeing the critique (selective, not overwrite)
    revision = claude.messages.create(
        model="claude-opus-4-7", max_tokens=2000,
        messages=[
            {"role":"user","content":question},
            {"role":"assistant","content":primary},
            {"role":"user","content":
              f"A skeptical reviewer raised these issues:\n"
              f"{json.dumps(review, indent=2)}\n\n"
              f"Revise ONLY if the issues are valid. If you disagree, explain why."}],
    )
    return revision.content[0].text

# Usage
answer = primary_solve(question)
review = cross_check(question, answer)
final  = arbitrate(question, answer, review)
# Cost: ~2× single agent. Quality: +10-20pp on factual / code tasks

The coordination tax & protocols: A2A, MCP, and the cost of N²

Background & mechanics

The multi-agent "coordination tax" is the distributed-systems problem of old reborn for LLMs. Three key overheads:

• (1) Communication complexity — arbitrary inter-agent comms is O(N²) edges; each edge has message encoding, token cost, context sync overhead. Past 5-7 agents performance noticeably drops (each agent's context bloats with other agents' state).
• (2) Decision latency stacking — sequential agent pipelines stack latency (5 agents × 8s = 40s); parallel agents are bounded by the slowest subagent + aggregation latency (~1.5× single-agent). User-perceived latency is usually the biggest engineering pressure point pushing against multi-agent.
• (3) Failure attribution — single-agent failures are easy to locate (read the trace, find the wrong step). Multi-agent failure means answering "which agent at which step did what that led to the final error" — subagent traces + lead aggregation trace + cross-agent state, debug complexity explodes. Anthropic's engineering post admits this is the hardest engineering problem in multi-agent — they solve it via per-agent full traces + cross-trace correlation IDs.

April 2025 Google launched A2A (Agent-to-Agent) protocol, standardizing "agents from different frameworks and vendors discover each other, delegate tasks, and coordinate". Stack: HTTP + SSE + JSON-RPC 2.0. Each agent publishes an Agent Card (JSON describing its capabilities), client agent finds suitable targets via Cards, Task is the work-delegation abstraction. In June, Google donated A2A to the Linux Foundation; 150+ organizations now back it.

A2A vs MCP — division of labor is often muddled:

• MCP (Anthropic 2024): standardizes LLM agent ↔ tools/data sources. One agent calls GitHub, Slack, local files through an MCP server — a vertical connection (agent acquires capability).
• A2A (Google 2025): standardizes agent ↔ agent. One agent delegates a task to another agent through A2A — a horizontal connection (agents collaborate).
• Complementary, not exclusive: real systems typically use MCP for tools, A2A for other agents. Google's own framing: "A2A and MCP are complementary".

For independent developers: don't reach for protocols first. A 2-3-agent system with bare Python function calls + asyncio.gather takes a few hours. Adding A2A/MCP for general-purpose use adds serialization, network, and version-compat complexity. Protocols' value is in cross-org / cross-vendor / long-lived agent ecosystems — for one person's product with 3 internal agents, direct function calls are 10× simpler, 10× faster, 10× easier to debug than JSON-RPC over HTTP. When the system genuinely needs to expose internal agents externally or integrate third-party agents, migrate to A2A then.

Hands-on example

The most pragmatic "protocol-less" multi-agent template for indie devs (asyncio + shared trace):

import asyncio, uuid, time, json
from dataclasses import dataclass, field

# —— Shared trace: the debug lifeline of multi-agent ——
@dataclass
class SharedTrace:
    run_id: str = field(default_factory=lambda: str(uuid.uuid4()))
    events: list = field(default_factory=list)

    def log(self, agent: str, kind: str, payload: dict):
        self.events.append({
            "t": time.time(), "agent": agent,
            "kind": kind, "payload": payload,
        })

# —— Subagent: just an async function, no RPC ——
async def subagent(name: str, task: dict, trace: SharedTrace,
                   budget_tokens: int = 8000) -> dict:
    trace.log(name, "start", {"task": task})
    used = 0
    try:
        # LLM call + tool loop (omitted)
        result = await run_llm_loop(task, budget_tokens=budget_tokens)
        used = result["tokens_used"]
        trace.log(name, "done", {"tokens": used, "preview": result["text"][:200]})
        return result
    except Exception as e:
        trace.log(name, "error", {"err": str(e), "tokens": used})
        return {"failed": True, "reason": str(e)}

# —— Orchestrator: concurrent + budget + timeout, three layers of safety ——
async def orchestrate(user_query: str) -> dict:
    trace = SharedTrace()
    trace.log("lead", "query", {"query": user_query})

    plan = await lead_plan(user_query, trace)
    if len(plan["tasks"]) > 7:
        plan["tasks"] = plan["tasks"][:7]   # hard cap

    # 3 protections: per-agent budget / global timeout / failure isolation
    try:
        results = await asyncio.wait_for(
            asyncio.gather(*[
                subagent(f"sub-{i}", t, trace, budget_tokens=8000)
                for i, t in enumerate(plan["tasks"])
            ], return_exceptions=True),
            timeout=120,                 # 2 min global budget
        )
    except asyncio.TimeoutError:
        trace.log("lead", "timeout", {})
        results = [{"failed": True, "reason": "global timeout"}]

    # Aggregate over partial success (failure isolation)
    good = [r for r in results if not (isinstance(r,dict) and r.get("failed"))]
    final = await lead_aggregate(user_query, good, trace)

    # Persist trace: lifeline for debug + eval
    json.dump({"run_id":trace.run_id, "events":trace.events, "final":final},
              open(f"runs/{trace.run_id}.json","w"), ensure_ascii=False)
    return {"answer": final, "trace_id": trace.run_id}