When to reach for it
- Many agents or services are loosely coupled.
- Events go to multiple receivers.
- Extensibility without central dependencies is important.
Pub/Sub Agent Mesh.
Topics, not addresses. Agents subscribe to what they care about.
Agents publish to and subscribe to named topics on a shared bus instead of calling each other directly, so a publisher never knows who consumes its events and subscribers can be added or removed without touching the publisher.
In practiceA sensor-monitoring platform publishes `anomaly.detected` events on a shared bus; three independent agents — alerting, logging, and auto-remediation — each subscribe and react independently without knowing about each other.
When it backfires
- Direct synchronous calls suffice.
- Message ordering and delivery are unresolved.
- Observability is not established.
The tradeoff
Scalable decoupling is gained against more complex delivery, debugging, and governance.
What it actually does.
Messages fan out to all interested subscribers.
Two ways this pattern will hurt you.
Topic taxonomy rots
Topics are coined ad-hoc; near-synonyms multiply; agents subscribe to one and miss messages published to the other. The naming is the system's bug surface.
Fix · Centralise topic definitions in a registry with descriptions and ownership. Reject publishes to unregistered topics at the broker.
At-least-once delivery double-processes an event
The bus redelivers an event after a consumer ack times out. A non-idempotent handler runs the side effect twice — a second charge, a duplicate order, a doubled metric.
Fix · Make handlers idempotent keyed by event id, and dedupe within a window at the consumer; never assume exactly-once from the broker.
Where Pub/Sub Agent Mesh is native.
AWSArchitecturesNative
Microsoft Agent Frameworkmessage-bus agentsNative
Keep going