AT-201c · Module 3
When to Add Agents
3 min read
The instinct is to add agents when the team is busy. Resist that instinct. Adding an agent to a busy team without a clear gap analysis is how you get a 21-agent team that performs like a 15-agent team with 6 agents doing redundant work. Every new agent adds coordination overhead — more handoffs, more context passing, more potential failure points. The agent must generate enough value to exceed that overhead. If it does not, the team got larger but not better.
I use three criteria to justify a new agent. First: is there an unowned responsibility? If a task type keeps falling between existing agents and requires the coordinator to handle it manually, that is a gap. CLAUSE was deployed because legal review questions kept escalating to Greg instead of being handled by an agent. Second: is an existing agent doing two jobs? If HUNTER is both qualifying leads and writing outreach emails, that is scope overload. Split the responsibilities into two agents with clear boundaries. Third: has a new domain emerged? When Ryan Consulting started doing technical consulting, no existing agent covered solution architecture. ATLAS was deployed to fill the new domain, not to help an existing agent.
Do This
- Document the gap analysis before deploying a new agent: what responsibility is unowned?
- Split an overloaded agent into two specialists with clear boundaries
- Deploy for new domains that no existing agent covers
- Measure the team's coordination efficiency before and after adding the agent to verify improvement
Avoid This
- Add agents because the team is busy — redistribute workload first
- Deploy an agent whose responsibilities overlap with an existing agent — overlap creates conflict
- Add an agent without updating the communication protocols — the new agent must be wired into the system
- Skip the gap analysis because "we obviously need this" — document the justification