Obvious Engineering

Building Notifications for an Agentic World

A sneak peek into the four-tier notifications routing system I've been working on.

Daria Shifrina · April 2, 2026 · 2 min read

So I've been getting overwhelmed managing all my agents recently. And a big part of that? Notifications. There is SO MUCH noise in today's world, and building proactive agents that are always working on cool things and always want to tell you about it got chaotic fast. So I interviewed my agent on what it needs in a notification system, compared it against my own notes, and built Agentic Notifications into Obvious to help power a couple of new products I'm working on.

This post is about figuring out where to reach you in the least disruptive way possible. Whether we should bother notifying you at all is a whole other post about our heartbeat and triage system. Coming soon.

The answer is a four-tier presence routing system:

Presence Detection SSE state in Redis

↓

Where is the user?

Tier 1

Active in chat

drop

Tier 2

In-app, elsewhere

in-app toast

Tier 3

Tab dark

OS desktop notif

Tier 4

No presence

external delivery

Presence is tracked via SSE connection state stored in Redis. There's a dedicated set per user, so checking if someone is online is a single O(1) read. It works across all replicas, not just in-memory, so it holds up at scale.

Here's what actually happens at each level.

Tier 1: You're in the chat, actively watching your agent work. The client detects this and skips the notification entirely. You're already watching it happen, so there's nothing to tell you.
Tier 2: You're in the Obvious app, just not in that specific chat or project. A real-time in-app event fires and shows up as a small toast or notification badge. Quiet and non-interrupting.
Tier 3: You have Obvious open but you're not actively in the tab. A notification election happens because multiple tabs could all fire an OS desktop notification at once. The system picks the best candidate: a hidden tab on matching context wins, then a visible tab on matching context, then the most recently hidden tab, then any tab as a last resort. First one elected fires the ping.
Tier 4: No active connections, you're fully away from the app. This routes to external delivery (ex: Slack, text, etc) in whatever order you've set as your preference. The system tries each one and stops at the first success.

The ordering is user-configurable, and storing those positions was its own fun problem. Instead of integer positions (1, 2, 3) that need a full renumber every time you update your preferences, we use fractional indexing.

One more thing: urgency

The agent itself decides if something is urgent. It can flag its own notification as urgent, and when it does, the whole delivery strategy flips.

Normal notifications cascade: try your preferred channel first, stop when one succeeds. There's also rate limiting, one ping per channel per five-minute window, so you're never getting spammed by a chatty agent.

Urgent notifications fan out to every external channel simultaneously, in parallel. No cascade, no rate limiting, and if you happen to be in the app it fires an in-app ping on top of everything else. The agent decided it was important enough to reach you everywhere at once, so we do exactly that.