The 5 concepts of multi-agent systems

Tap any concept to jump to its 5-card cluster.

• 1When One Agent Isn't EnoughSpecialists beat one overloaded generalist
• 2Architecture PatternsSupervisor, pipeline, peer-to-peer
• 3Communication ProtocolsStructured handoff messages
• 4Shared State vs. MessagesCentral store vs. explicit handoffs
• 5Conflict ResolutionWhen agents disagree

Split the job across specialists

One agent can do a lot — until the sub-tasks need fundamentally different skills. Research wants search tools and a "gather facts" mindset; writing wants a creative prompt and no tools; editing wants a critical eye. Cramming all of that into one agent means a bloated system prompt, 15+ tools, and conflicting instructions.

A multi-agent system hands each role to a focused agent: a small prompt (200–400 tokens), 3–5 relevant tools, and one clear job. A coordinator delegates and stitches the results together. The payoff is sharper prompts, better tool accuracy, parallel work, and failure isolation.

The solo contractor building a skyscraper

BEFORE: Imagine one contractor asked to build a skyscraper alone — architect, structural engineer, electrician, plumber, and project manager, all at once.

PAIN: Even with every skill, they drown in context switching and can't work on the foundation and the wiring at the same time. A single agent with 20 tools and a kitchen-sink prompt is the same: mediocre at everything, and stuck doing one role at a time.

MAPPING: A multi-agent system is the construction crew. The Researcher has search tools, the Writer has a prose prompt and no tools, the Editor watches grammar, and a Supervisor coordinates like a project manager. Each focused role means fewer tools, a clearer prompt, and better results.

Four wins from specializing

1. Prompt specializationEach agent's system prompt is 200–400 tokens and focused — the model follows short, sharp instructions more reliably.
2. Tool isolationEach agent gets only the 3–5 tools it needs. Selection accuracy drops sharply above 5 tools.
3. Parallel executionIndependent agents run at the same time, cutting wall-clock time.
4. Failure isolationEach agent is a separate call — if the Editor fails, the Researcher's results survive.

Fewer tools per agent = higher selection accuracy

Multi-agent or single agent?

IF every sub-task uses the SAME
   tools and reasoning style:
  → one planning agent (simpler, cheaper)

IF sub-tasks need DIFFERENT expertise
   (research vs write vs review):
  → go multi-agent, one role each

# the decision point is ROLE DIVERSITY,
# not task size. Coordination isn't free —
# only pay for it when roles truly differ.

A local model like Mistral benefits even more from a short, focused prompt than a frontier model does.

Misconceptions

Choose who talks to whom

Once you have multiple agents, you must decide the structure: who assigns work, who talks to whom, and how results flow. There are three dominant patterns — supervisor/worker (a hub coordinating spokes), pipeline (an assembly line), and peer-to-peer (a mesh where anyone talks to anyone).

The pattern is the org chart of your system. Skip it and agents duplicate work, pass incomplete context, or deadlock. Supervisor/worker is the safe default — it handles 90%+ of real use cases and is the easiest to debug.

Three ways to run a team

BEFORE: Imagine assembling a team but never deciding how it's managed. Does one person assign tasks? Does everyone coordinate as equals? Does each finish a part and hand it on?

PAIN: Without a structure you get chaos — people duplicating work, waiting on each other, or stepping on each other's toes. Multi-agent systems fail the same way when no pattern defines the flow.

MAPPING: The three patterns are familiar org shapes. Supervisor/worker is a manager with a team who assigns and compiles. Pipeline is an assembly line where each station adds value and passes work forward. Peer-to-peer is a brainstorm where everyone contributes as equals until consensus emerges.

The three patterns

1. Supervisor / WorkerA coordinator decomposes the task, dispatches to workers, and aggregates results. Workers never talk to each other. One control point, easy to debug.
2. PipelineAgents in sequence: each takes the previous output and refines it. Researcher → Writer → Editor → Reviewer. Ideal for staged refinement.
3. Peer-to-PeerAny agent talks to any other, no central coordinator. Flexible for debate, but N×N channels make it hard to debug — rare in production.

Hub-and-spoke: workers report only to the supervisor

Which pattern fits?

IF unsure / general coordination:
  → supervisor / worker (safe default, 90%)

IF task is staged refinement
   (research → write → edit):
  → pipeline

IF you need open debate / negotiation
   AND can afford the complexity:
  → peer-to-peer (rare, <5%)

# start with supervisor — you can
# always refactor later.

Misconceptions

Agents pass structured messages

Agents don't share a mind — each has its own isolated context window. So they communicate through handoff messages: structured objects with typed fields, not raw text tossed over the wall.

A good handoff carries who sent it, who receives it, a task ID, a type, the payload, and — critically — the original_goal and instructions. The #1 multi-agent failure is context dropping: Agent A knew something important but didn't put it in the message, so Agent B operates blind.

Company forms vs. shouting across the office

BEFORE: Imagine departments coordinating by shouting. Sales yells "We got a big deal!" but never says the client, the value, or the deadline.

