Single-agent AI systems have clear limits: context window constraints, the difficulty of parallelising work, and the challenge of maintaining coherent long-horizon planning. Multi-agent systems — where multiple AI models collaborate, each with specialised roles — address these limits but introduce new complexity. Understanding the trade-offs is essential before building one.
Why Multi-Agent Systems
Context window limits: a single model can only hold a limited amount of information in active context (200k tokens for Claude, meaning roughly 150,000 words). Long tasks — auditing a large codebase, writing a book, running a multi-day research project — exceed these limits. Multi-agent systems can split work across agents, each operating within their own context. Parallelisation: a single agent executes sequentially. If a task has independent sub-tasks (research 5 different topics; process 100 documents), spawning parallel agents reduces wall-clock time dramatically — each agent works simultaneously. Specialisation: different agents can be optimised for different tasks — a code reviewer, a documentation writer, a security auditor — each with specialised system prompts and tool access, without compromising the other’s performance by mixing their focus. Error checking and verification: a second agent reviewing the first agent’s output catches mistakes that are invisible to the agent that made them (the blind spot problem). This is one of the most valuable applications of multi-agent systems in production. The orchestrator-worker pattern: the most common multi-agent architecture. An orchestrator agent (sometimes called a planner or router) decomposes a high-level task into sub-tasks and delegates them to worker agents, then aggregates results. The orchestrator maintains the high-level state; workers operate in narrow scopes. The key design decisions: what the orchestrator knows vs. what workers know; how workers report back; whether workers can spawn sub-workers; how errors propagate.
Design Patterns and Practical Considerations
The pipeline pattern: agents are chained sequentially — Agent A’s output becomes Agent B’s input. Each agent does one step in a transformation chain (extract → classify → summarise → format). Simple to implement and debug; limited parallelism. The peer review pattern: Agent A produces a result; Agent B reviews it; Agent A revises based on the review. Significantly improves output quality for writing, code, and analysis tasks. The debate pattern (adversarial): Agent A produces an argument; Agent B argues against it; a judge agent evaluates both and produces a final answer. Research shows this improves accuracy for factual tasks where the answer is uncertain. Tool assignment: multi-agent systems should give each agent only the tools it needs for its role (principle of least privilege). An agent that searches the web does not need database write access. This limits the blast radius of agent errors. State management: the hardest problem in multi-agent systems. Options: shared memory (a common store all agents read/write — simple but creates race conditions and consistency problems); message passing (agents communicate via explicit messages with a coordinator — safer but more complex to implement); conversation history (each agent maintains its own context, receives only what it needs — the cleanest approach for stateless tasks). Failure modes: agents can get stuck in loops; agents can hallucinate tool calls; agent coordination overhead can exceed the benefit (if the sub-tasks are actually correlated or sequential, orchestration adds latency without parallelism benefit). The cost: multi-agent systems use more tokens than single-agent systems — each agent invocation is a separate API call. Benchmark your system’s token usage before scaling.
