Topic-Based Routing
Route inter-agent messages through named typed topics agents subscribe to — senders never need to know who's listening, and new subscribers join without touching the sender.
telemetry.parsed, incident.opened, plan.proposed); agents that care subscribe; the runtime fans messages out to all subscribers, applies back-pressure on slow consumers, and provides delivery guarantees per topic class — a new monitoring agent, audit agent, or downstream processor joins by adding a subscription, with zero changes to existing publishers.Intent & Description
🎯 Intent
Route inter-agent messages through named topics that agents subscribe to, instead of having senders address each other by id.
📋 Context
A message produced by one agent is potentially of interest to several others, and the set of interested agents may change over time. The sender shouldn’t need to know which agents care about its message, and new subscribers should be able to join without forcing changes to existing publishers.
💡 Solution
Define a small set of typed Topics (telemetry.parsed, incident.opened, plan.proposed). Agents publish to topics; agents that care subscribe to topics. The runtime fans messages out to all subscribers, applies back-pressure on slow consumers, and provides delivery guarantees appropriate to the topic class. Topic schemas are first-class artifacts; subscribers depend on the schema, not on the publisher.
Real-world Use Case
- Senders should not need to know which agents care about a message.
- Subscribers join and leave over time without requiring sender-side changes.
- Cross-cutting concerns (audit, observability, monitoring) need to attach by adding a subscriber.
Source
📌 TL;DR
Publish to topics, subscribe to what you care about — senders stay decoupled from receivers, new consumers join without touching publishers, and cross-cutting concerns attach for free.
Advantages
- Senders are fully decoupled from receivers — new subscribers join without any sender changes.
- Cross-cutting workflows (logging, audit, monitoring) attach as additional subscribers with no integration cost.
- Scales to many participants where direct addressing would become unmanageable.
Disadvantages
- Diagnosing “who is supposed to handle this topic?” requires runtime subscription introspection.
- Topic-schema drift can break subscribers silently if not versioned carefully.
- Slow subscribers need explicit back-pressure rules or they degrade the entire topic for all consumers.