team-topologylisted

# Team topology A method for defining a multi-agent team for a task as an explicit topology: not "spawn some agents" but a legible deployment you can draw, hand off, and reason about. Who runs where, who talks to whom, what each node can touch, which model sits in which seat. Substrate-agnostic: the same method applies to a Cotal mesh, harness subagents, workflow stages, or plain processes. ## When to use - The user asks to **define / design / lay out** a team or formation, or asks **"what topology?"**. - You are about to stand up more than one or two agents and want them arranged deliberately. - You need to communicate a running deployment in a scannable form. ## Step 1: pick the shape from the dominant risk A topology is a defense against the way the task fails by default. Name the task's **dominant risk**, then pick the shape that structurally prevents it: | Task type | Dominant risk | Shape | |---|---|---| | audit / review / research | missed findings, groupthink | **hub-and-spoke fan-out**: independent finder lanes, an adversarial verify tier, coordinator synthesizes | | fix / implementation | write races, unverified changes | **writer lanes + merge authority**: 1-2 writers in isolated workspaces, everyone else fenced read-only, a proof gate before merge | | staged transform (migration, ETL, generation) | loss at handoffs | **pipeline**: stages connected by explicit artifacts, each stage validates its input | | open design question | anchoring on the first idea | *