Inbox Triage with AI

How much time goes on email in the first place

There are three independent measurements on this, and what makes them convincing is that they line up.

On top of the 2.8 hours a week of reading come writing, searching and filing — which is how you get to one to one and a half hours a day. That is the ceiling: there is no more than that to save, however good the tool is.

What to steer clear of: figures of the "three hours a day on email" kind typically come from a 2012 report, and they travel around statistics-aggregator sites with no source attached. That data is more than a decade old.

What is measurable: what you gain and what you do not

In that same randomised experiment, measured by telemetry:

• whoever got the licence read email for 12 minutes a week less (−7%);
• whoever actually used it, −18%, which is more than half an hour a week;
• response time got 18 minutes shorter (−4%);
• the number of conversations did not change.

That last point is the one that matters. The machine does not produce fewer messages, and it does not answer more of them on your behalf. It makes you read your inbox faster. Anyone expecting the mail to run out will be disappointed.

And one thing is worth stating plainly: there is no recent, independent measurement of how often draft replies are accepted. Neither vendor telemetry nor research publishes a figure for how many of the suggested replies get sent unchanged. If you see a specific percentage for this somewhere, ask where it came from.

Categorisation: 25% or 99%?

Here is the most instructive contradiction in the article, because at first glance it looks as though two measurements rule each other out.

The first one: a 2026 academic study measured 90.4% "accuracy" on a large corpus of real mail — while precision was a mere 25.3%. In plain terms: when the system said "this is a technical email", it was wrong three times out of four, and it missed 60% of the genuinely technical ones. The 90.4% looks good only because more than 90% of the mail fell into the other category anyway — meaning a "say no to everything" strategy would also have scored above 90%.

The second one: a June 2026 vendor benchmark, but an unusually transparent one — 42 models tested, hardware disclosed, a reproducibility package — measured F1 scores above 99% with several models on the same kind of task. The key sentence in the report: every model that was kept achieved recall above 99%, so the difference between models comes almost entirely from precision, not from missed hits.

The resolution is not in the model, it is in the category.

The practical message: if you cannot describe in two sentences what counts as "important", the machine will not be able to either. The accuracy of categorisation does not depend on which model you pick, it depends on how sharp the definition you give it is.

The recipe

1. THREE CATEGORIES, NOT TEN
   Needs a reply / Need to know / Nothing to do with me.
   One sentence for each that settles the borderline case.

2. WRITE THE DEFINITION DOWN, DO NOT JUST THINK IT
   "Important" is not a category. "Comes from a client and
   has a question in it" is.

3. LABEL FIRST, DO NOT MOVE ANYTHING
   For one week, let it only tag. Then look at how many
   filings were wrong — and in which direction.

4. DRAFTS YES, SENDING NO
   You review the draft. No automatic sending, not even
   when it looks good.

5. WHAT NEVER GOES TO THE MACHINE
   Dismissal, complaint, legal matter, price and contract
   changes. You do not even let it tag these.

The third step is the one most people skip, even though it is the only thing that tells you whether it works for you. The measurement above shows exactly that a nice-sounding aggregate figure can hide 25% precision — and the only way to notice is to look at the false alarms separately from the missed hits.

A copy-paste instruction for the labelling:

Sort this email into EXACTLY one category:

NEEDS_REPLY — it has a question in it, or a decision is
  expected from me, or it sets a deadline for me.
NEED_TO_KNOW — information that concerns me but expects
  nothing from me.
NOT_MY_JOB — newsletter, automated notification, a copy
  that does not concern me.

Give the category, and in one sentence say WHY, citing
the original text. If none of the three fits it clearly,
write: UNCERTAIN.
Do not guess.

The "UNCERTAIN" option is needed because without it the model is forced to decide — and the borderline cases are the ones it will get wrong.

The risk that barely gets discussed

This part is the most important section of the article, and most inbox recipes leave it out.

When an assistant reads your mail for you, the content of the mail becomes part of its instructions. And the model has no reliable way to tell an instruction apart from data. This is not a bug that will eventually be fixed: it is a property of the architecture.

Four documented cases from 2025–2026:

• Zero-click data exfiltration in an office assistant. An instruction hidden in a harmless-looking email that needed not a single click from the user to run: the reply contained a reference that the client downloaded by itself, and that carried the data out. It was given a vulnerability identifier, the vendor fixed it, and no evidence of exploitation in the wild was found.
• Phishing through the summary. Zero-size, white-coloured text in the message — invisible to the recipient, readable to the model. When the user clicked the "Summarise" button, the machine wrote the fake security warning, with a phone number, at the end of its own summary. So it looked as though the provider were saying it.
• Poisoned content in enterprise search. An instruction hidden in a shared document, a calendar invitation or an email, which ran whenever anyone in the company started an ordinary search — and carried the data out through a disguised external image request.
• The largest measurement of this: in a public competition, 839 participants made 461,640 submissions against a mail assistant. 3,324 of those were successful end-to-end attacks. The defences were worth a lot — with the best single defence it took around five hundred attempts on average to get the first success — but even with every defence switched on at once, at the hardest level 16.6% of the participants got through.

The balanced reading: a casual attacker does not get in. Against a persistent, adaptive attacker, on the other hand, no defence is a hundred per cent.

Two practical frameworks follow from this, and they are worth applying to your own setup:

• The lethal trifecta. If the assistant has access at the same time to (1) private data, (2) untrusted content and (3) an outbound communication channel, then it becomes an exfiltration tool. The inbox hands you the first two for free — the third one you add yourself.
• The rule of two. An assistant running without human approval should satisfy at most two of the three properties.

That is why the recipe has the "drafts yes, sending no" step. It is not timidity: it is what takes the third leg out of the trifecta.

Common misconceptions

• "I will have fewer emails." You will not. The measurement says the number of conversations does not change — you just read them faster.
• "They measured 90% accuracy, that is good." Not necessarily. If 90% of the mail falls into one category anyway, then the 90% tells you nothing. Precision and recall have to be looked at separately.
• "It is enough to tell it to filter out the important stuff." This is the most common mistake. "Important" is not a category, it is a feeling. You need a criterion that can be written in two sentences.
• "The email is just data to the machine." No. The model cannot separate an instruction from data — that difference is exactly what all four cases above rest on.
• "The vendor will fix it." They fix the specific vulnerabilities. The general cause — that a token does not carry on it whether it is a command or data — they cannot fix, and the industry position papers say so themselves.

What to take away

The inbox is good ground, because the gain is measurable: half an hour of reading a week, a four per cent faster reply. That is not a revolution, but it is real.

The two things it stands or falls on: a sharp category definition and the machine not being allowed to send on its own. The first one you have to dig out of your own head; the second is a setting you must not switch off, not even after a week of flawless work.

Where else there is a measurable gain in your office day is broken down task type by task type in the real time savings post; and for meetings, where the time does not drop but the notes do get better, the meeting notes post has the recipe.