Chapter 5 · Multi-Agent & Team Harnesses · Lesson 5.1
When to Add a Second Agent
The win: more agents is not automatically better - add one only for a concrete reason, and default to a single agent otherwise.
- Chapter 0 · Sprint Zero
- Chapter 1 · The ratchet & the practice loop
- Chapter 2 · Spec-driven development in depth
- Chapter 3 · Scaling & trusting the harness
- Chapter 4 · Measuring & evolving the harness
- 5.1 · When to add a second agent
- 5.2 · Orchestration patterns
- 5.3 · Worktrees & parallel isolation
- 5.4 · The team harness
- 5.5 · Fighting drift & governance
The trap: more brains feel smarter
Spinning up a swarm of agents feels powerful. It looks like you are throwing more brains at the problem, so surely the work gets better. It usually does not. Every extra agent adds coordination cost - the parent has to split the work, hand it off, wait, and stitch the pieces back together, and context gets lost at each seam.
So the starting position is not "how many agents?". It is one. A single agent, in one clean context, is the default. You only add a second when you can name a concrete reason - and there are exactly three.
When a second agent earns its place
Each of these is a behaviour a single agent can't deliver well on its own. If none of them applies, you don't have a reason yet.
- Isolation - a subagent with its own fresh window does a messy job (read a huge codebase, sift a pile of files) and returns just a short summary, so the parent's window stays clean. That's the context firewall from Lesson 1.5 - it keeps context rot off the main thread.
- Parallelism - two subtasks that are genuinely independent (they don't depend on each other's output) can run at the same time instead of one after the other. Real fan-out, not busywork.
- Diversity - a different model or a different lens catches failures the first one is blind to. That's cross-agent review from Lesson 1.6: two agents, same code, different mistakes found.
The anti-reason: "it sounds cool"
The reason that does not count is "more brains must be smarter" or "a multi-agent setup sounds impressive". That is the trap dressed up as a plan. Sequential work - a chain of steps where each one builds on the last - that one agent could do in a single clean context usually gets worse when you split it, because of the coordination overhead and the context lost between agents. The number from the top of the lesson is that failure, measured.
Rule of thumb
If you can't name isolation, parallelism, or diversity, keep it single-agent. When you do add one, give it a crisp, narrow job and a clean handoff - a clear question in, a short answer out. A second agent with a vague brief is just more mess to coordinate.
Check yourself
When no clear reason applies, you should -
One agent in one clean context is the default. You only add a second when you can name isolation, parallelism, or diversity - otherwise the coordination cost buys you nothing.
A good reason to add one is -
The three valid reasons are isolation, parallelism, and diversity. Genuinely independent subtasks that can run at once are real parallelism. "Sounds impressive" and "more brains" are the trap, not a reason.
Sequential work split across agents usually gets -
Steps that must happen in order lose context at every handoff. Splitting them degraded performance by 39-70%. Keep a dependent chain in one head.
Do this now (3 min)
Think of a recent task you were tempted to split across agents - or already did. Ask the one question that settles it:
- Which of the three reasons applies - isolation (keep a messy job off the main window), parallelism (truly independent subtasks), or diversity (a second lens catching different failures)?
- If none of them fits, keep it single-agent. That is the right answer far more often than it feels.
Go deeper
Primary source (read this): My Experiments With AI - Agentic Engineering: Why the Harness. Where the 39-70% degradation number lives, and the case for defaulting to one agent.
Wisdom (test it on people): the HumanLayer community - practitioners arguing over when a second agent actually earns its keep versus when it just adds noise.