PAIN: Marketing hears fragments and launches the wrong campaign; Finance has no idea what happened. Agents do this too — the Researcher hands over raw text without saying which facts are confirmed or what the goal was, and every hop loses information.

MAPPING: Structured communication is a company form: client name, deal value, product, deadline, terms. Every department knows exactly what it's getting. Handoff messages work the same way — typed fields for task ID, status, payload, and next instructions ensure nothing gets lost in translation.

Anatomy of a handoff

1. Routing fieldssender, receiver, and task_id say who sent it, who processes it, and how to track it across the pipeline.
2. Type & payloadtype is task / result / error / feedback; payload holds the actual content (notes, draft, edits).
3. Carried contextoriginal_goal and previous_results travel with every message so no agent operates blind.
4. MetadataTimestamps, token counts, and confidence scores support auditing and later conflict resolution.

One typed envelope carries goal + payload between agents

Pseudocode

handoff = {
  sender:   "researcher",
  receiver: "writer",
  task_id:  "article-42",
  type:     "result",
  payload:  { notes, sources, confidence },
  # context that MUST travel along:
  original_goal: "beginner walking article",
  instructions:  "use all 5 findings, 200-300w",
  metadata: { tokens, timestamp },
}
send(handoff)   # pass ONLY what the receiver needs

Misconceptions

Central store or explicit handoffs?

When agents need to share data, you pick a coordination model. Shared state is a central store (database, dict, file) that every agent reads and writes. Message passing gives each agent private state; they communicate only through explicit handoff messages.

Shared state feels simpler but breeds race conditions: two agents write the same key, one clobbers the other; or B reads before A finishes. Message passing is more verbose but eliminates conflicts and makes every data flow logged and auditable. For 5+ agents or production, message passing wins.

One Google Doc vs. emailed copies

BEFORE: A team writes a document. Option one: everyone edits the same Google Doc at once (shared state) — fast and convenient.

PAIN: Two people edit the same paragraph simultaneously and create conflicts, or one silently overwrites the other and the good version is lost. As agents grow, these race conditions multiply and are subtle to debug.

MAPPING: The other option: each person works on their own copy and emails revisions to a coordinator (message passing). No conflicts, but every change is an explicit handoff. For 2–3 agents shared state is fine; for 5+ or production, message passing is more robust because every input and output is explicit and auditable.

Three risks & the fix

1. Race conditionsTwo agents write the same key at once; one silently overwrites the other's work.
2. Stale readsAgent B reads a value before Agent A finishes writing the updated version.
3. Tight couplingChange the store's schema and every agent that reads it breaks at once.
4. Message passing fixes itPrivate state + explicit messages: no shared writes, every exchange logged. Big outputs become artifact references, not embedded blobs.

Message passing trades verbosity for auditable, conflict-free flow

Shared state or message passing?

IF 2-3 agents, quick prototype:
  → shared state is fine (simplest)

IF 5+ agents OR production
   OR you need audit / replay:
  → message passing

IF outputs are large (long drafts):
  → hybrid — pass an artifact ID,
     not the full blob

# conflict pairs grow fast:
# 5 agents = 10 pairs, 10 agents = 45.

Misconceptions

Plan for when agents disagree

Agents will contradict each other — the Researcher says "500 employees," the Editor says "it's 800 now." Without a resolution protocol, one output silently overwrites the other and the wrong answer ships. Silent conflicts are worse than loud failures.

Design for disagreement upfront with one of four strategies: supervisor arbitration, voting/consensus, confidence scoring, and human-in-the-loop escalation. Each fits a different situation and cost budget.

Two editors, one article

BEFORE: Two editors work the same article — one makes a paragraph formal, the other makes it conversational.

PAIN: With no tiebreaker, both changes land and the paragraph becomes an incoherent mix — or one silently overwrites the other and nobody knows the formal version was lost. In agents, outdated data can silently propagate to the final output while the user trusts it.

MAPPING: Resolution strategies are editorial workflows. Arbitration is a senior editor picking the better version. Voting is asking three editors and taking the majority. Confidence scoring trusts the more confident editor. Escalation flags unresolvable disputes for a human.

Four resolution strategies

1. Supervisor arbitrationThe coordinator sees both outputs and picks or merges. Cost: one extra call. Best when it has enough context to judge.
2. Voting / consensusRun the task 3+ times and take the majority. Expensive (3× calls) but reliable for factual, high-stakes answers.
3. Confidence scoringEach agent reports a 0–1 confidence; pick the highest. Caveat: self-reported confidence is poorly calibrated — use as a tiebreaker.
4. Human escalationFlag unresolvable conflicts for review, using programmatic thresholds (scores within 0.1, safety-critical data, 3+ retries).

Which strategy to reach for

IF coordinator has enough context:
  → supervisor arbitration (cheap)

IF factual + high-stakes, one right answer:
  → voting / consensus (3x cost)

IF you need a quick tiebreaker:
  → confidence score + other signals
     # never trust confidence alone

IF scores within 0.1 OR safety-critical
   OR retried 3+ times:
  → escalate to a human (make it a RULE)

Misconceptions

Test the core insight

One question per concept. Tap to reveal the answer.