When a second agent genuinely helps
Lesson 2 of 5 in Multi-Agent Systems: When One Agent Isn’t Enough.
Strip away the anthropomorphism and a second agent gives you exactly one new physical resource: another context window. Every legitimate reason to go multi-agent is downstream of that fact. There are three.
Context isolation. Some subtasks generate huge, disposable working sets — a web research sweep produces fifty pages of fetched text to yield three sentences of finding. Run that inside your main agent and the junk permanently occupies the window that also holds the user’s goal, degrading every later decision. Give it to a subagent with a clean window and only the three sentences come home. This is context engineering by architecture: the worker’s mess is garbage-collected the moment it returns.
Heterogeneous capability. The agents are genuinely different: an expensive frontier model plans while a cheap fast model executes bounded steps; a coding agent gets shell access while the customer-facing agent gets none. That last split is least privilege made structural — the agent that reads untrusted email cannot also hold the credentials, which is your strongest defense against the lethal trifecta.
Parallel independent work. Five competitors to research, forty files to migrate — subtasks that share no state and need no coordination mid-flight. Fan out N workers, run them concurrently, and wall-clock time approaches the slowest worker instead of the sum. The keyword is independent: parallel workers that must agree on shared state mid-task buy you lesson 4’s failure modes, not speed.
Context isolation — the strongest reason
Test: does the subtask generate bulk intermediate content (search dumps, file trees, long tool outputs) that the parent does not need verbatim? Then a fresh-window worker returning a compressed report protects the parent’s reasoning. If the parent would need the raw material anyway, isolation just adds a lossy compression step — keep it in one agent.
Heterogeneous capability — different models, tools, or privileges
Test: would you configure the two roles differently even inside one agent — a different model tier, a disjoint toolset, stricter sandboxing? Privilege separation is the version with teeth: a boundary the runtime enforces survives prompt injection; a boundary written in the system prompt does not.
Parallel independent work — fan out, then integrate
Test: can you write each worker’s brief before any worker starts, and does no worker need another’s output mid-task? Then fan-out converts serial latency into parallel latency. If briefs depend on earlier results, the work is sequential — a pipeline wearing a fan-out costume, better served by one agent or a workflow.
Key terms: context isolation, context engineering, fan-out, least privilege, context window
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.