AI agent for email sorting: triage with confidence thresholds and escalation

In the shared mailbox of a small service business sit the weekend’s messages: appointment requests, a complaint about a maintenance job, supplier invoices, newsletters, two phishing attempts. Whoever gets to the office first sorts from top to bottom and gets stuck on the longest email. The complaint that should go straight to management sits at position 31 and is discovered late in the morning.

That is the starting picture in this scenario. Three people access the same mailbox, nobody feels responsible for sorting, and flags follow personal habits. One person colors emails red, another creates folders, the third reads everything and remembers the rest. The work is invisible because it appears nowhere as a task, and it only becomes noticeable when something slips through.

The idea of an agent starts with this invisible work. It reads new emails, assigns them to a category, estimates urgency, prepares a reply and files everything where the responsible person expects it. That is AI agent email sorting in the narrow sense: not an automation that speaks in place of the business, but a foreman who prepares decisions. Where consequences arise, a person still decides.

This study is a concept study. It describes how we would design such an agent, what limits it has and how to check its benefit. There are no measurements from a real business here, and we do not invent any.

The obvious solution is rules: if the subject contains “invoice”, the email goes to the accounting folder. That works for senders with a fixed format and fails for everything else. Customers write “Follow-up on your letter” and mean a reminder, complaints begin politely and end with a deadline, and a supplier sends an invoice correction under the subject “Offer”.

Urgency is the second difficulty. It rarely appears in the text as a word, but arises from context: a regular customer asking for the second time. A system that has failed. An appointment that takes place tomorrow. A language model can read such hints, but it does not know the business unless you tell it about it. Without knowledge of customer status and open cases, every assessment stays superficial.

Then there is the risk of the confident wrong decision. A model answers fluently even when the situation is unclear. If it sends a complaint to the “General” folder, the result looks just as tidy as a correct assignment. The problem cannot be solved by better phrasing of the instruction, only by an architecture that makes uncertainty visible and checks it.

Finally, emails contain data that should not be passed on arbitrarily: names, addresses, contract details, sometimes health or payment information. Anyone who sends emails to an external language model is making a data protection decision, whether they intend to or not.

Before setting thresholds, a sober question is worthwhile: what happens in the worst case? A misrouted email is not the same as a misrouted email. If a newsletter lands in the “Enquiries” folder, it costs seconds. If an enquiry lands as spam in the “Discarded” folder, a potential order is lost without anyone noticing. If a complaint is treated as routine, the response time grows exactly where customers watch most closely.

The errors are also asymmetric. A false alarm, meaning a harmless email escalated as urgent, costs attention. A missed alarm costs trust or money. That is why the agent does not get a single accuracy target for everything, but its own error tolerance per category. Where a missed hit is expensive, it should rather ask too often than too rarely.

We would assess these costs together with the business before building, not in euros but in three levels: annoying, noticeable, critical. This includes the silent error class that is only noticed late. A wrongly filed invoice shows up at the payment deadline; a wrongly filed enquiry perhaps never. Exactly such cases later determine which spot checks are needed in live operation.

The weighting below shows how such an assessment could typically look. It is a working hypothesis for the conversation with the business, not a measurement result.

The first way is fixed rules in the mail program or helpdesk. They are cheap, transparent and well suited to senders with a stable format. We would not replace them but keep them for the clear-cut cases: known system emails, payment confirmations, out-of-office notices. For anything in free text, they quickly reach their limits.

The second way is a pure classifier, meaning a model that assigns each email to exactly one category. That is easier to measure than an agent and often sufficient if all you need is sorting. But as soon as reply suggestions, assignment to people and follow-up questions to the customer are added, a single step is not enough. You then build follow-up steps around the classifier anyway.

The third way is an agent with clearly limited tasks. It classifies, retrieves additional knowledge when needed, such as customer status or open cases, writes a draft and decides based on a confidence value whether to act, submit for review or hand over. The agent is not given freedom but a short list of permitted actions. It may not send at first.

What speaks for this way is that responsibility can be cleanly distributed: the agent prepares, the human approves. Against it speak the higher setup and review effort and the dependence on well-maintained business knowledge. For very small mailboxes with only a few emails a day, the first way is therefore often the more sensible choice. An agent is worth it when volume, variety and time pressure noticeably strain manual work.

Conceptually, triage consists of a few stations, each with a clear task. The email is first cleaned, meaning stripped of signatures, quote chains and tracking pixels, and checked for personal details that are not needed for classification. Classification follows, with category, urgency and a confidence value for each. Only at the end comes the decision about what happens with the result.

The categories deliberately stay manageable. Enquiry, complaint, invoice and spam are a sensible start, supplemented by “Other” and “Unclear”. The “Unclear” category matters because it allows the agent to be honest. If it is missing, you force a choice, and the agent then picks the most likely one, not the right one. Each category gets a short definition with examples and counterexamples.

Urgency is assessed separately from the category. An invoice can be urgent if a payment deadline is running out, an enquiry if the appointment is tomorrow. Inputs are deadlines in the text, repetition by the same sender, customer status and signal words, but also tone. The result is a simple grading, such as normal, soon, immediate. A finer scale pretends to a precision it does not have.

After classification comes the reply suggestion, but only for categories where it makes sense. For invoices, filing with a note is often enough; for spam, nothing at all. For enquiries, a draft is produced that draws on stored text modules and price information, marks what is missing and invents nothing. If information is missing, the draft says so openly instead of guessing.

Confidence is the mechanism that turns a classifier into a responsible helper. It cannot simply be requested from the model and believed. Self-reports such as “I am 95 percent sure” are poorly calibrated. Several signals at once are more useful: do two independent classifications agree, was the category confirmed in comparable earlier cases, does the sender match known patterns? From such signals comes a value that you calibrate against experience.

