IMAP triage
Sorting company mail and drafting replies
In the morning it is clear what is on fire. The agent sorts the NOC, CSIRT, billing and sales mailboxes and drafts replies to selected messages. It cannot send them.
The problem
Operational mailboxes receive dozens of messages a day: alerts, incident reports, invoices, enquiries. An important message gets lost among automated notifications, and a reply to a routine question waits until someone gets to it.
How it works
- 1
Find new messages
Searches IMAP for messages it has not processed yet. Its own IMAP client over TLS, no PHP extension needed.
- 2
Deterministic pre-filter
The spam score, the List-Unsubscribe header and known senders file a large part of the mail without a model.
- 3
First pass with a local model
A cheap local model sets the category and writes a summary. The output is JSON against a schema, not free text.
- 4
Second pass for selected categories
Messages that matter get a more careful second pass, and a draft reply is created if the mailbox’s rule says so.
- 5
Label and draft in the mailbox
The message gets an IMAP label and the draft goes to Drafts. A person always sends it.
- 6
Run summary
An overview of what arrived and what is urgent goes to the mailbox or a Mattermost channel.
Guardrails
- The service has no access to sending mail. It physically cannot send an e-mail, only save a draft.
- The message content enters the prompt fenced off as untrusted data.
- Double duplicate check: local state and an IMAP label. Saving a draft is never retried automatically.
- The summary is stripped of formatting, mentions and line breaks, so it cannot tag anyone or become its own input.
- For incident reports, drafts are deliberately not prepared.
- Dry-run mode and a message limit for first runs.
The model’s confidence is useless; it almost always reports 1.00. So the second pass is triggered by category, not by how sure the model is.
More case studies
GitLab triage
A daily issue digest for developers and teams
Every morning, what changed in GitLab and what is expected of whom. Code builds the sections; a local model only adds summaries. Client data never sees the cloud, and code enforces it.
Day digest
A morning overview from company systems
One e-mail before the day starts: calendar, tasks, mail, GitLab and Mattermost. The agent calls no model itself; it assembles the output of the other agents.
Delegator
Assigning tasks in plain text in chat
You tell a Mattermost bot what needs doing and who should do it. The model proposes a task, code checks the assignee and deadline, you confirm with a thumbs-up. Then the bot watches how the task goes.
Expense hub
Re-billing company expenses
Statements for fuel, phones, insurance and internet arrive by e-mail and end up as an overview for each holder. No model: the parsers are deterministic and the totals match to the cent.
No-obligation consultation
Let’s find the first job for AI in your company.
An hour’s conversation about where your data lives, which processes slow you down and what of it may leave your network. You leave with a proposal for a first pilot, not a tool demo.
Built and is accountable for the AI layer at Nux
Radek Růžička
Managing Director and CTO, Nux s.r.o.