swarmlisted

# Swarm Fan out N agents at once. They may cover separate slices, race the same brief, or mix both. The parent waits, aggregates, and returns one report. ## The one rule that makes this a swarm **All N Agent calls go in a SINGLE assistant message as N separate tool uses. One message, N tool_use blocks.** **If you emit one Agent call, wait for it, then emit the next, you have not swarmed — you have run a slow serial loop wearing a swarm's name.** That is the default failure mode and it is invisible from the outside: the transcript looks busy, the wall-clock cost is N times what it should be, and the race arms can no longer be compared because each one saw the previous one's result. Concretely, the fan-out turn contains: ``` message: [Agent(brief 1), Agent(brief 2), Agent(brief 3), ... Agent(brief N)] ``` not ``` message: [Agent(brief 1)] → result → message: [Agent(brief 2)] → result → ... ``` Before you send the fan-out turn, count your tool uses. If the count is less than N, stop and rewrite the message. **N briefs, N tool uses, one message.** No exceptions for "let me just check the first one works" — sending a probe agent first and the rest after is the serial loop again. ## When a swarm is the wrong tool A swarm is one model-driven fan-out: N independent briefs, one aggregation. When the shape is a *pipeline* — items flowing through stages, loops that run until dry, verify passes gating each stage, or more arms than you can aggregate in one turn — use the native