Every "AI email" product claims smart triage. The phrase does a lot of heavy lifting because the actual mechanic — how the software decides whether a message matters — is almost never explained. It ends up sounding magical, which is convenient for the marketing copy and terrible for anyone trying to evaluate whether the thing will actually fit their workflow.

Here's the unmagical version. Modern email triage is a classifier with three jobs: read the message, assign a category, decide what to do about it. The hard part isn't the classification — language models are very good at that — it's the chain of consequences after the category lands.

Step 1: read the message

The classifier sees three things about a new email: the participant fields (from, to, cc), the subject line, and the body text. It doesn't see your reply, your relationship to the sender, your calendar, or anything outside the message itself — unless you've given the tool explicit access. The simplest triage systems stop there. The better ones layer in a small amount of context: did you reply to the last three messages from this sender? Is this sender in your contacts? Is the subject a reply to a thread you started?

Context matters because the same message can mean different things in different inboxes. A "quick question about Q4" from your CEO is a top-priority reply needed. The same subject from a vendor you've never replied to is more likely noise.

Step 2: assign a category

The category set defines the ceiling of what triage can do. Two categories (important / unimportant) is too coarse — you can't treat a receipt the same way as an FYI from your team. Twenty categories is too granular — you'll spend more time tuning the rules than reading email. The sweet spot most well-designed systems land on is six to ten:

To Respond — explicit ask, needs your reply.
FYI — informational, no action required, worth reading.
Notification — automated system message (build status, calendar invite, etc.).
Marketing — vendor outreach, newsletters, drip campaigns.
Receipt — transactional confirmation.
Calendar — invite or schedule change.
Spam — what your provider missed.

Each category gets a default action: To Respond stays in the inbox, FYI gets a soft label, Marketing and Notification auto-archive. The user can override defaults globally (always keep newsletters in the inbox) or per-sender (this newsletter is actually a friend's blog, don't archive).

Step 3: decide what to do

This is where most triage products get it wrong. The classifier picks a category, the tool applies the default action, and the message either disappears or stays. Done. No reasoning, no explanation, no override path. When the classifier makes a mistake — and it will — you discover it three days later when a customer pings you about a missed email, and you have no way to understand why it was buried.

The right design records a one-line reason for every classification. Not a model log — a sentence in plain English. "Sender matches newsletter pattern, no first-party CTA in body." You can read it on any thread to audit a decision. When the classifier is wrong, you reclassify in two clicks and the override gets remembered for future messages from that sender.

The failure modes nobody talks about

Triage fails in three predictable ways:

False archives. An important message gets labeled Marketing and auto-archived. Recovery: a daily review of auto-archived mail catches these in the first week, and per-sender overrides prevent recurrences.
FYI burial. A thread starts as FYI (low priority) but evolves into a real conversation that needs your input. The classifier doesn't re-read old threads. Good systems re-evaluate when a thread extends or the sender changes, promoting FYI → To Respond when warranted.
Drift. Your inbox patterns change — new clients, new topics, new senders — and the classifier's accuracy slowly degrades. The fix isn't to retrain a global model; it's to keep the override path open so the system continuously learns from your corrections.

What "working" actually looks like

After a week of use, a well-tuned triage system should:

Auto-archive 60-80% of your inbound email volume without you noticing anything missing.
Get the "To Respond" bucket right 90%+ of the time — no important threads buried, very few non-actionable ones surfaced.
Adapt to per-sender overrides within a day or two of you setting them.
Surface its reasoning on every decision so you can audit misses without a support ticket.

Anything less and you're trading one form of inbox cognitive load (reading every message) for another (auditing the triage). The whole point is to reduce your involvement, not relocate it.

How Inboxer does it

Inboxer's triage runs on eight categories (the seven above plus Sent for outbound mail). It explains every classification in plain English on the thread, supports per-sender and per-thread overrides that propagate to future messages, and re-evaluates FYI threads when they extend. Auto-archive is configurable per-category from /settings/inbox — you can opt any bucket out of the default rule.

If this sounds like the workflow you want, the deep mechanics live in our triage use-case page. You can also start a 7-day free trial on one inbox without a credit card.