We check our email through the day, and we still come back to dozens of unread messages. Most of them are low impact: a receipt, a password reset, a newsletter, a notice that a report is ready. Each one takes only a few seconds, but opening them one by one is a slog, and it happens several times a day. Worse, the message that matters, such as a client asking for a call, sits in the same list and waits its turn.
We looked at two years of our company email to see how big the problem was. More than half of it, 54%, was automated mail: receipts, alerts, newsletters and account notices.
So we built email triage into Kai, our internal operations platform. It sorts new mail every five minutes on weekdays, from 8:30 am to 6:30 pm.
The AI's job is to find the rules
The obvious design is to send every message to an AI model and let it decide. We did not do that. Most of our mail comes from the same senders again and again, and a receipt from a vendor looks the same every month. Asking a model about it every time is slow, costs money and gives a slightly different answer each time.
So the AI's main job is to look at mail that no rule covers yet, and work out which rule would handle it next time. Once a rule exists, messages from that sender never reach the AI again. We now have about 750 rules. In the last 30 days, rules sorted about 90% of our mail, and the AI saw the rest.
What happens to each message
Every message gets one of four outcomes:
- Archive. Low-value mail: marketing, sales pitches from vendors, surveys, product announcements and plain notifications. The message leaves the inbox, is marked read and gets a label, such as Newsletter, so it is easy to find later. Nothing is deleted. Archived receipts still show up in the daily briefing as one short line, with each vendor and amount.
- Summarize (read, kept). Mail you want to know about but do not need to open: receipts you keep for records, payment confirmations, delivery notices, appointment confirmations and statements. The message stays in the inbox, marked read, so it does not add to the unread count, and it appears in the daily briefing summary.
- Leave alone. Anything that asks us to do or decide something, and anything a real person wrote to us, including every client. The message stays in the inbox, unread, for a person to see.
- Urgent. Words such as "action required" or "please review and sign" in the subject. The message stays in the inbox and is flagged as urgent.
In the last 30 days, that came to about 780 messages archived, 310 summarized, 525 left for a person and 15 flagged as urgent.
The hard part is not sorting the easy mail. It is making sure the system never hides a message a person needed to see. Our rule for that: decide which mistakes you could not undo, and put those decisions in code, not in a prompt.
Written rules decide first
A rule matches a sender's address, a sender's domain or words in the subject line, and it names one of the outcomes. When several rules match, the most specific one wins. A person can read, change or turn off any rule.
A message goes to the AI model only when no rule covers it. The model reads the sender, subject and body, and returns an outcome, a confidence score from 0 to 1 and a one-sentence reason.
The model is set up to fail safely:
- Below a confidence of 0.6, it changes nothing. The message is left alone.
- If the call to the model fails, the message is left alone.
- Its instructions say that when in doubt, it should keep the message in front of a person. Archiving something important is far worse than one extra unread message.
If you are automating an inbox, start with rules. They cost nothing to run, and anyone on the team can read them. Then tell the model which way to fail: when it is unsure, it changes nothing.
The AI writes a rule only with evidence
When the model is very sure about a message (0.85 or higher), its verdict can become a new rule, so the next message from that sender skips the model. Two limits apply.
One address, never a whole domain. A large company can send automated receipts and a real person's support reply from the same domain. So a learned rule covers one exact sender address. Only a person writes a rule for a whole domain.
Two separate messages must agree. The rule is written only when a second message from the same address gets the same verdict. One email, however it is worded, cannot write a permanent rule about itself.
A decision about one message is easy to undo. A rule applies to every message after it, so it needs more evidence.
Checks in code protect people's mail
The model judges a message by its text, and text is where a personal note and a marketing email look most alike. A note from an event organizer to three named panelists can read like a promotion.
So a few checks run after the model, in code. They can only keep a message in front of a person. They never archive anything.
- Someone we have written to. The message is kept, marked read. If the lookup fails, we treat the sender as known.
- A note to two or more people with no sign of bulk mail, such as an unsubscribe link. The message is kept, marked read.
- A client contact as the sender or on copy. The message is never archived or marked read, whatever a rule or the model says.
- Urgent words in the subject, such as "action required" or "please review and sign". The message stays in the inbox, flagged as urgent.
When a check overrules the model, that message is never used to write a rule. The model got it wrong, so its verdict says nothing reliable about the sender.
Make your own list of the mistakes you could not recover from, such as a client's email disappearing into an archive. Write each one as a check that can only raise a message's priority. You can test checks like these, and they stay the same when you change the model.
A client's meeting request goes straight to a phone
A client asking for a call is the message we most need to see quickly, because the times they offer run out. So this path is plain code, with no AI step. When a client contact is on a message, the system looks for a scheduling request:
- Some phrases are enough on their own, such as "can we schedule" or "find a time".
- Weaker phrases, such as "your availability", count only next to a meeting word like "call" or "Zoom".
- Calendar invitations, acceptances and "please hold this time" notices do not count.
A match creates a top-priority work item and sends a phone alert that opens it. A follow-up on the same thread is added to that work item. Once we have replied, no more alerts go out, and a repeat alert waits at least six hours.
When a rule is clear and a miss is expensive, do not leave it to judgment. Write it as code, test it against real messages, and keep the model for the cases that need judgment.
A person presses Send
Every decision goes into a triage log, with the rule or model result behind it. Every fifteen minutes, our operations agent reads the messages that were not archived. It interrupts someone only for a short written list of reasons, such as a person waiting on a same-day decision. Everything else waits for the next briefing.
For a routine message it can answer with confidence, such as a request to confirm a meeting time, the agent drafts a reply. The draft appears on a card with a Send button. The agent has no tool that sends email, so nothing leaves until a person taps Send. It never drafts on legal, pricing or personnel threads, and when it is unsure, it does not draft at all.
One rule sits under all of this. Anyone can send us an email, so the text of every message is treated as data, not as instructions. The model is told so. Before a subject line or preview is saved to the log, the system removes any text made to look like it came from our system instead of the sender.
Keep sorting, deciding to interrupt and replying as three separate steps, each with its own written rules. Then make a person's tap the only way out.
Start with three lists
If your team also comes back to dozens of unread messages, most of the design starts before you choose a model. Write down three lists: the mail that written rules can handle, the mistakes you could never recover from, and who presses Send. Those lists are where our AI Workflow Review starts.
For how our agent decides what reaches a person at all, read How we cut ten alerting agents down to one. For the same approach applied to deadlines, read How to automate follow-up when deadlines slip. Everything else our agent does, and the rules it follows, is on How we run Kaizen on AI.