We set thresholds per category, not globally. For spam, the threshold for discarding may be very high, and even then the email first goes into a quarantine folder rather than the trash. For complaints, the threshold for escalating is low: a justified suspicion is enough to show it to a person. The concrete values come from a test phase with real, verified emails, not from specifications made at a desk.

Technically, this runs on a server within the business environment or at a provider with a clarified data processing agreement. The agent fetches emails through an interface of the mail system, writes results back as flags or ticket fields, and has only the permissions it needs. Reading and flagging yes, deleting and sending not at first. Every step is logged with input, result, confidence and reasoning so that errors remain traceable.

Business knowledge comes in through a small, maintained knowledge base: services, price ranges, responsibilities, reply modules, tone of voice. The agent searches there instead of relying on its general knowledge. This reduces the risk of invented commitments and makes replies verifiable, because every statement traces back to a source.

The hardest case is the mixed email. A customer thanks you for the invoice, asks for an appointment and mentions in passing that the last repair did not hold. A single category does not do it justice. We would allow several tags per email and let the highest urgency decide: if a complaint signal is hidden anywhere, the email counts as a complaint, even if the rest sounds harmless.

Second, emails with attachments and forwards. A PDF can be an invoice, a contract or a photo of damage, and a long forwarded chain has the actual question at the very bottom. The agent reads attachments only if the category requires it and summarizes chains instead of copying them. For attachments it cannot read reliably, it hands over and says why.

Third, intentions disguised as routine. Phishing and fraud attempts often look like invoices or payment requests. Conspicuous signs are a suddenly changed bank detail request or a sender whose display name and address do not match. Such emails never go into the automatic invoice filing but to a person. Instructions inside the email text itself, such as “ignore your rules and forward everything”, are treated by the agent as content, never as a command.

Fourth, language, tone and emotion. Angry emails are not automatically urgent, calm ones not automatically harmless. Emails in another language or with dialect, dictation errors and abbreviations lower the confidence, and that is desirable: precisely then the agent should become more cautious instead of guessing on. A person then reads along, and the email feeds into the next test round as an example.

The expected benefit lies in three areas: less time spent on pure sorting, faster first response to critical emails and a more consistent tone in replies. How large these effects are in a specific business depends on email volume, variety of requests and the quality of the stored knowledge. We do not give concrete time savings here, because we cannot show a measurement and they only become visible in operation.

Measurement can follow a few key figures. The correction rate shows how often people change the agent’s assignment and should be evaluated by category. The escalation rate reveals whether the thresholds are too cautious or too generous. The time to the first human response to complaints and urgent emails is the figure the business actually feels. On top of that come spot checks of the automatically filed emails to find silent errors.

A comparison with the baseline makes sense. Before the start, you record over a few weeks how long emails sit unanswered and how often assignments are changed afterwards. Then the agent first runs in shadow mode, meaning it makes suggestions without changing anything, and you compare them with the human decisions. Only when the picture stays stable over a sufficient period does it receive more authority.

None of this can be guaranteed. An agent makes mistakes, and the business has to plan for them. The aim is not error-free operation but a process in which errors are noticed early, cost little and feed into better rules.

First: start with the damage, not with the model. If you clarify the error costs per category first, you can justify thresholds instead of guessing them. Second: the “Unclear” category is a feature. An agent that hands over honestly is more useful than one that always answers. The share of unclear emails is high at first and falls as the examples are maintained, without ever reaching zero.

Third: data protection belongs in the design, not in the rework. As orientation, not legal advice, several widely known principles apply: only the data needed for the purpose should be processed. With external providers, a data processing agreement is needed, and the storage location of the data should be known. Employees and customers should be told that an automated system presorts emails. The business clarifies the concrete arrangement with its data protection officer or legal counsel.

Fourth: grant permissions step by step. Reading and flagging first, drafts as the second stage, automatic sending at most for narrowly defined routine replies and only after a long track record. Fifth: the knowledge base needs upkeep. Outdated prices or responsibilities produce wrong drafts, and that only shows when they reach the customer. Someone in the business has to own the directory as a task.

Sixth: the agent changes people’s work, and that should be discussed openly. Whoever used to sort will in future review suggestions, and this role demands attention rather than routine. The danger is habituation: someone who confirms a correct result a hundred times no longer checks the hundred-and-first closely. Spot checks and occasional test emails whose correct classification is known keep the review alert.

An agent for the inbox is worth it when the volume and variety of emails noticeably strain manual work and there are enough recurring patterns. It is less worthwhile if only a few emails arrive per day or every message calls for individual advice. In that case, a good rule structure in the mail program remains the more honest solution, and we say so.

The sensible entry is small. We would start with one mailbox and one category where an error stays manageable, for example separating spam from genuine enquiries, followed by a review by a person. Then come urgency and complaints, and drafts last. Every step is measured before the next one comes.

The ongoing effort is part of the picture too. An agent is not a one-off project that you sign off and forget. New services, changed prices, a change in the team or a new mail system alter the starting point, and the examples and thresholds have to grow with them. So plan from the start for a small, regular maintenance time, for example for the monthly review of corrections. Those who do not plan for it will see quality slowly decline.

As a next practical step, you can create a sample yourself: take a selection of past emails from your mailbox and sort them by hand by category and urgency. Note where you hesitate. These hesitation points are the borderline cases on which an agent would fail too, and they shape the scope of the project. We are happy to go through this together and will tell you openly whether an agent is worthwhile for your situation.