ModelRefs / Multi-Agent Networks — Tutorial
Multi-Agent Networks — Tutorial
Orchestrators, subagents, and message-passing — how to coordinate multiple AI agents on a shared task. Covers Why multiple agents.
Overview
Orchestrators, subagents, and message-passing — how to coordinate multiple AI agents on a shared task
Level: Expert. Estimated reading time: 40 minutes.
Why multiple agents?
A single agent handles one task at a time, has a single context window, and uses one set of tools. Multi-agent networks break these limits:
Parallelism: an orchestrator assigns independent sub-tasks to multiple worker agents running simultaneously. Researching 5 topics in parallel takes the same time as researching 1.
Specialisation: different agents can have different system prompts, tools, and models. A "researcher" agent with web search, a "coder" agent with a code sandbox, and a "critic" agent that reviews outputs.
Context management: complex tasks exceed a single model's context window. Subagents handle bounded sub-tasks and return summaries.
Checks and balances: a generator-critic-revisor pattern produces higher-quality outputs than a single agent.
Patterns: orchestrator-worker and peer-to-peer
Orchestrator-worker (most common): a central orchestrator plans and assigns tasks to worker agents. Workers report results back. The orchestrator synthesises the final answer.
Strengths: clear control flow, easy to debug, orchestrator can replan when a worker fails. Weaknesses: orchestrator is a single point of failure.
Peer-to-peer (autonomous): agents communicate directly via a shared message bus. Each agent picks up tasks that match its capabilities.
Strengths: more robust, scales to many agents. Weaknesses: harder to reason about, debugging is complex.
Supervisor pattern: a supervisor monitors all agents, detects loops or failures, and intervenes. Common when reliability requirements are high.
Anthropic's recommendation: start with orchestrator-worker, add a supervisor for high reliability, move to peer-to-peer only when scale demands it.
Communication, state, and safety
Agent communication: agents exchange structured messages. A shared message store (Redis, a database, or in-memory) allows agents to read each other's outputs.
Shared state: a state object passed between agents holds the plan, completed steps, and intermediate results. Each agent reads what it needs and writes its output back.
Safety in multi-agent systems: prompt injection risk is higher — a subagent reading external content could receive instructions that hijack its behaviour. Defences: treat subagent outputs as untrusted data, use allow-lists for tool actions, have a supervisor validate outputs.
Idempotency: tools should be idempotent (running twice = running once) because agents may retry failed steps. Non-idempotent actions (send email, charge a card) should require explicit confirmation.
Continue your research
Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Multi-Agent Networks — Tutorial.