Multi-Agent Systems — teams, and the coordination tax

Give each worker in pattern 4 its own full loop, tools, and system prompt, and you've crossed into multi-agent systems. The hype version says "many brains are smarter than one." The engineering truth is more interesting and more useful:

Recall the agent's binding constraint (Topic 58, discipline 2): one context window, filling with every step's debris. A research task touching forty sources drowns a single agent's context. Split it, and each subagent gets a clean whiteboard holding only its subtask — reads its ten sources at full attention, returns a compressed report to the orchestrator, whose own context holds only the plan and the digests. Multi-agent is context engineering by architecture. Three secondary benefits ride along: parallelism (subagents run concurrently — wall-clock wins on read-heavy work), tool partitioning (each role gets only its tools — Topic 57's least privilege, structurally enforced: the web-reading agent has no email tool, amputating the trifecta), and specialization (different system prompts, even different models per role — the router pattern, applied to personnel).

The architectures you'll actually see: orchestrator-subagents (dominant — a lead agent plans, spawns parallel workers, synthesizes; the shape of every deep-research product), pipelines (agents as assembly-line stations — really Topic 59's chain with loops inside the boxes), and critic pairs (a builder agent and a reviewer agent — the evaluator pattern with the evaluator given its own tools, e.g. actually running the tests).

Now the part the hype omits — the coordination tax, in three installments:

1. Token multiplication. Every subagent re-reads its system prompt and re-processes context; orchestration itself costs turns. Anthropic's published numbers on their multi-agent research system: roughly 15× the tokens of a plain chat interaction. The architecture pays for itself only when the task genuinely needs the isolation and parallelism — Topic 38's economics, with a bigger multiplier than most anticipate.
2. The telephone game. Subagents cannot see each other's context — that's the entire design. Everything crossing between agents is a written report, and information not written down does not exist for the recipient. So inter-agent messages must be composed for a colleague with amnesia — Topic 54's contractor standard, now applied agent-to-agent. Corollary: the orchestrator's task descriptions to subagents are prompts, and vague delegation produces subagents confidently solving the wrong subproblem in parallel, at 15× cost.
3. Distributed debugging. One agent's failure gives you a trajectory to read. Five concurrent agents' failure gives you five interleaved nondeterministic trajectories and an emergent outcome nobody individually caused. Observability — logging every message, every delegation, every report — stops being nice-to-have.

The honest placement rule: multi-agent wins on read-heavy, parallelizable tasks with clean subtask boundaries — broad research, codebase-wide analysis, multi-source due diligence. It loses on tightly-coupled sequential work where shared context is the whole game — which is most coding tasks, and why serious coding agents remain single-agent with occasional throwaway subagents for search, not standing committees. Define the interfaces between agents like you'd define APIs (structured report formats, explicit required fields), and know that the frameworks people name-drop — LangGraph, CrewAI, AutoGen, the Claude Agent SDK — are conveniences over concepts you now fully possess: a multi-agent system is functions invoking Topic 58's twenty-line loop with different arguments.

---