Execute, Don't Summarize: An AI Email Triage Pipeline That Runs Locally

The first thing everyone automates with AI is email summaries. A long thread becomes a polite bulleted list, and it feels like progress — until you notice you're now reading two documents instead of one: the summary, and the original you opened anyway to check the summary was right.

That's the summary trap. Reading was never the bottleneck. The time-sink in an inbox is the deciding and the drafting: what does this person want, do I owe an answer, and how do I phrase it without starting at a cursor for four minutes. Summaries describe that work. They don't do it.

The shift that actually saves time is from a workflow that describes your inbox to one that executes on it: drafts ready to edit, decisions flagged and ranked, noise archived before you ever see it. This post builds that pipeline — with prompts you can use today and a local n8n + Ollama version that keeps your entire inbox private.

Why Summaries Don't Save Time

A summary adds a verification step instead of removing work:

The third row is the goal. Editing a decent draft is 3–5x faster than composing, and triage labels mean you only open the emails that deserve a human.

The Triage Layer: Decisions vs Actions vs Noise

Before any drafting, classify. Every email is one of three things:

• ACTION — someone waits on your reply
• DECISION — a choice only you can make ("move the meeting to Tuesday?")
• FYI — information only; archive on sight

The classification prompt is short and works on any strong model:

Classify this email into exactly one bucket:
ACTION (awaiting my reply), DECISION (requires my choice —
state the choice), or FYI (no response needed).
Then in one line: what the sender wants.
If information is missing for a reply (dates, numbers, names),
list it under GAPS. Do not guess.
EMAIL: <paste>

The GAPS line is the quiet superpower. When the model drafts a reply missing a deadline, it says so at the top instead of inventing a plausible one — which is the failure mode that makes people distrust AI email tools in the first place.

The Drafting Layer: Kill Blank-Page Syndrome

Triage tells you what to answer. Drafting writes the first version:

Draft a reply to this email in my voice: direct,
no fluff, short paragraphs, bullet points where natural.
Address every request the sender made.
Put any missing facts I must fill in at the top as
[NEEDS: ...] placeholders — never invent details.
Style examples of how I write:
<3-5 of your own past replies>
EMAIL: <paste>

Two details do the work. The style examples keep it sounding like you (three to five of your own replies beat any adjective like "casual"), and the [NEEDS: ...] rule keeps the draft honest. You come back to a mostly-finished reply with a short shopping list, not a confident letter full of wrong dates.

For low-stakes mail, batch it: paste five newsletters-adjacent replies into one prompt, get five short drafts, clear them in one sitting.

The Logistics Layer: Meetings and Threads

Two more patterns cover the rest of an inbox.

Meeting requests — encode your constraints once:

My rules: only accept meetings about project X;
anything else gets offered async-first ("can we handle
this over email?"); Tuesdays are blocked.
Draft a reply to this meeting request following the rules.
REQUEST: <paste>

Long threads — extract what's still open:

Read this thread and list OPEN ITEMS: what I am
waiting on, from whom, since when. One line each.
THREAD: <paste>

That second prompt is the one people get emotional about. "You're still waiting on the contract from Sarah, 9 days" is the sentence that rescues a deal that would otherwise quietly die in a scrolled-past thread.

The Local Version: n8n + Ollama

Everything above works pasted into any chat window. But an inbox is the most private dataset most people own — client details, contracts, personal matters — and the pipeline needs the whole stream to be useful. That's a strong case for running it locally.

The architecture is simple: an automation tool watches the mailbox, a local model does triage and drafting, results land in a folder or a daily digest.

pipeline: inbox-triage
trigger:
  source: imap (new email)
  folder: INBOX
steps:
  - name: classify
    run: ollama llama3.1  # triage prompt from above
    output: bucket + one-line intent + gaps
  - name: route
    rules:
      FYI: archive, log one line to digest
      ACTION: draft reply via ollama, save to Drafts folder
      DECISION: flag + push to top of digest
  - name: digest
    schedule: "0 9 * * *"   # 9 a.m. daily
    output: decisions first, then drafts awaiting review

In n8n terms: an IMAP or email trigger node, an HTTP Request node pointing at your local Ollama instance (http://localhost:11434/api/generate), a Switch node for the routing rules, and an email-send node writing drafts back to your Drafts folder. Nothing leaves the machine — the model runs on your hardware, the automation runs on your hardware, and the daily digest is the only thing you actually read.

Triage and drafting are comprehension tasks, not creative ones — a mid-size local model handles them well, and the [NEEDS: ...] format keeps even a small model honest about what it doesn't know.

What Stays Human

The pipeline prepares; you decide. Three things never get automated:

• The send button — drafts wait for your edit and approval, always
• Decision answers — the model surfaces the choice; you make it
• Anything with real stakes — apologies, negotiations, bad news: the model drafts structure at most

This isn't timidity; it's the correct division of labor. Machines are good at preparing options, humans are accountable for them.

Frequently Asked Questions

Does email summarization ever make sense?

Rarely — mostly for genuinely long threads where you were CC'd late and need orientation before deciding. As a default workflow it adds a verification step. If you catch yourself opening the original to check the summary, the summary has already lost.

How do I keep drafts from sounding robotic?

Give the model three to five of your own past replies as style examples in the prompt. Concrete examples beat adjectives ("casual," "friendly") every time, and they're reusable — save them in a snippet so every prompt includes them.

Is a local model really good enough for replies?

For triage and first drafts, yes — these are comprehension tasks. The placeholder rule ([NEEDS: ...], never invent) does the safety work, and you're editing before sending anyway. Escalate only high-stakes mails to whatever your best model is.

How much time does this actually save?

The honest answer: it depends on your inbox volume and how much you batch. The structural change is real though — your role shifts from writer to editor, and editors move faster because they never face a blank page.

Wrap-Up

Summarizing email is a demo, not a workflow. The time lives in deciding and drafting, so that's where the automation goes: triage every message into action, decision, or noise; draft replies in your voice with honest placeholders; surface open items before threads die. Run it on your own hardware with n8n and Ollama, read one digest at 9 a.m., and press send on your own terms.