The inbox stays closed and the two things that actually matter still reach you. An agent classifies first, posts to Slack only what crossed the threshold, and leaves the rest where they are — the point is fewer notifications, not a second inbox.
Every notification system starts by asking you to decide, repeatedly and quickly, whether something is worth your attention. That is the opposite of the job. The fix is not a better filter on the alerts — it is having nothing to filter.
The instinct is to tighten the filter: fewer senders, fewer subjects, a quieter primary tab. That reduces the count and not the problem, because the mail that remains is still arriving faster than you can judge it. What you actually need is for the decisions to be made before they reach you, not for fewer things to reach you unjudged.
The reason people keep the inbox open all day is not that they are reading it — it is the low-grade uncertainty about whether something important is sitting in there. That uncertainty is the actual cost, and it is paid whether or not anything ever arrives. Removing the need to check removes the cost even on the days nothing comes.
Sending everything to a channel just gives you two places to ignore. Slack is quieter than the inbox partly because it is ambient, which is exactly why it saturates fast — a channel with two hundred notifications a day is worse than the inbox was. The design constraint is not how to deliver more, it is how to deliver almost nothing and still trust it.
Copy it once, paste it into Zaira, and it reads your mail against the threshold you wrote, posts only what clears it, and stays quiet about everything else. The threshold is the whole product — the agent is just the thing that applies it without being asked.
Two or three posts a day instead of two hundred emails. The metric that tells you whether it is working is not volume — it is how often you open the inbox anyway, which drops because you no longer have to check in case something was missed.
Most runs post nothing, and that is the design rather than a failure state. An alert channel that occasionally stays empty is trusted in a way that one with daily filler never is — the whole value is in the runs where you did not have to look.
You write down what reaches you and what never does, and the agent applies it to four hundred messages a day. When it fires wrongly, you correct one sentence rather than tuning a filter, and the correction applies to everything that arrived since.
Each alert carries a link to the actual thread, so acting on it is one click rather than a search. That matters more than it sounds: an alert that sends you hunting for the original message has converted a notification into a task.
The questions people ask before letting an agent post on their behalf.
The opposite. This posts a small number of alerts — usually zero on any given run — and is explicitly forbidden from forwarding or summarising what it held back. Most alerting systems fail by moving the volume problem somewhere new. The whole design here is that the agent decides before anything reaches you, so the channel stays quiet enough to keep your attention.
Because priority is computed by Google from your behaviour and it is not yours to argue with — you cannot tell it a legal deadline outranks a customer escalation, and it will occasionally promote a newsletter while burying a client. Writing the threshold yourself in Step 0 is the entire difference: it encodes a judgement about your work that no client-side priority feature can know.
No, and that is deliberate. Self-claimed urgency from a sender you do not recognise is not a signal, which is why Step 2 bases the decision on who it is from and what it asks for. The first thing worth writing into your rules is which senders are allowed to trigger a post regardless of content — usually a named customer, your accountant, and nobody else.
Not usefully, which is why Step 0 takes an availability window and Step 4 tells it to stay silent entirely outside it. Anything that would page you at midnight is not an alert, it is an interruption. If you genuinely want overnight coverage, the honest version is a different channel with a different threshold rather than widening this one.
You correct the rule in Step 0 and every future run inherits it. That is the argument for writing the threshold in prose rather than tuning thresholds numerically — a sentence you can read and edit is learnable, whereas a set of weights you are trying to reason about is not. Keep the rules in one block so the correction is one edit.
Two rules do most of it. First, no counts, no heartbeats, no placeholders — Step 4 and Step 5 forbid them outright, because a channel that tells you it is empty every hour is as noisy as one that is full. Second, post nothing at all when the threshold is not met. If you find yourself scrolling the channel, the threshold is too loose, and the fix is the rules rather than muting the channel.