Adding a second agent is a decision to pay three to ten times more for coordination you did not have before.

A multi-agent system is an architecture in which several autonomous agents, each with a narrow role, work in a shared environment on a task a single generalist could not handle well alone. Four things make it one: specialised agents, an orchestrator or router that decomposes goals and manages handoffs, a shared environment of data, context and external systems, and communication protocols that keep everyone in sync. That is the definition — but the first honest thing to say about the pattern is that most systems built this way should have been a single agent with a better prompt. Coordination is not free: multi-agent approaches typically consume three to ten times the tokens of a single-agent equivalent, add failure points, and are considerably harder to debug, and teams have spent months on elaborate architectures only to match them later with a better-engineered single agent. Three situations genuinely justify the cost — protecting context from irrelevant accumulation, parallelising genuinely independent work, and specialising where tool sets, behavioural modes or domain depth conflict — and the single most important design rule is to divide work by the context it requires rather than by the type of work it is. This guide runs from concept to implementation: the components, the decision, decomposition, topologies and design patterns, orchestration and routing, communication and shared state, handoffs and the telephone game, parallelism, the verification subagent, conflict and consensus, failure and cascades, termination, observability across a graph, evaluation, inter-agent identity and trust, the economics, the frameworks, and the operating model. Five lenses per concept: what it requires, how to architect it for a bank, a flow diagram, a plain-English reading, and what it hands off next.