Every AI email product shipped in the last two years has the same architecture, and it is the wrong one. The model reads your mail. The model decides what matters. The model drafts a reply, and in the ambitious ones, the model sends it. Som...
Every AI email product shipped in the last two years has the same architecture, and it is the wrong one.
The model reads your mail. The model decides what matters. The model drafts a reply, and in the ambitious ones, the model sends it. Somewhere in the system prompt there is a paragraph asking it politely to check with you first.
That paragraph is the entire safety story. That is the bug.
The bug is not that models hallucinate
Everyone knows models hallucinate. That is priced in. The bug is subtler and worse: these systems give the model authority, then try to constrain it with instructions.
Instructions are input. Your email is also input. And your email is written by strangers.
So the threat model is not "the model is sometimes wrong." It is: someone who wants your model to do something writes an email designed to make it do that. They do not need to breach your infrastructure. They just have to send you mail — which is a thing they are already allowed to do, by design, for free, from anywhere on earth.
Ask whatever AI inbox tool you use one question:
When it decides to hide a message from me, what artifact can I read to see why? Not a natural-language explanation the model generated afterward — the actual decision.
There usually isn't one. The decision was a forward pass. It left no trace you can audit, test, or pin.
The fix is boring and nobody ships it
Separate perception from authority.
Let the model do what models are genuinely good at: read messy text, produce a few calibrated numbers. Then let code make the decision.
In my own tool the model never picks the outcome. It scores four features per email — confidence, sender trust, reversibility, urgency — and a deterministic, unit-tested rule maps those four numbers to exactly one of five lanes: interrupt me now, it's scheduling, queue it, file it as a record, or never render it. That rule is about 200 lines. You can read it. A test pins it. If its behaviour changes, CI fails.
Two things fall out of that split, and they are why I think this is a correctness argument rather than a style preference:
A cheap model beats an expensive one. On a committed 50-email eval set, gemini-2.5-flash scores 88% against gpt-4o's 82%, with 100% recall on urgent mail. Not because the small model is smarter — because the job is narrow enough that frontier reasoning buys nothing. When you ask a model to decide, you need brilliance. When you ask it to score four things, you need consistency. Different purchases, and one is much cheaper.
It degrades instead of breaking. With no LLM at all — provider down, rate limited, key expired — a keyword path produces the same four features and the system still classifies at 78%. Everything gets worse. Nothing gets dangerous.
Automation is not a lane
This is the part people get wrong when they copy the pattern.
Classification and delegation are separate decisions, and collapsing them is how "it sorted my mail" becomes "it answered my mail." A lane says what a message is. A separate flag says whether this particular message is even eligible to be answered unattended — reversible, high confidence, trusted sender, not urgent. And a separate account-level mode says whether unattended answering is on at all.
Three switches, not one. You can be wrong about the lane and still not be wrong about the outbox.
Approval has to bind bytes, not intent
The classification half is the easy half. The hard part is the three actions you cannot take back: send, permanent delete, forward.
Most tools gate those behind a confirmation dialog. That is theater, because what you confirmed and what executes are connected by nothing but hope.
So: approving mints a receipt — a sha256 over the exact canonical payload bytes at the moment you click yes. At execution the bytes are hashed again and compared. Any drift and it fails closed. No send, no delete, no forward.
The check does not live in the prompt. It lives in the execution path. There is no phrasing that gets around it, because the thing doing the checking cannot read English.
That is the difference between a safety policy and a safety property.
The part where I make this falsifiable
Claims like these are cheap, so here is mine, stated so you can break it:
Given an inbound message crafted to maximize model confidence, no path exists from classification to an executed irreversible action without a human approval that byte-pins the payload.
Note what that does not say. It does not say the model can't be fooled — it can. It does not say the lane will be right — a hostile message may well land in PUSH. That is a nuisance, not a breach. The floor is not a better classifier. It is a smaller blast radius.
The repo's SECURITY.md lists nine claims like that one, and for each: what would disprove it, and which test enforces it. It also names what has no authority — including my own accuracy numbers. A 94.3% classification score is not a safety argument, and I would rather say so myself than let it quietly stand in for one.
It also lists what is missing. There is no end-to-end adversarial corpus yet — fixtures that start from a hostile email and assert containment across the whole path. That gap is written down in the repo, not hidden.
So
If you use anything with an LLM near your inbox, go find out how it decides. If the answer is "the model decides, and we told it to be careful," you are trusting a probability distribution with your outbox.
You do not have to use mine. It's AGPL, self-hostable, docker compose up -d with prebuilt images, and it runs against a local model if you want nothing leaving your machine at all. But whatever you use — make it show you the decision.
Six months solo, 101 releases, ~1,590 commits. If you think the architecture is wrong, the fastest way to prove it is a PR that breaks the claim above. I'll merge it.
github.com/k08200/klorn