Why Multi-Agent Systems Work — A Field Note

A single context window asked to simultaneously act as editor, coder, critic, and retriever will, in the end, do all four — but never quite be any of them. The careful editor starts writing code snippets to clarify. The confident coder hedges with editorial disclaimers. The skeptic goes soft because it wrote the draft. The work happens; the seams show. A multi-agent system splits the work into roles, gives each role its own context, and forces clean handoffs. The result is not just faster. It is qualitatively more coherent.

The hard part is not the agents. It is the handoffs.

— closing observation

01 · Failure mode

One brain, four jobs, and the leakage between them

When a single context window must play four roles at once, the personas leak. Each role quietly bends the others. This is the failure the multi-agent pattern is designed to fix.

The unified brain

The one-context model

One system prompt, supposedly holding four personas in productive tension. In practice: a hybrid of editor, coder, critic, and retriever, each pulling the response in a different direction.

Role 01

Edit the prose

Starts writing code snippets to "clarify"

Role 02

Write the function

Adds hedges and disclaimers mid-function

Role 03

Critique the draft

Goes soft because it "wrote" the draft

Role 04

Retrieve the sources

Tries to sound like the editor again

Figure 1 The single-context failure. One window asked to hold four personas; each role bleeds into its neighbours. The output is technically correct and tonally incoherent.

02 · The pattern

An orchestrator and four specialists, each in their own context

The fix is structural. One orchestrator routes the work; each specialist runs in a clean context with a system prompt tuned for exactly one job. The seams between them become the handoff protocol — explicit, inspectable, and correctable.

A typical roster

Orchestrator

Routes · Sequences · Validates

Reads the goal, decomposes it, picks the right specialist for each subtask, stitches the results, decides when to ship. Holds no domain knowledge — only routing logic and the user-facing persona.

in user goal
out assembled result

Reasoner

Plans · Decomposes

Turns vague goals into explicit plans. Quiet, structured, no opinions about style.

Coder

Implements · Tests

Receives a spec, returns a diff. Never sees the original user goal. Doesn't know if the project is a startup demo or a production system.

Critic

Reviews · Pushes back

Reads a draft as if a stranger wrote it. Does not see the system prompt. Does not feel loyal to the author. Its job is to be the skeptic.

Retriever

Searches · Quotes

Takes a question, returns sources with verbatim quotes. No synthesis, no voice — just the receipts.

Specialist n

Whatever the job needs

Designer. Lawyer. Quant. Translator. The pattern composes — add a specialist, give it a clean context, wire it to the orchestrator.

Figure 2 The five-plus-one pattern. One orchestrator above; a roster of specialists below, each with its own context and its own job. The orchestrator never writes a single line of code or pulls a single source.

03 · The protocol

What actually crosses the seam

The agents are isolated. The handoff is the only thing that connects them — so the handoff is the system. The minimum viable handoff has three parts: a clear contract, a small payload, and a recorded decision.

sequenceDiagram
    autonumber
    participant U as User
    participant O as Orchestrator
    participant R as Reasoner
    participant C as Coder
    participant K as Critic

    U->>O: "build me X"
    activate O
    O->>O: decompose into 3 subtasks
    O->>R: { goal, constraints, format }
    activate R
    R-->>O: { plan, acceptance_criteria }
    deactivate R
    O->>C: { plan, contract, tests }
    activate C
    C-->>O: { diff, run_log }
    deactivate C
    O->>K: { draft, plan, criteria }
    activate K
    K-->>O: { issues[], verdict }
    deactivate K
    alt issues.length > 0
        O->>C: { issues, original_diff }
        C-->>O: { diff_v2 }
        O->>K: re-review
    end
    O-->>U: { final, audit_trail }
    deactivate O

Figure 3 The handoff contract. Each arrow is a typed payload. Each box is a clean context. The orchestrator holds no domain knowledge — it only routes, validates, and decides when to ship.

04 · Trade-offs

When the pattern wins, when it breaks, and the honest middle

Multi-agent systems are not a free lunch. They add latency, cost, and a new failure surface: the seams. The art is knowing which problems are worth paying for that tax.

Dimension	Single agent	Multi-agent
Persona coherence	LossRoles blend. The editor starts coding; the critic goes soft.	WinEach specialist runs in its own context. No blending.
Latency & cost	WinOne round trip. One bill. Cheap to run.	Loss2–5× more model calls. Coordination tax is real.
Debuggability	SplitOne trace to read — but the failure has no clear owner.	WinEach step is inspectable. The audit trail is the system.
Failure surface	SplitFewer seams, but a bad step poisons everything downstream.	LossMore seams. A bad handoff is a new class of bug.
Domain depth	SplitDecent at many things, master of none.	WinEach specialist can be deeply tuned. Sum of depths > depth of one.
Iteration cost	WinChange a system prompt, run again.	LossChanging a contract breaks every caller. Refactoring is non-trivial.
Right size of problem	Short, single-domain tasks. Quick answers. Anywhere coherence loss is acceptable.	Multi-step work that mixes domains. Anywhere persona leak would degrade quality.

Figure 4 Honest accounting. Three wins, three losses, two splits, one judgment call. The right column is not strictly better — it is differently shaped.

Closing observation

Build the seams first. The agents come after.

A multi-agent system is a small, opinionated protocol between personas. If the contract between them is sloppy, the system will produce confident garbage with extra steps. If the contract is sharp — explicit inputs, explicit outputs, an explicit decision rule for what to do when the work is bad — the system can outperform any single agent on the same problem, because each agent gets to be exactly one thing.

The pattern is older than the tooling. Print shops, military staffs, hospital triage, restaurant kitchens — all of them have been running multi-agent systems for decades. The novelty is not the structure. The novelty is that we can now implement the seams in plain text, and the agents in plain code, and watch the whole thing work in a browser tab.

— end —

Why Multi-Agent Systems Work · A Field Note Set in Shadows Into Light Two & Cause

← Back to all posts