team-topology

Topics in the source

• Team topology
• When to use
• Step 1: pick the shape from the dominant risk
• Step 2: specify three layers
• Step 3: place capability by lane
• Step 4: present it (the deliverable is a PROPOSAL)
• Step 5: agree, then execute
• Hard rules (any substrate)

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. 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. 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 (migr

This is an excerpt. Refer to the complete source and its current requirements.