notification-routing

Define a JSON config mapping notification types to channel names or IDs, then have agents prefix output with a CHANNEL:<type> tag. A dispatcher function parses the tag and sends the message to the matching channel, defaulting to a general notifications channel.

Use topic-based routing so each notification type goes to its own channel instead of one shared feed. Agents tag messages by type, and team members subscribe only to the topics they care about, mirroring pub-sub patterns like Kafka topics or SNS filtering.

Yes, the routing layer is provider-agnostic. You plug in a platform-specific adapter script for Teams, Slack, Discord, or a generic webhook, while the channel config and CHANNEL tags remain unchanged across deployments.

Display names can collide across teams or workspaces, causing messages to land in the wrong channel. Resolve channel IDs once during setup, store them in the config alongside names, and use the opaque IDs at runtime for reliable delivery.

The dispatcher falls back to a default channel, typically the general notifications channel. This ensures untagged agent output is still delivered rather than dropped, while tagged messages route to their specific topics.