Every overloaded agent tempts you with the same fix: add more agents. Sometimes that is exactly right. More often you have just bought yourself coordination overhead, a bigger token bill, and a new class of failure that is much harder to debug. This week you learn the patterns — and the honest test for whether you need them.
Specialization (a narrow role with a narrow tool set), context isolation (each worker gets a clean window instead of one bloated one), and parallelism (four searches at once instead of four in a row). These are real. They are why Anthropic's own research system is multi-agent.
Coordination: every hand-off is a contract that can be under-specified. Context fragmentation: two agents holding different pictures of the same task make confidently conflicting decisions. Tokens: each agent is a full model call with its own prompt overhead.
Attribution. A single-agent run has one trace to read. A five-agent run fails somewhere in the seams, and "whose fault was that?" becomes a research question — unless you paid, up front, for per-agent and per-hand-off logging (Week 8's evaluation discipline).
Capability grows roughly with the number of agents. The number of relationships that can go wrong grows faster. This is the oldest result in organization design, and it did not stop being true when the workers became language models.
Pick a team size.
Each agent is a recurring per-run expense, not a one-time build cost. Anthropic reports that their multi-agent research system consumed roughly 15× the tokens of a chat interaction (Anthropic Engineering, 2025 — figure as reported, approximate). Parallel search buys breadth, not savings. A second agent has to earn that line item.
Two agents that disagree do not announce it — they produce two confident, incompatible outputs and let a human discover the contradiction. Your users cannot see the seam. That is a trust failure before it is a technical one.
"Why did the system do that?" has a clean answer only if every agent's trace carries the Week 2 evidence standard — state before → observation → available actions → selected action → result → state after — plus the hand-off payload. Budget observability before you add the agent.
Your first working capstone checkpoint: a single agent that runs end to end on your chosen task, plus the start of an evaluation harness — a handful of cases you can re-run to tell whether a change made things better or worse. Submit on iCollege in your own section; the full brief and rubric live in the Milestone I dropbox.
Do not add a second agent to Milestone I without a written justification. "It felt cleaner" is not one. The justification you owe is the test from page 02: name the subtasks, show that they can run in parallel, and say how each one is verified on its own. A single agent with well-designed tools is the correct default — and it is the baseline you will need in order to prove that a second agent helped.