Agent orchestration

The frontier of agent hype is 'multi-agent systems' — swarms of specialists collaborating. Some of it is real and valuable; much of it is complexity cosplay. This module gives you the honest version: when multiple agents genuinely help, when they just multiply your failure modes, and how to build them when they're warranted.

The default: one agent, more tools

Start here and stay here as long as you can. A single well-designed agent with a good tool suite handles an enormous range of tasks, and it has one context, one trajectory to debug, one place for guardrails. Most 'we need multiple agents' intuitions are actually 'we need more tools' or 'we need better context management' — cheaper fixes you already know. Reach for multiple agents only when a single agent hits a real wall.

The walls that justify splitting

• Context overload: the task needs so much specialized context that no single window holds it all coherently — a research agent, a coding agent, and a writing agent each need different tools and reference material. Splitting lets each keep a focused window (Module 4's problem, solved structurally).
• Genuine parallelism: independent subtasks that can run at once — investigate five leads simultaneously, then combine. Real wall-clock wins.
• Separation of privilege: a worker that only reads and analyzes, and a separate gated actor that writes — so the powerful permissions live in a small, heavily-guarded agent. A security architecture, not just an org chart.
• Distinct expertise: subtasks needing genuinely different system prompts, tools, or even models. A specialist beats a generalist juggling five hats — sometimes.

The patterns

• Orchestrator–worker: a lead agent decomposes the task and delegates subtasks to workers (often via a spawn_worker(task) tool — a worker is a tool that is itself an agent), then synthesizes results. The dominant real-world pattern; the orchestrator holds the plan, workers hold the focused work.
• Pipeline: fixed stages, each an agent, output→input (retrieve-agent → analyze-agent → write-agent). Simpler and more predictable when the stages are known — but if the stages are fixed, ask whether they even need to be agents, or just pipeline steps.
• The coordination tax is real: more agents = more model calls (cost), more latency (unless parallel), and a new failure surface — agents miscommunicating, the orchestrator misdelegating, results lost in handoff. You're trading single-agent complexity for coordination complexity; make sure the trade pays.