Chapter 7: When the Team Has Many Agents
From one agent to many. This step usually gets called multi-agent orchestration, but that term points at a flowchart: nodes and edges. A team is about role relationships: who owns what, who delivers to whom, who answers for whose output, and when to escalate.
This chapter deals only with the engineering layer: how a group of agents divides labor, hands off work, shares the context it must share, and avoids contaminating one another. Writing appears as a concrete case. It makes the classic multi-agent mistake easy to see: turn a group of agents loose to write in parallel, stitch the results together, and you usually get a Frankenstein draft.
Multi-agent design means separating the judgment roles that must stay independent, then installing an explicit editor-in-chief role that owns the final cut. Separating here does not mean the finer the roles the better. It means keeping distance between judgments that must not contaminate each other: fact-checking, critique, execution, and the final cut. The next chapter takes up the higher-level question: which parts of human organizational experience to inherit, and which human failures must not be replicated.