Single-Agent vs Multi-Agent Architectures

The moment a single agent struggles, someone proposes five. Specialist agents sound clean on a whiteboard: researcher, writer, critic, executor. In production, every extra agent adds handoff latency, shared-state bugs, and a new way for the system to disagree with itself. Multi-agent architecture is a coordination tax. Pay it only when the tax buys something you cannot get from one strong loop with good tools.

The real reason to split#

Split when specialization or isolation is the constraint — not when the prompt feels crowded.

Good reasons:

• Different tool permissions — a billing agent may refund; a support agent may only read
• Different context corpora — legal retrieval should not share a window with marketing drafts
• Parallel work that is actually independent — fan-out document review across disjoint files
• Hard organizational boundaries — separate teams own separate runtimes and audit trails

Weak reasons:

• "The system prompt is getting long" (fix context assembly instead)
• "We want it to feel autonomous" (product theater)
• "The single agent failed once" (fix tools, bounds, or evals first)

One agent with tools vs many agents#

A single agent with a well-designed tool set will beat a loosely coupled swarm for most enterprise tasks. Multi-agent helps when workers must run with different policies or true concurrency, and when an orchestrator can merge results against an explicit contract.

Start with one. Promote a subtask to a worker only when you can name the permission, corpus, or latency reason that forced the split.

A thin orchestrator sketch#

from dataclasses import dataclass

@dataclass
class Subtask:
    name: str
    worker: str
    input: dict

def run_job(goal: str, planner, workers, merge):
    plan: list[Subtask] = planner.decompose(goal)
    results = {}
    for step in plan:
        worker = workers[step.worker]
        # each worker has its own tool allowlist and context packer
        results[step.name] = worker.run(step.input)
    return merge(goal, results)

The important part is not the planner. It is that workers[step.worker] carries its own allowlist and context. If every "agent" shares the same tools and the same prompt blob, you have renamed functions, not designed a multi-agent system.

Coordination failure modes#

• Duplicate side effects — two workers update the same ticket
• Contradictory drafts — merge step averages nonsense instead of choosing
• Ping-pong — critic and writer loop until the budget dies
• Opaque blame — no single trajectory explains the final action

Mitigations are boring and effective: single-writer rules per resource, idempotency keys, a merge schema, and a global step budget that includes worker steps.

Communication patterns that stay understandable#

Prefer orchestrator-workers with structured handoffs (JSON task specs in, JSON results out). Treat free-form agent chat as a debugging liability. If you need asynchronous fan-out, use a job queue your platform already understands, not an improvised message board inside the prompt.

Shared memory should be typed: working state for the job, not a scrapbook of every intermediate monologue. Summarize worker output before it re-enters the orchestrator window.

When one is enough#

If a single planner can call search, ticket APIs, and a calculator under one policy, keep one agent. Add a critique pass (second model call with a checklist) before you add a critique agent. A pass is an eval-friendly step. An agent is a new runtime citizen.

Shared state without a scrapbook#

Multi-agent systems tempt teams into a shared "blackboard" of free-form notes. That board becomes an untyped database nobody can invalidate. Prefer:

• A job document with known fields (status, artifacts, decisions)
• Per-worker private context that never leaks privileges
• Append-only event log for audit, summarized for model consumption

If worker B must see worker A's result, pass a structured artifact through the orchestrator. Do not grant B the same tool permissions "just in case."

Latency and cost reality#

Every handoff is at least one extra model call plus serialization. Parallel workers help only when subtasks are independent and the merge is cheap. Sequential specialist chains often lose to one agent with three tools on both wall-clock and quality — because each handoff drops nuance. Measure end-to-end task success and cost per success before celebrating the architecture diagram.

Org boundaries vs runtime boundaries#

Sometimes "multi-agent" is really "multi-team": payments owns refunds, support owns macros. That can justify separate services with separate allowlists even if a single logical orchestrator calls both. Do not confuse that with five LLM personas chatting. Separate deployables with contracts; keep the number of planning brains small.

Evaluating multi-agent vs single-agent#

Do not compare architectures on a whiteboard. Run the same task suite on both shapes with matched budgets: total model calls, total tokens, wall-clock time, and side-effect count. A multi-agent design that wins on a single cherry-picked demo but loses on cost per successful task is not winning.

Track these per variant:

• Task success rate on your golden set — not only final answer quality but whether required tools fired
• Handoff loss — does worker output drop fields the orchestrator needed?
• Duplicate work — two workers fetching the same document because neither saw the other's cache
• Blame clarity — can you point to one trajectory id and explain every write?

If single-agent with expanded tools matches multi-agent on success and beats it on latency, stop. If multi-agent wins only on parallel fan-out, confirm the merge step is tested — parallel speed is worthless when the merge invents a compromise nobody asked for.

A migration path from one to many#

Most teams should not design multi-agent on day one. A sane progression:

1. One agent, strict allowlist — prove the job class with evals
2. Critique pass — second model call, same runtime, structured checklist
3. Extract a worker — only when a subtask needs different permissions or corpus; keep the orchestrator thin
4. Parallel fan-out — only when subtasks are independent and merge is schema-defined

Document the trigger at each step. "We split legal review because the legal corpus must never appear in the support agent's context window" is a design decision. "We added Agent B because Agent A felt tired" is not.

When you do split, version the handoff schema like an API. Breaking changes to worker output shape should fail CI the same way a REST contract change would.

Summary#

Multi-agent systems pay for themselves when specialization, isolation, or true parallelism is required. They punish you when they are used as a substitute for clear tools, context budgets, and evals. Default to one bounded agent. Split only with a named constraint, typed handoffs, and a merge contract you can test.