Single-agent or multi-agent? The answer depends on failure tolerance, observability, and whether subtasks are actually independent. Most teams reach for multi-agent architectures before they have earned the complexity.
The appeal of multi-agent systems
Multi-agent architectures look elegant on diagrams. A coordinator delegates to specialists, each with focused tools and prompts. Failures in one agent don't cascade. The system can process subtasks in parallel. Individual agents are testable in isolation.
In practice, each of these benefits has a corresponding cost that diagrams don't show.
Where multi-agent systems actually fail
Context degradation at handoffs. When one agent passes output to another, information is lost. The receiving agent sees a summary or a structured artifact — not the full reasoning, not the edge cases the previous agent considered and discarded. Each handoff is a potential point of silent failure. The coordinator sees a clean output from an agent that internally made a questionable decision, with no visibility into the reasoning.
Error propagation without attribution. A downstream agent producing wrong outputs is often blamed for a problem that originated two steps earlier. Debugging multi-agent failures requires tracing the entire execution graph, not just examining the output. Teams consistently underestimate how difficult this is before they have experienced it.
Parallelism that isn't. Subtasks that appear independent often have data dependencies that only become visible under production load. Two agents that can each run in isolation may produce conflicting states when run concurrently on the same underlying data. Concurrency bugs in agent systems are harder to reproduce than in conventional software.
When to use a single agent
A single agent with well-designed tools is the correct starting point for almost every production system. It is observable — one execution trace, one set of tool calls, one output. It is debuggable. It fails in predictable ways. Context is not degraded by handoffs.
The limiting factor for single-agent systems is context window size and the cognitive load of a very large tool set. When a task genuinely cannot fit in a single context — when it requires more information than a context window can hold, or when it involves sequential subtasks that each require substantial context — multi-agent starts to make sense.
The right time to introduce a second agent
Introduce a second agent when you have a working single-agent system and you have identified a specific bottleneck that agent decomposition solves — not before. The bottleneck should be measurable: context overflow, latency from a sequential step that could run in parallel, or a subtask with a different failure mode that warrants separate evaluation.
Start simple. Instrument everything. Add agents when the data tells you to, not when the architecture diagram looks cleaner.