The first question I get about EmailTriage is why it doesn't connect to Gmail. I could have built an OAuth flow, requested read access, and synced messages in the background. I didn't, and the reason isn't privacy theater. It's that the connection is the expensive part of the problem, and most of what people need from triage doesn't require it.
Triage is a classification task over a finite batch. You have a pile of messages, you want to know which ones need a reply today, which ones you can read later, and which ones are noise. That's a labeling problem, not a synchronization problem. Once I framed it that way, the architecture got small.
The permission I didn't want to ask for
An inbox integration means tokens, refresh logic, scopes, a consent screen, and a background job that keeps state in sync. Every one of those is a surface I'd have to maintain. It also means the tool sees your whole mailbox, including threads that have nothing to do with the batch you're trying to clear. For a founder pasting twenty messages before a flight, that's overkill.
So EmailTriage works on bulk paste. You copy a set of emails into one field and get each one labeled. That's the entire input contract. No tokens, no background sync, no stored mailbox state. The feature list calls this 'No inbox access needed', and it's the decision I'm most attached to because it removes a whole category of failure: nothing breaks at 3am because a refresh token expired, because there is no refresh token.
The trade-off is real, though. There's no incremental update. If a new reply lands in a thread, it isn't in your batch until you paste it again. There's no threading context beyond what you copy. I'd rather be honest about that than pretend a paste box is a full mail client.
Three labels, and why only three
I spent more time than I'd like on the label set. Inside the tool, the output is ACTION, READ, or LOW. ACTION means the message needs a response and gets a draft reply. READ means it's worth your attention but not a reply. LOW means it can wait or be ignored.
Fewer labels is a deliberate constraint. A taxonomy with eight categories sounds more precise, but in practice it pushes the hard judgment onto the person doing the triage: is this 'urgent' or 'important but not urgent'? Three buckets force a choice that maps to a real behavior - reply now, read later, skip. The draft replies attach only to ACTION items, which keeps the tool from generating text nobody asked for.
The 'Auto label' and 'Draft replies' features are the two halves of that. Labels sort the pile; drafts give you a starting sentence for the ones that matter. Neither is a decision. I treat the draft as a first pass you edit before sending, not as something to fire off untouched.
Where the paste approach gets awkward
The interesting failures are all about input quality. Paste a forwarded chain with five quoted replies and the boundaries between messages get fuzzy. Paste HTML-heavy marketing mail and the useful sentence is buried under markup. Paste two emails with the same subject and no separator and you get one blob.
These aren't bugs I can fully fix with a smarter model, because the ambiguity is in the input itself. What I can do is be clear that the tool works on a batch of discrete messages and that you get better labels when each message is distinguishable. That's an honest limit of the format, not a hidden one.
Long threads are the other weak spot. A single email in a long conversation often only makes sense with the history, and a paste doesn't carry that history reliably. If a message looks like it references something you can't see, the honest move is to open your mail client and read the thread. The tool is a sorting aid for a batch, not a substitute for reading your mail.
What this is and isn't
EmailTriage is decision-support for clearing a pile of messages. It labels and drafts; you decide and send. It doesn't connect to your inbox, schedule sends, or guarantee that a labeled LOW item is actually unimportant. For a busy operator who wants to turn a wall of unread mail into three buckets and a few reply starters, that's the whole job. If you need continuous sync or full-thread awareness, a paste-based tool is the wrong shape and I'd say so.
FAQ
Does it need access to my inbox?
No. You paste a batch of emails and get labels and draft replies back. There's no OAuth, no token, and no background sync.
Why only three labels?
ACTION, READ, and LOW map to three real behaviors: reply now, read later, skip. A bigger taxonomy moves the hard judgment back onto you.
Are the draft replies ready to send as-is?
Treat them as a first pass. I'd review and edit before sending; the tool drafts, you decide.
What if my emails are messy or part of a long thread?
The labels depend on the text you paste. Forwarded chains and quoted replies can blur message boundaries, so for context-heavy threads, read the original in your mail client.
Top comments (0)