What AI features can a modern developer-built email inbox have?

A developer-built inbox can run a chat agent over your mail, LLM triage rules that sort by intent, a thread summarizer, RAG over your archive, smart compose and reply drafting, auto-labeling, snooze and scheduling, email-to-task automation, an MCP server for external assistants, and FTS5 full-text search underneath it all. The key difference from a closed inbox is that each feature is a tool you define, test, and own, running on your own account rather than a vendor's. Tinbox ships these on Cloudflare D1, R2, and Workers behind npx tinbox init.

Do I need machine learning experience to add AI features to an inbox?

No. Most of these features are an LLM API call plus a typed tool definition and a place to store the result. Classification, summarization, and drafting are prompt-and-schema work, not model training. The harder parts are the plumbing every developer already knows: a database for messages, a search index for retrieval, and a queue for background jobs. If you can call a REST API and write a SQL query, you can wire up an AI inbox.

Can these AI inbox features run without sending my email to a third party?

The storage, search index, and retrieval all run in your own account, so your raw mail never leaves. What leaves on each call is the specific prompt plus the snippets you choose to send to the model, and you can route that to a private or local model if you need zero third-party exposure. You decide what crosses the wire, per call, instead of handing your whole mailbox to a cloud assistant.

Which AI inbox feature should a developer build first?

Build full-text search first. Almost every other feature (triage, RAG, the agent, summarization) needs to find the right messages before it can act, so a solid FTS5 index in SQLite is the foundation everything else stands on. After that, an LLM triage layer on inbound mail gives the highest visible payoff for the least code.

10 AI Inbox Features Every Developer Should Know About

An AI inbox is not one feature, it is a stack of small, typed capabilities sitting on top of a database of mail. Here are ten that a developer can actually build, what each is for, and where to read how it works.

The interesting thing about AI on email, from a builder's seat, is how little of it is exotic. A chat agent is a few typed tools over your message store. Triage is an LLM call plus a label column. RAG is search plus a prompt. Once you see the inbox as a programmable surface, the features stop being magic and start being a checklist. Here are ten worth knowing, each one a thing you can wire up yourself on infrastructure you control.

1. A chat agent that operates the inbox

A chat agent turns your mailbox into something you can give orders to, not just click through. You type "find the contract thread with Acme and draft a reply confirming the June date," and the agent searches, reads the relevant messages, and writes a draft. Under the hood it is an LLM with a set of typed tools (search, read, draft, label) and a loop that lets it chain them. The reason this matters for developers is that you control exactly which tools exist, so the agent can do precisely what you declared and nothing more. For the architecture and how the agent reasons over messages, see building an AI email agent over your inbox.

2. LLM triage rules driven by intent

The single highest-payoff feature is a classifier that runs on every inbound message and sorts by what it means. Keyword filters break the moment a sender rephrases; an LLM reads "I still have not received my refund and I am done" and routes it to the complaints queue without a matching rule. The pattern that keeps cost sane is hybrid: cheap algorithmic rules catch the obvious cases (a code that matches a regex, a known sender), and the model handles the ambiguous ones where intent beats keywords. A scannable menu of rules to copy is in AI triage rules that tame a busy inbox.

3. A thread summarizer

A summarizer earns its keep the first time it collapses a 40-message reply chain into a paragraph. Long threads are where context goes to die: someone loops you in on message 31 and you are expected to know the history. The feature reads the chain and returns the gist plus the open action items. As a build, it is one of the simplest on this list: gather the messages in a thread, send them to the model with a tight prompt, store the result keyed to the thread. The full walkthrough is in summarizing long email threads with AI.

4. RAG over your archive

Retrieval over your own mail is the difference between a grounded answer and a confident guess. Ask a raw model "what shipping dates did we agree on with this vendor" and it invents something plausible. Wire it to retrieval over your archive and it answers from the actual thread, citing the message it pulled from. You do not need an exotic vector stack to start: full-text search plus optional embeddings retrieves the right messages from the same database that stores them. See running RAG over your email archive for the retrieval setup.

5. Smart compose and reply drafting

Drafting is the lowest-risk place to put AI to work, because a human still hits send. Generate a reply from the thread context, propose three subject lines, expand a one-line note into a full message: each is a prompt against the conversation plus a draft saved to the database, never an autonomous send. The guardrail that makes this safe is the boundary itself: drafts are drafts, and the send action is a separate, reviewable step. Pair this with the agent from item 1 and you get suggested replies that already know the thread's history.

6. Auto-labeling and tagging

Labels are where triage becomes durable: a verdict written to the message, not just a one-time routing decision. Once an interpreter decides a message is a receipt, a complaint, or a hot lead, that tag should persist so the inbox can filter, the agent can reason over it, and your analytics can count it. The build is a classification step plus a tags column (or a join table) and an index so you can query by label fast. This is also where a typed schema pays off: a fixed set of labels keeps the model from inventing a new category every Tuesday.

7. Snooze, schedule, and follow-up reminders

The inbox should be able to make a message disappear until Tuesday and come back if no one replied. Snooze, scheduled send, and "remind me if this gets no response" are small features with outsized daily value, and on a Cloudflare stack they map cleanly onto Cron Triggers and a queue rather than a standing server. A scheduled-time column plus a periodic sweep that resurfaces or re-sends is the whole mechanism. The AI angle is letting the agent set these: "snooze anything from this sender until I am back" becomes a tool call instead of a manual rule.

8. Email-to-task automation

Inbound mail is a trigger, and turning it into a task or a webhook is where the inbox stops being a place you visit and starts being plumbing. A support email becomes a ticket, an invoice becomes a row in your billing system, a signup becomes a webhook to your app. The interpreter decides what kind of message it is, and a typed action fires the side effect. This is the feature that replaces a pile of Zapier zaps with code you own. The patterns are laid out in turning inbound email into automated tasks.

9. An MCP server for external assistants

An MCP server is how you let Claude or ChatGPT touch your email through a door you control. Model Context Protocol exposes your inbox as typed tools that an external assistant can call, instead of handing it a raw API key. You decide which tools exist, the server runs on your account, and every call goes through your scoping and audit log. Authentication can be OAuth for a one-click consumer connect or a static bearer token for a CLI or backend. The win for developers: the same tool definitions back the chat agent, the MCP server, and any CLI, so there is one allowlist to reason about.

10. Full-text search as the foundation

The unglamorous feature that every other one leans on is fast full-text search. Triage, RAG, the agent, summarization: each has to find the right messages before it can act, and that retrieval layer is SQLite's FTS5 virtual table, running in the same D1 database that stores your mail. No separate search service, no syncing a second index, no egress. Get this right and the rest of the list has something solid to stand on; get it wrong and the agent feels slow and dumb because it cannot find anything. The build is in adding FTS5 full-text search to your email database.

Putting the inbox to work

The honest version: a polished closed inbox will feel more finished out of the box, and for a throwaway personal account that may be the right call. Where building your own wins is when the mailbox is the asset, when you want a tool the vendor will never ship, and when "where does this data go" needs a real answer. The features here are the ones Gmail's smart inbox will not hand you, and seeing them in one place is the fastest way to decide which to build first. None of these ten features requires a research team. They require a message store, a search index, a queue, and a willingness to define each capability as a typed tool you can test. Start with search, add triage, and grow from there.

Deploy your own email stack: npx tinbox init <domain>. The scaffold wires the agent, triage interpreters, retrieval, summarizer, and FTS5 search onto your Cloudflare account in one deployable Worker, so your mail and data never leave your account.