AI That Reads Your Inbox Without Sending It Anywhere

Context

“Let AI sort your email” is an easy sell and a hard one to accept. For a law office, a medical practice, a recruiter, or anyone whose inbox contains other people’s private business, the answer to “so where does my mail go?” decides whether the project happens at all. If the honest answer is “to a third party’s servers,” a lot of businesses stop listening — correctly.

So the design constraint here was set first and treated as non-negotiable: the mail never leaves the machine.

The trade-off is real and worth naming. A cloud model is stronger, and a companion project of mine deliberately uses one for a different inbox where the content is my own and the better summariser is worth it. This one takes the weaker local model on purpose, because for confidential mail the constraint is the feature.

The approach

Local model, local database, local index. Messages are pulled into a local SQLite database. Summarisation runs against a model hosted on the same machine. Search is a full-text index in that same database. There is no API call carrying message content to a vendor, because there is no vendor in the content path.

The ranking is a config file, not a black box. Items are scored on topic relevance, accessibility, content quality, technical density and source reliability — with the weights in a YAML file the owner can open and edit. When someone asks “why did it rank that first?”, the answer is a file you can read together, not a shrug.

That matters more than the model choice. An automated ranking nobody can inspect gets overridden by hand within a fortnight, at which point you have built a very expensive sorting hat. One with visible weights gets tuned instead, and tuning is how it survives contact with a real inbox.

A pipeline with separable stages. Drain, discover, score, browse — each runnable independently from the command line. When something looks wrong, you can re-run one stage against existing data instead of re-fetching everything. Debugging a five-stage pipeline you can only run end-to-end is how a working system becomes an unmaintained one.

Layered so the parts can be swapped. Domain models and interfaces are separate from the infrastructure that implements them: the mail source, the storage, the model client. The local model is a choice made behind an interface, which is what makes “keep it local” a constraint the architecture enforces rather than a promise someone remembers.

Result

A full ingest, score, search and summarise loop over a working inbox, where the only outbound call is the one that fetches the owner’s own mail. 442 commits and 166 modules, with 46 test files covering the pipeline.

The sellable point is not the model. It is that “where does my data go?” has a one-word answer, and the architecture is what makes that answer true — not a policy page. For a small business weighing an automation against its confidentiality obligations, that is usually the whole decision.