One agent, or many?

The last foundational decision: one agent, or several? The honest default is start with one. A single agent with a clear task, a good set of tools, and solid verification is easier to build, cheaper to run, and far easier to debug than a committee. Multi-agent systems are seductive on a whiteboard and painful in production.

The reason is coordination. Every time one agent hands work to another, something can be lost in the hand-off: context the second agent never received, an assumption the first one made silently, an error that compounds down the chain. More agents means more hand-offs means more places for the thread to snap. The system gets harder to reason about exactly as it gets more impressive-sounding.

There's a concrete lesson here worth remembering. Microsoft's first version of its Azure SRE Agent was built with 100+ tools and 50+ subagents. It looked comprehensive. But long hand-off chains between all those subagents failed in practice, and they rebuilt it around a few generalist agents and just 5 core tools. Fewer, more capable pieces beat a sprawling org chart of specialists. The failure wasn't the model's intelligence — it was the coordination cost the harness couldn't absorb. That's the golden rule again: the hard part was never the reasoning; it was keeping a reliable loop across many moving parts.

So when should you add a second agent? Two honest cases:

1. A genuinely different job. Not "a slightly different prompt" — a different task with different tools, different context, and a clean boundary between them. If you can't state where one agent's job ends and the other's begins in a sentence, you don't have two jobs; you have one job you're splitting for no reason.

2. To check the first one's work. This is the strongest reason to add a second agent, and it's just the golden rule made structural: the generator can't judge itself, so a separate evaluator holds the quality bar. A reviewer agent reading the worker's output against a rubric is verification you can trust more than self-assessment.

A simple rule of thumb to carry out of this module:

Add a second agent only to do a genuinely different job, or to check the first one's work. Everything else is one agent with better tools.

Before you split, try the cheaper fixes first: give the one agent better instructions, better tools, or a tighter loop. Most "we need multiple agents" problems are really "our single agent's harness is weak" problems in disguise.

And whatever you build — one agent or five — the guardrails don't change. Read-only by default. Spend caps on every loop. A human approves anything risky, no matter how many agents proposed it. The number of agents is an implementation detail; the discipline is not.