Stop agent notification overload

Every alert spends attention

Treat your notification channel like a budget. Every message the agent sends spends a little of your attention and a little of your trust that the channel is worth opening. Spend both on a job that merely finished, and there is nothing left when a refund is sitting on your “yes.”

This is why a technically correct alert can still do harm. Patient-safety researchers gave the failure a name—alarm fatigue—after finding that when most alarms are non-actionable, staff turn them down, ignore them, or switch them off, and then miss the ones that mattered. A solo founder with a buzzing phone arrives at the same place faster: the channel gets muted, and the mute is indiscriminate.

How to judge it: for one week, mark every agent message that actually made you do something. If the acted-on share is small—say under a fifth—the channel is overspending, and the fix is fewer messages, not a louder phone.

The trade-off: sending less means you sometimes learn about a routine failure in the evening digest instead of the second it happens. That is the right price for anything that can wait, and the wrong price for anything with a deadline—which is exactly what the levels in the next section sort out.

Sort every message into three levels

A short policy beats a long one because you will actually apply it. Sort every kind of message the agent can send into exactly three levels, decided by one question: if I saw this at 2 a.m., would I need to do something before morning?

1. Needs action now — a risky approval waiting, a critical scheduled job stuck, or a security or access concern. These interrupt you the moment they happen.
2. Review soon — routine work that failed, or a connection or credential about to expire. Real, but it can wait for the next digest or a same-day nudge.
3. Summary only — successful runs, minor auto-corrections, routine confirmations. These never arrive on their own; they roll up into the digest.

Why three and not ten: levels only help if the choice is obvious at setup time. When you are unsure which one fits, rank up a step for anything that touches money, a customer, or access, and rank down for anything you would only ever glance at.

The failure case to avoid is a mislabel in the risky direction—filing a failed payment retry under “summary only,” where it sits unseen for a week. Getting a level wrong toward caution costs you one extra glance; getting it wrong toward silence costs you the incident. Today you set these levels in the agent’s standing instructions; a per-workflow notification-level selector in the dashboard is Coming soon.

Bundle routine information into one digest

Everything below “needs action now” belongs in a single scheduled digest—one message a day, or one a week for a quiet workflow—listing what completed, what failed, and what is waiting for review. Link each line back to the dashboard instead of pasting the full detail, so the digest stays a table of contents rather than a transcript. Because Hermes runs scheduled work, the digest is just another job on a timer.

The point is to convert forty interruptions into one planned read. An interruption costs you the task you were in the middle of; a digest you open on your own schedule costs almost nothing.

How to judge it: a good digest is skimmable in under a minute and every line has somewhere to click. The failure case is a digest that swells into a wall of text nobody opens—now just as ignored as the pings it replaced. When that starts, cut it to failures and review items and move pure successes to a single weekly count.

The trade-off: batching delays awareness by design. Set the cadence to match how fast you would truly need to react, and if something genuinely cannot wait for the next digest, it was never “review soon”—move it up a level.

Collapse repeats into one thread

One incident should produce one alert. When a connection drops and the agent retries every few minutes, you want a single message that updates in place—“retry 3,” “retry 12,” “recovered”—not twelve separate buzzes for one underlying problem. Give the agent a rule: group messages that share a cause, and update the existing one instead of opening a new thread.

This matters most overnight, which is also when it fails worst. The failure case: an integration flaps from 1 a.m. to 6 a.m. and floods the channel; by the time you wake, you mute everything—and the mute catches the real alerts too. Collapsing repeats is what keeps one flaky connection from burning down the whole channel’s credibility.

How to judge it: after an incident, count how many messages described the same event. More than a handful means the grouping is not working. The trade-off: a collapsed thread shows you a count, not each event, so add one rule back—if the incident crosses a threshold or passes a deadline, it escalates from “review soon” to “needs action now.” A muted repeat should still be able to shout when it finally matters.

Audit the channel every month

A notification policy rots. Every new workflow you add arrives with its own messages, and a channel that was quiet in March is loud again by June if nobody prunes it. Once a month, look back and ask one question of each recurring message: did this ever change a decision? Downgrade the ones that did not, and default every new workflow to summary-only, so noise has to earn its way up instead of being trimmed back down.

How to judge it: track the ratio of acted-on messages to total—the same number from the first section—and watch that it holds or climbs month over month. If it slides, the channel is filling back up.

The failure case is simply never doing this: six months of added workflows quietly rebuild the original flood. The trade-off: aggressive pruning can remove an alert that fired rarely but mattered when it did, so downgrade it to the digest before deleting it outright. A rare-but-critical message belongs in a quieter place, not in no place.