Inbox Triage Pipeline

01 The problem

The inbox ate the first hour of every day. Sorting what mattered from what did not, finding the thread that needed an answer, noticing the deadline buried three messages down. The work happened before the real work even started, and none of it needed a person. Worse, an urgent message could sit unread for hours behind a wall of newsletters and receipts, and I would not know until it was already late.

02 The system

A pipeline that works overnight. Each evening it pulls the full day of email across every label, drops obvious noise with plain rules, then sends the retained threads through second-pass classification into four tiers. It writes a ranked briefing and short action list, then leaves them on a dashboard, in a message, and in a dated archive. By the time I sit down, the first sort is complete and the highest-priority items are at the top.

03 How it holds up

The primary classifier sorts each retained thread, and a fallback retries output that fails validation. Three layers protect a completed day from an identical duplicate run. Soft warnings publish with a visible flag instead of being hidden. A separate watchdog confirms that the nightly record landed and raises an alert if it did not. The repo carries 179 tests across the pipeline paths.

04 The result

The pipeline moves the first triage pass before the workday and leaves a short, ranked list for review. A separate watchdog reports a missed nightly run, so a missing briefing becomes an explicit operational alert rather than a silent gap.

05 Frequently asked questions

Can automated email triage run overnight instead of in real time?

Yes, and overnight is the point. A scheduled job fires at 8 PM, pulls the whole day of email across every label, and sorts it into four tiers. By morning a ranked briefing and a short action list are already waiting, so the first hour of the day belongs to real work.

What happens if the classifier returns an invalid response?

A fallback classifier retries output that fails validation. If problems remain, the pipeline can publish the usable briefing with a warning flag rather than presenting the run as fully clean.

How do you know an automated pipeline actually ran?

I do not take the pipeline’s word for it. A separate watchdog checks the database to confirm the night’s run actually landed, and raises an alert if it did not. The system watches itself instead of waiting for me to notice a gap, and 179 tests sit behind the parts that matter.

How does an email triage pipeline keep processing costs down?

Plain rules drop the obvious noise first, so paid classification reads only the retained threads. This keeps the nightly second pass focused while the briefing still covers the full inbox through the combined rule and classification paths.