When a long-running agent should ping you
A chat agent that answers in ten seconds doesn't need a notification design — you're already watching the screen when it finishes. That stopped being the default case sometime in the last year. Coding agents now run in cloud sandboxes for tens of minutes at a stretch, sometimes longer, and somebody has to decide when that's worth interrupting a person for.
The tooling caught up to the problem before anyone wrote down a framework for it. OpenAI's Codex ships a Slack integration where you tag @Codex in a thread, walk away, and it replies with a link to the finished task when it's done — admins can even disable it posting generated content directly to the channel, leaving just the completion link (Codex Slack integration). Devin works the same way: tag it, and it works alone in a sandbox until there's a pull request to look at, all coordinated through Slack (Devin on the Slack Marketplace). Claude Code added background-agent sessions that fire a Notification hook carrying agent_needs_input or agent_completed events as of version 2.1.198 (Claude Code changelog).
None of this is exotic anymore — it's just how these tools ship now. Which means the interesting question isn't "should we notify the user." It's "which of several different things is happening right now, and does this one deserve to reach a phone."
Three tiers, not one
LangChain's ambient-agents framework names three distinct human-in-the-loop patterns, and the distinction holds up better than most teams give it credit for (Introducing ambient agents):
- Notify — something happened that a person should see, but the agent isn't asking for anything and isn't blocked. A flagged email, a finished run, a summary worth a glance.
- Question — the agent is stuck on a specific piece of missing information and can't proceed without it. This is a genuine interrupt: the task is paused, not just informing you of something.
- Review — the agent has a proposed action ready and wants sign-off before executing it. The highest-stakes tier, because saying yes has consequences.
Collapsing these three into a single notification channel is the most common mistake in agent products right now. If "your PR is ready" and "I'm about to delete this branch, confirm?" arrive with the same sound and the same visual weight, the person who's trained themselves to glance and dismiss will glance and dismiss the one that actually needed a stop.
| Tier | What it means | Right channel | Wrong channel |
|---|---|---|---|
| Notify | FYI, no action needed | Digest, inbox item, badge count | Push to a phone at 2 a.m. |
| Question | Agent is blocked, needs an answer | Active interrupt, if the task is time-sensitive | A log line nobody reads |
| Review | Agent wants to act, needs approval | Push plus a specific diff of the proposed action | A bare "continue?" with no detail |
Suppressing the redundant ping
The other half of the design problem is knowing when not to notify. If you're sitting at the machine watching the terminal, a push notification telling you what you can already see on screen is worse than useless — it teaches you to ignore the channel entirely, which is the failure mode that costs you when a Review-tier event actually needs a fast answer.
Claude Code's changelog shows this being solved directly rather than left as a settings toggle: version 2.1.181 added a CLAUDE_CLIENT_PRESENCE_FILE environment variable that points at a marker file, and while that file says you're present, mobile push notifications get suppressed (Claude Code changelog). It's a small mechanism, but it names the real failure mode correctly — a notification isn't wrong because of its content, it's wrong because it duplicates something the person can already see.
What actually changed
The reason this needed solving now and not two years ago is duration and delegation, not novelty of the pattern itself. Chat interfaces had a synchronous rhythm: you asked, you waited a few seconds, you read the answer. Background and cloud agents broke that rhythm on purpose — the entire pitch of Codex cloud tasks, Devin, and Claude Code's background sessions is that you hand off a unit of work and go do something else. The notification is the only thread connecting the person to a process that's now running somewhere they aren't looking.
That changes what "good" notification design has to do. It's no longer about announcing that an answer arrived. It's about triage: deciding, on the agent's side, which of three very different situations just occurred, and picking a channel whose urgency matches the actual stakes rather than defaulting every event to the loudest available option.
The escalation ladder
Put the pieces together and a workable design looks like a ladder, not a single alert path:
- Log everything, always. The audit trail is the floor a notification design sits on top of, not a substitute for it.
- Route Notify-tier events to a digest or inbox, not a push. LangChain's Agent Inbox — an interface modeled on email and support-ticket queues rather than a single chat thread — is one answer to what that inbox looks like when several agents are producing these events at once.
- Escalate Question-tier events to an active interrupt only when the agent is genuinely blocked and time actually matters. Not every missing piece of information justifies pulling someone out of a meeting.
- Reserve push-to-phone for Review-tier events and real blockers — the two cases where the agent cannot proceed without a human and where waiting has a cost.
- Suppress duplicate channels once presence is already established, the way Claude Code's presence file does for an open terminal session.
The failure modes on either side of this ladder are symmetric, and both are visible in products shipping today. Push everything through one loud channel, and people mute it — the entire reason LangChain built a tiered inbox instead of a flat notification list. Push nothing, and the alternative isn't calm, it's an agent that stalls or acts on a guess somewhere unattended, with the full story only recoverable later from an audit trail nobody was watching in real time.
Where the tiers still leak into each other
The three-tier split is clean in theory and messier where products actually draw the line. Codex's Slack completion message and Devin's in-thread reply are both technically Notify-tier — the agent isn't asking anything — but a finished pull request sitting unreviewed for a day is a soft form of Review-tier risk, since nothing else is gating it from merging. Treating "done" and "done and safe to ignore" as the same notification is a subtler version of the same collapsing-tiers mistake, just one step downstream: the ping fired correctly, but what it should have prompted next wasn't obvious from the notification itself.
Getting this right mostly means being honest about which tier an event belongs to before deciding how loud to make it, rather than picking the channel first and rationalizing the urgency afterward.
The tracker keeps a running entry on ambient agents and the agent inboxes forming around them — worth a look if you want the current state of who's actually shipped a working inbox versus who's still describing the idea.