2.1 KiB
Why One Agent Is Not Enough
June 3, 2026
A single agent, no matter how smart, hits three ceilings.
The Context Ceiling
One agent doing everything means one context window holding everything. File contents, database schemas, business logic, deployment configs — they all compete for the same limited space. A 100K token codebase leaves zero room for the actual task.
The Capability Ceiling
A generalist agent is mediocre at everything. A specialized agent — backend dev, security reviewer, UI designer — outperforms the generalist in its domain by a wide margin. You wouldn't ask your frontend dev to write SQL migrations. Why ask your agent to?
The Reliability Ceiling
One agent failing = everything fails. Multi-agent systems degrade gracefully. If the reviewer agent crashes, the builder keeps working. If the planner goes down, deployed agents continue running.
The Solution: Depth-2 Delegation
The production-proven pattern:
User
|
v
Orchestrator (Opus-level, thinking only)
|
+-- Planning Team Lead
| +-- Product Manager (worker)
| +-- UX Researcher (worker)
|
+-- Engineering Team Lead
| +-- Frontend Dev (worker)
| +-- Backend Dev (worker)
|
+-- Validation Team Lead
+-- QA Engineer (worker)
+-- Security Reviewer (worker)
Leads think, plan, and delegate. Workers execute. The orchestrator never touches code.
When to Go Multi-Agent
You need multiple agents when any of these are true:
- Different expertise required — Your task needs a planner, a coder, a reviewer, and a security auditor
- Parallel work possible — Multiple sub-tasks can run simultaneously
- Failure cost is high — You want a second agent to catch mistakes before they ship
- Context exceeds one window — Split across specialized agents
If none of these are true, a single well-configured agent is simpler and cheaper.
This is an excerpt from Module 4 of the Agentic Engineering Course. The full module includes runnable lab code for building multi-agent systems with domain locking, mental models, and P2P communication.