📝 Multi-Agent System

Description

< What is it? >

• [Multi-Agent System (MAS)]
  • A multi-agent system is an agentic AI system in which several specialized agents, each with its own prompt, tools, and (often) its own model, collaborate to solve a task that a single agent would handle poorly. Instead of one agent holding every instruction and every tool, the work is split across agents that communicate by passing messages or shared state.
  • Each agent keeps its own context window. That is the main reason to go multi-agent: a single agent degrades once its prompt carries dozens of tools and thousands of tokens of unrelated history, while N focused agents each stay inside a small, relevant context.
• [Agent vs. sub-agent]
  • A sub-agent is an agent invoked as a tool by another agent. The caller sees only the sub-agent's final answer, not its intermediate reasoning or tool calls — so the sub-agent's exploration never pollutes the caller's context. This is the compression property that makes deep research and large-codebase tasks tractable.
• [Handoff]
  • A handoff transfers control (not just data) from one agent to another: the receiving agent takes over the conversation and decides what happens next. Handoffs make peer-to-peer topologies possible, where a supervisor is not the only router.

Key points

< When to go multi-agent >

1. [Context isolation] the task produces far more intermediate tokens than final answer tokens — search, reading many files, log triage. Sub-agents read a lot and return a little.
2. [Parallelism] subtasks are independent (compare 5 vendors, audit 20 files), so agents can run concurrently and wall-clock time drops to the slowest branch rather than the sum.
3. [Specialization] different subtasks want different prompts, tools, or model tiers — a cheap model for mechanical extraction, a strong one for the final synthesis.
4. [Adversarial checks] a separate critic/verifier agent that never saw the author's reasoning catches errors that self-review misses, because it cannot inherit the same wrong assumption.

< When NOT to >

1. [Token cost] every agent re-reads its own context; a multi-agent run typically burns several times the tokens of a single-agent run for the same task. It pays off only when the task value justifies it.
2. [Shared-state writes] agents editing the same files or rows in parallel conflict. Either serialize the writes, or isolate each agent (separate branch/worktree/scratch dir) and merge afterwards.
3. [Coordination loss] instructions degrade as they pass through layers. If the subtask is small enough for one agent, one agent is more reliable and cheaper.

Architecture

< Common topologies >

• Network (peer-to-peer) — any agent may hand off to any other. Flexible, but termination and loops become your problem.
• Supervisor (orchestrator–worker) — one lead agent decomposes the goal, dispatches sub-agents, and synthesizes their returns. Workers do not talk to each other. The default and the easiest to debug.
• Hierarchical — supervisors of supervisors. Used when the subtask tree is genuinely deep; each layer costs fidelity, so keep it shallow.
• Agentic workflow (pipeline) — a fixed sequence of agents (extract → transform → verify), with the control flow written in code rather than decided by a model. Deterministic where determinism is cheap. This is the boundary case of the taxonomy: a workflow orchestrates LLMs through predefined code paths, whereas an agent decides its own next step at runtime. Prefer a workflow whenever the steps are known in advance — it is cheaper, reproducible, and debuggable.

< Swarm multi-agent vs Supervisor multi-agent >

• Definition

  • [Swarm multi-agent] — all agents are peers. Each agent can hand off to any other agent, there is no central orchestrator. This is the most flexible topology, but it is also the hardest to debug and the easiest to get stuck in loops.

    • Flow:
      1. User starts talking to Agent A
      2. Agent A handles what it can, then passes control (handoff) to Agent B
      3. Agent B continues the conversation
      4. Agent B may pass to Agent C if needed
      5. Each agent gives the user the final answer directly
    • Example:
      • User: "I want to cancel my subscription and get a refund"
      • Reception Agent → "I can help. Let me check your account..."
      • Reception Agent → (Hands off to Billing Agent)
      • Billing Agent → "I see your subscription. Let me process the refund..."
      • Billing Agent → "Done! Refund will appear in 3-5 days."

  • [Supervisor multi-agent] — one orchestrator agent decomposes the goal, dispatches sub-agents, and synthesizes their returns. Workers do not talk to each other. This is the default and the easiest to debug.

    • Flow:
      1. User asks the Supervisor a complex question
      2. Supervisor decomposes the task into subtasks
      3. Supervisor assigns each subtask to the right specialist
      4. Each specialist reports back to the supervisor
      5. Supervisor synthesizes the final answer
    • Example:
      • User: "Write a market report on AI stocks"
      • Supervisor → Research Agent: "Go find stock prices"
      • Supervisor → Analyst Agent: "Analyze the data"
      • Supervisor → Writer Agent: "Write the report"
      • Supervisor → User: "Here's your report"

• Comparison Table

  	Swarm	Supervisor
  Control	Any agent, by handoff to a peer (Decentralized) Peer-to-peer: Agents pass control to each other as needed	One orchestrator, for every dispatch (Centralized) Top-down control: Supervisor assigns tasks to sub-agents Can enforce termination conditions and avoid loops
  Failure mode	Agents can get stuck in infinite handoff loops, no single trace of who decided what. Loss of global coherence	Orchestrator is the bottleneck and the single point of failure
  Cross-cutting rules	Duplicated per agent or hoisted into shared context	Enforced once, in the orchestrator
  Best for	1. The route through the subtasks cannot be predicted (like customer service) 2. Conversational routing, loosely coupled specialists, low-latency handoffs	1. Subtasks are independent and their returns need merging 2. Complex tasks needing planning/sequencing, strict oversight, audit trails 3. Task has clear, predictable steps 4. Task needs easy debugging & monitoring
  Debugging	Harder — a need to trace agent-to-agent conversations (distributed decisions)	Easier — one place to inspect
  Examples	Customer support chatbots, multi-domain assistants	Document processing, code generation pipeline, data analysis

< What the supervisor (orchestrator) owns >

1. [Task decomposition] turning one goal into subtasks that are independently answerable, with explicit output formats — vague subtask descriptions are the single largest source of duplicated or missed work.
2. [Effort scaling] deciding how many agents a task deserves. A simple lookup gets one; a broad audit gets a fan-out.
3. [Result merging] deduplicating overlapping findings and resolving contradictions between agents before answering.
4. [Termination] a stop condition — a budget, a round cap, or "K consecutive rounds found nothing new" — since agents left to route freely will not stop on their own.

Crash course

Reference

• Multi-Agent Systems with LangGraph (datacamp)
• How we built our multi-agent research system (Anthropic Engineering)
• Building effective agents (Anthropic Engineering)
• AutoGen (Microsoft)
• CrewAI docs (CrewAI)
• Multi-agent architecture explained (Rich Holmes)
• Agentic workflows (agentguides.dev)