Multi-Agent Systems
When and how to split work across multiple agents: architecture patterns, communication protocols, and shared state strategies.
Quick Reference
- →Multi-agent = multiple specialized agents collaborating on a task, each with its own tools and prompt
- →Three main patterns: supervisor (centralized control), swarm (peer-to-peer handoffs), and hierarchical (nested supervisors)
- →Agents communicate through shared state in LangGraph — the state object is the message bus
- →Use multi-agent when a single agent would need 15+ tools or when tasks require genuinely different expertise
- →Each agent should have a focused system prompt and a small, curated tool set (3-7 tools)
Why Multi-Agent?
A multi-agent system splits a complex task across multiple specialized agents, each with its own tools, prompt, and role, coordinated through shared state or message passing.
A single agent with 20+ tools suffers from tool selection confusion, bloated system prompts, and degraded reasoning. Multi-agent architectures solve this by giving each agent a narrow scope -- 3 to 7 tools and a focused prompt. The coordinator (supervisor or peer handoff) handles routing, not execution.
- ▸Tool overload: LLMs pick the wrong tool more often as the tool count grows beyond ~10
- ▸Prompt dilution: a single system prompt covering research, writing, and coding is worse than three specialized ones
- ▸Parallel execution: independent agents can run concurrently via LangGraph's Send API
- ▸Separation of concerns: each agent is independently testable, versioned, and deployable
Multi-agent adds latency, cost, and debugging difficulty. Start with a single agent and only split when you hit measurable tool-selection or prompt-quality limits.