Module 6 — Multi-Agent & Macro Process

A single agent loop is a machine for spending context. Every tool result, every file read, every stack trace accumulates in one window until the window is full and the work is not done. Delegation is the obvious escape: hand a bounded piece of the job to a second agent, get back a summary, and keep the parent's window small. It is also the most over-applied idea in the field. The literature is full of "orchestrator plus five workers" diagrams; the production reality is that most of those five workers cost more than they saved, arrived with no shared understanding of the codebase, produced conflicting edits, and returned prose that the parent had to re-read in full anyway.

This module treats delegation as an engineering decision with a measurable cost, not a design aesthetic. The cost has three components you will feel directly in the lab: context duplication (a fork copies the parent's history into the child's requests, so you pay for the same tokens twice), result-schema discipline (an unstructured child return is a second unbounded input to the parent, defeating the purpose), and barrier latency (a fan-out finishes when its slowest branch finishes, so a five-way parallel step costs the max, not the mean). Every architectural choice in the module trades against one of those three.

The taxonomy underneath is simple and worth memorizing before anything else: a child either inherits the parent's conversation (fork), starts empty with only a prompt (spawn), runs as a separate OS process speaking a protocol (subprocess), or is a different vendor's agent entirely (cross-vendor driver). Those four differ in cost, isolation, capability, and failure mode, and confusing them is the root of most multi-agent bugs.

---

Learning objectives

• M6.1 — The delegation decision. State the conditions under which delegating is cheaper than continuing in the parent, and — more importantly — recognize the larger set of cases where it is not.
• M6.2 — Subagent architecture. Distinguish fork, spawn, subprocess, and cross-vendor-driver children by context inheritance, capability set, isolation, and failure mode.
• M6.3 — Context isolation and the return channel. Explain why a child's only durable product is its result, and design result schemas and report paths that hold under failure.
• M6.4 — Capability negotiation. Explain why a provider must declare what it supports at start time, and why unsupported requests must fail loudly rather than being silently dropped.
• M6.5 — Orchestration topologies. Compare sequential, fan-out/barrier, and pipelined execution; compute the latency and concurrency consequences of each.
• M6.6 — Lifecycle and control of running children. Describe one-shot runs versus continuable children, and the semantics of messaging, interrupting, and listing live agents.
• M6.7 — Durable and long-running work. Distinguish in-turn work, background jobs, scripted workflows, and scheduled work, and state what survives a process restart in each.
• M6.8 — Quality harnesses and anti-patterns. Evaluate loop-based, adversarial, and judge-based quality structures, and name the failure modes of each — including the ones the field has not solved.

---

Prerequisites and time

Prerequisites: Module 1 (the spine), Module 2 (the agent loop and its stop conditions), Module 4 (context assembly, compaction, and token budget), Module 5 (permission decisions and blast radius). Module 6 assumes you can already reason about a token budget as a scarce resource; the whole argument here is about spending it.

Estimated time: 4–5 hours reading, 4 hours lab.

Scope note. This module covers macro process — structure above the single agent turn. Structure within a turn (parallel tool calls, tool-result ordering, the rolling call pool) belongs to Modules 2 and 3 and is assumed here.

---