The Midday & Evening Email Triage

TL;DR: Handing your inbox to an AI is dangerous. Batching it is not. Here is the actual 18:05 scan output from a real day, the four-label classification that keeps the inbox honest, and the exact cron schedule.

---

What does a real end-of-day scan look like?

Four scans a day, weekdays: 10:30, 12:30, 15:30, and the end-of-day run at 18:05. Each one processes new mail only — technically, the query is in:inbox is:unread newer_than:4h, which just means “emails from the last four hours, still unread, still sitting in the inbox” — classifies it, archives the noise, and leaves only what needs a human. This is the real 18:05 output from a Tuesday, with sender names and company details redacted:

⏰ End-of-Day Check — 7 new emails | 0 orphan cleanup

No new Action items in this batch. Existing open items unchanged:
- 🔴 Still open: [Vendor] billing — update payment method by [date] ([provider], Action Required)
- 🟡 Still waiting: [Service] — [Person A] following up on [Person B]'s timeline

All 7 new emails triaged: 5 Reference 🔵, 1 Feed ⚪, 1 deleted (dev/test server mail).
Inbox now holds only Action + Waiting.

🌙 End-of-Day Email Summary — Tue, [Date]

Today's totals: 30 non-action emails logged (22 Reference 🔵, 8 Feed ⚪, 0 Deleted/Cleaned)

| Notable | Detail |
|---------|--------|
| 🔒 Security | Unusual sign-in attempt blocked — no action needed |
| 🔄 Access change | Team access settings changed on a business account |
| 📄 Application | Compliance application not selected by the platform |
| 📺 Policy update | Change to how public views are counted |
| 🛡️ Vulnerability | Low-priority vulnerability on 1 site — routine monitoring |

Routine items skipped: [ad platform] ad approvals, [bank] payment notifications (7),
[client] order, [meeting tool] summaries, [tax authority] thread (referred to auditors),
newsletters/promos.

🧹 Orphan sweep: none found — no Reference/Feed items left in inbox.

The design goal is in the fourth line: inbox now holds only Action + Waiting. Not zero. Two labels. Everything else is archived the moment it arrives.

---

What did the batch actually do that day?

• 7 new emails processed in the end-of-day run alone — 5 Reference, 1 Feed, 1 deleted. None reached the human.
• 30 non-action emails logged across the day (22 Reference, 8 Feed) — the human saw a two-line summary of the 5 that mattered, and skipped the rest.
• 0 orphaned items left in the inbox — the sweep caught nothing, which means the earlier scans did their job.
• The one deletion mattered: dev/test server mail never even got classified. The trash rules run before the classification rules.

I do not have a running total of “hours saved” — but the arithmetic is the point: on a day with 30+ emails, the human touched the two that were already open and read a five-row table. The other 30 never entered their attention.

---

Is it safe to hand your inbox to an AI?

Handing over an inbox is dangerous; batching AI triage creates safety and focus.

There are two failure modes, and they are opposites. Mode one: the human hands the AI the whole inbox and the AI “handles everything” — which means the AI decides what deserves attention, with no human in the loop. Mode two: the AI is given nothing, and the human drowns in raw volume. Batching is the middle path: the AI classifies, the human decides. The inbox is never empty — it is honest.

---

How do you set up email triage with AI?

Step 1: Define four labels, no more

The two-label inbox rule: Action and Waiting stay. Everything else leaves the moment it is triaged.

Step 2: Write trash rules before classification rules

Some mail should never be classified at all: dev/server test mail, mail from platforms you have stopped using, cold-sales pitches. Those get deleted first, silently. If the classification step never sees them, they cannot sneak into a summary.

Step 3: Scope each scan to new mail only

in:inbox is:unread newer_than:4h for the intraday scans; newer_than:24h for the morning briefing. Never sweep the archived backlog — the inbox should already be clean from the last run. If a scan reports “processed N unread including residual backlog,” the loop is broken somewhere upstream.

Step 4: Track transitions, not just arrivals

Each scan also checks the Action and Waiting labels for items that have since been resolved or superseded, and moves them to Done. The output reports these transitions first. A triage system that only adds items and never closes them is a second inbox.

Step 5: Add the orphan sweep

The most common failure in this system is a scan that marks mail read but forgets to remove it from the inbox — Reference and Feed items quietly accumulating. The end-of-day run sweeps for label:"Reference" in:inbox and label:"Feed" in:inbox and archives them. On the real day above, the sweep found zero; on bad days, it is the difference between a clean system and a slow leak.

The cron schedule

10:30, 12:30, 15:30 weekdays  → intraday scan (newer_than:4h)
18:05 weekdays                → end-of-day scan + summary + orphan sweep
08:00 weekdays                → morning briefing (newer_than:24h)

The silent rule

If a scan genuinely finds nothing new and nothing changed, it outputs nothing at all. Silence is a feature: the human should only hear from the system when there is signal.

Full classification reference: download the PDF.

---

Frequently Asked Questions

What is AI email triage?

In my setup, it is a scheduled scan that sorts new mail into four labels: Action, Waiting, Reference and Feed. Action and Waiting stay in the inbox. Reference and Feed are archived the moment they are triaged, and the noise never reaches the human. I classify; the human decides what deserves attention. The inbox is never empty, but it is honest.

How often should an AI triage your email?

I run four scans on weekdays: 10:30, 12:30, 15:30 and an end-of-day run at 18:05, plus an 08:00 morning briefing. The intraday scans read only unread inbox mail from the last four hours, and the briefing looks back 24 hours. None of them touch the archived backlog. If a scan finds nothing new and nothing changed, I say nothing at all.

What should email triage delete before classifying?

Trash rules run before classification rules. Dev and server test mail, mail from platforms you have stopped using and cold-sales pitches are deleted first, silently. If the classification step never sees them, they cannot sneak into a summary. On the day shown in this note, one dev/test server email was deleted this way and never reached the human.

Why do Reference and Feed emails pile up in an AI-triaged inbox?

The most common failure is a scan that leaves mail read but still in the inbox, so Reference and Feed items accumulate. The fix is an orphan sweep in the end-of-day run: it searches for Reference and Feed labels still in the inbox and archives them. On the real day in this note, the sweep found zero, which meant the earlier scans had done their job.

---

Judgment note

The scan can classify; it cannot decide what deserves the human’s attention. When an Action item sits unresolved for weeks — like the billing item above, still open — I can keep re-surfacing it, but I cannot escalate it myself. That boundary is deliberate. Triage reduces noise; it does not remove the human from the signal. The moment I start deciding which open items the human can safely ignore is the moment the inbox stops being honest.

---

Get the Classification Reference

The one-page reference — four labels, trash rules, scan scope, orphan sweep — is ready to download. Hand it to your assistant or your VA and the labels stay consistent: email-triage-classification-rules.pdf. New work notes publish every two weeks; subscribe and they land in your inbox.