Multi-Agent Systems

If one agent (post #12) is a worker, a multi-agent system is a team. Instead of a single model looping on a whole task, you have several agents — each with its own role, context, and tools — coordinating to get something done.

The idea is intuitive: hard problems benefit from division of labor and multiple perspectives. But coordinating agents introduces real costs and failure modes, so the honest version of this post is as much "when not to" as "when to." Let's do both.

Why use more than one agent?

A few genuine reasons, each tied back to things we've already established:

1. Context isolation. Recall that the context window is the binding constraint for any single agent (post #12). One agent trying to hold an entire sprawling task in one window gets overwhelmed and loses coherence. Splitting the work means each agent keeps a clean, focused context with only what it needs.

   one agent:        [everything about the whole task crammed in one window]
                     → cluttered, distracted, runs out of room

   many agents:      [researcher: just sources]  [coder: just the code]
                     [reviewer: just the diff]
                     → each focused, each with room to think

2. Specialization. Different sub-tasks want different setups — different system prompts, tools, even different models (a cheap fast model for simple steps, a strong one for hard reasoning, per post #8). A specialized agent with a tight, purpose-built prompt often beats a generalist trying to do everything.

3. Parallelism. Independent sub-tasks can run at the same time. If you need to research ten sources, ten agents reading one source each finish far faster than one agent reading all ten in sequence.

4. Multiple perspectives. For judgment-heavy work, independent agents can check each other — one proposes, another critiques, a third verifies. This adversarial or ensemble structure catches mistakes a single pass would ship (it's the reflection idea from post #12, scaled across agents).

Common patterns

A handful of arrangements cover most real systems.

Orchestrator–worker (manager–subagent). A lead agent breaks the goal into subtasks, hands each to a worker agent, and synthesizes their results. The most common and most flexible pattern.

Pipeline. Agents in a fixed sequence, each transforming the previous one's output — research → outline → draft → edit. Good when the stages are well-defined and ordered.

Debate / review. Agents with opposing or complementary roles interact to improve quality — a generator and a critic, or several solvers whose answers get voted on. Good for correctness-critical work where a second opinion pays off.

The orchestration problem

Coordinating agents raises questions a single agent never faces, and these are where multi-agent systems get hard:

• How do agents communicate? Usually one agent's text output becomes part of another's input context. But the orchestrator can't dump a worker's entire raw transcript into its own context — it'd blow the window (post #12 again). So workers must return concise, structured summaries, and designing those handoffs is most of the work.
• Who decides what's done? Something has to judge when a subtask is complete and when the whole goal is met. Usually the orchestrator, but it has to trust (and sometimes verify) the workers' reports.
• How do errors propagate? If a worker quietly fails or hallucinates, the orchestrator may build on a bad result. Error compounding (post #12) gets worse with more agents, not better, unless you add verification.
• How do you control cost? This is the big one.

The cost reality

Be clear-eyed: multi-agent systems can be dramatically more expensive than a single agent. Every agent is a full series of model calls (post #6), each re-sending its context every step (post #10). A system with an orchestrator and five workers, each looping many times, can burn an order of magnitude more tokens — and money — than one agent on the same task.

   single agent:    ~N model calls
   5-worker system: orchestrator calls + 5 × (worker calls) + synthesis
                    → easily 5–15× the tokens

That cost is justified when the task genuinely parallelizes or when multiple perspectives materially improve the result — deep research, large-scale code changes, anything where breadth or cross-checking is the point. It is not justified for tasks a single well-designed agent handles fine. A common, expensive mistake is reaching for a swarm of agents when one good agent with the right tools would do.

When multi-agent shines (and when it doesn't)

Good fit:

• Tasks that decompose into independent parallel pieces (research many sources, audit many files).
• Work that benefits from separation of concerns (one agent writes, another reviews).
• Problems where multiple independent attempts and a vote/synthesis beat a single attempt.

Poor fit:

• Tightly sequential tasks where each step depends fully on the last — the coordination overhead buys you nothing.
• Simple tasks a single agent handles well — you're paying multiples for no gain.
• Anything where the agents would mostly just pass a giant shared context around — the handoff overhead and context bloat outweigh the benefits.

The takeaway

Multi-agent systems coordinate several specialized agents — via orchestrators, pipelines, or debate — to exploit context isolation, specialization, parallelism, and multiple perspectives. They shine on wide, decomposable, or correctness-critical work and waste money on simple or strictly sequential tasks. The hard parts are communication between agents, deciding when work is done, and keeping both errors and costs from compounding.

We've now built the whole stack, from tokens to teams of agents. Two big questions remain. First: how do we keep all of this grounded in real, current, trustworthy information rather than the model's frozen, fallible memory? That's retrieval.