AI email triage workflow

Triage is not a smarter inbox filter. It is a system that reads what came in, decides what kind of thing it is, and hands you a short queue instead of a long one.

An inbox has three kinds of email in it, more or less: things that need a reply, things that need to be filed and referenced later, and things that need nothing at all. Most inbox tools are good at the third category, sorting newsletters and receipts out of the way. The harder and more valuable sort is the first two, and that is where an AI triage workflow actually pays for itself.

The version worth building does not summarize your inbox. It reads each new thread against what it already knows about your projects and contacts, and routes accordingly.

Think about what actually happens across a normal week: a supplier sends an invoice, a client asks a question that has already been answered twice in the same thread, and somewhere in the middle a short note arrives that quietly changes a project's direction. A rules-based filter treats all three the same, because it only sees sender and subject. A triage workflow that reads for meaning treats them differently, because it is not sorting mail, it is reading it.

What triggers it

New mail arrives, on whatever schedule you run the pass: a few times a day, or once, first thing.

What the system does

1. Reads each new thread in context

Not just the subject line and sender. It checks the thread against your existing project and contact files to see whether this is a continuation of something already tracked.

2. Classifies what kind of thing it is

A substantive thread that needs a decision, a status change to log, a logistics item, an event to add to the calendar, or noise. The classification determines what happens next, not a single generic action for every message.

3. Drafts a reply where one is owed

If a thread needs a response and the system has enough context to write one, it drafts it as staged text you review, never sends it, matching the pattern behind inbox zero with AI.

4. Files what needs filing and flags what it cannot resolve

A financial statement or receipt goes to the right project record, a reported decision gets logged the way the decision log workflow describes, and anything ambiguous, a thread that could belong to two different projects, a request the system is not confident about, gets flagged rather than guessed at.

What lands in front of you

A short queue: drafted replies waiting on your go-ahead, a list of threads that were filed and where, and a small number of flagged items the system could not confidently place. Not a re-summarized inbox. A queue of decisions. On a normal day that queue is short enough to clear before your first meeting, which is the actual measure of whether triage is working.

What you still decide

Whether each drafted reply actually goes out as written, edited, or not at all. Which flagged thread belongs where. And, over time, which senders or thread types you want the system to stop routing to you altogether because the answer is always the same. That last part matters: a triage workflow that never learns your patterns just adds a second inbox on top of the first one.

Where triage connects to the rest of the system

Triage is the front door. What it routes into becomes the input for the workflows behind it: a thread that reveals a promise becomes an entry in follow-up tracking, and a reported status change updates the right project the way project status tracking describes.

This is also why triage should not be judged on its own, in isolation from what it feeds. A triage pass that sorts mail perfectly but drops everything into a generic "handled" pile is not actually doing anything more than a folder rule would. The value is specifically in the routing: knowing that a thread is a decision, not just a message, and sending it somewhere that treats it like one. That is especially true for people like consultants and product managers, who tend to run the heaviest inboxes and feel a bad routing decision the fastest.