Nobody's real problem is reading email. The problem is making the same six decisions a hundred times a day: is this urgent, whose is it, does it need a reply, what does that reply say, does it touch money or a contract, and can I ignore it until Thursday.
Every one of those decisions is cheap on its own and expensive in aggregate. That's exactly the shape of work an AI worker handles well - high volume, low ambiguity per item, a written rule connecting input to output. And it's exactly the shape of work people keep trying to solve with a smarter email client, which fails, because the bottleneck was never the interface.
Here's the workflow, the boundary where it has to stop, and the parts that will bite you if you treat them as configuration details.
Inbox triage is five jobs, not one
You can't automate "triage" because it isn't a task. Break it up:
- Classify. What kind of message is this? Invoice, support request, sales enquiry, internal FYI, vendor noise, recruiter, legal notice.
- Prioritise. Does it need action today, this week, or never.
- Route. Who or what system owns it. A person, a queue, a ticket, a CRM record, a folder that nobody reads.
- Prepare. Draft the reply, extract the fields, attach the context the human would otherwise go hunting for.
- Escalate. Flag the ones the rules don't cover, and say why.
Only the first four are automatable end to end. The fifth is the entire safety design, and it's the one most implementations bolt on last.
The workflow map
This is what a deployed inbox triage worker actually runs, per message:
Stage 1 - Ingest. Message arrives. The worker reads it via a scoped mailbox connection, not by logging in as you. It captures sender, thread history, attachments, and whether this sender or thread has been seen before.
Stage 2 - Classify with a confidence score. The classifier assigns one category from a closed list you defined, plus a confidence value. A closed list matters. Open-ended classification produces new categories every week and quietly destroys your routing rules.
Stage 3 - Enrich. Look the sender up. Existing customer? Open ticket? Outstanding invoice? Named in an active dispute? Enrichment is what turns "this is a support email" into "this is the third support email from a customer whose renewal is in eleven days."
Stage 4 - Route. Category plus enrichment determines destination: create the ticket, update the CRM record, forward to the owner, file it, or drop it in the human review queue.
Stage 5 - Prepare the draft. For categories where a reply is expected, the worker writes one from known context and known templates, and leaves it as a draft. Not sent. Drafted.
Stage 6 - Log. Every decision - inputs, category, confidence, rule applied, destination, draft text - written to an append-only record.
Stage 7 - Escalate or complete. If any escalation trigger fired, the message goes to a human with the reasoning attached. Otherwise it's done.
Notice what's missing. The worker doesn't send third-party email on its own authority in the default configuration. It classifies, routes, prepares, and stops. That's not timidity - it's what makes the thing deployable in week two instead of month six.
The escalation boundary
The boundary is one sentence: the AI worker handles messages that match a defined rule at high confidence; a human handles everything else, and "everything else" is loud, not silent.
Four triggers, and they're non-negotiable:
1. Low confidence. Below your threshold, it escalates. Set the threshold high at first and walk it down as the log tells you where it's actually reliable. Everyone sets it too low on day one because a big review queue feels like failure. It isn't - it's the calibration data.
2. Consequence class. Some categories escalate regardless of confidence. Anything touching money, contracts, legal notices, personal data requests, terminations, or complaints from a named account goes to a human even if the classifier is certain. Confidence is about what the message is, not about what happens if you're wrong.
3. Novelty. New sender domain, unseen thread pattern, a message that doesn't fit any closed category. Novel isn't the same as low-confidence - a model can be confidently wrong about something it has never seen.
4. Anything requiring a promise. Dates, prices, scope, commitments. Draft it, don't send it.
The failure mode you're protecting against isn't the AI worker doing something dramatic. It's the AI worker doing something reasonable-looking to four hundred messages before anyone notices the rule was wrong. Escalation exists so the blast radius of a bad rule is one message, not a quarter.
Permissions are the implementation, not a checkbox
An inbox is the highest-privilege surface in most companies. It contains contracts, credentials, personal data, and every password reset link in the business. Giving a system access to it deserves more thought than clicking "Allow."
Minimum bar for a deployment we'd sign off on:
- A dedicated service identity, not a shared human login. You need to be able to see what the worker did versus what a person did, and you need to be able to revoke it in one action.
- Least-privilege OAuth scopes. Read, label, and draft. Send permission is granted per category, deliberately, after the review queue shows the category is safe - not by default.
- Delegated mailbox access over credential sharing. No password in a config file, ever.
- Explicit exclusions. Folders, labels, or senders the worker never reads. Legal, HR, and anything under an active dispute or NDA should be out of scope on day one, and revisited only with a reason.
- Data handling written down. What's retained, where, how long, and whether message content leaves your tenancy. If you're in the EU or handling health or financial data, this is the part your DPA hangs on. Answer it before the build, not during a security review that stalls the project for six weeks.
Most stalled AI email projects don't die on accuracy. They die in a security review that nobody prepared for.
The audit trail is the deliverable
If you can't reconstruct why a message went where it went, you don't have an automated workflow. You have a black box that occasionally embarrasses you.
Log, per message: what arrived, what the worker classified it as, the confidence, which rule fired, what enrichment it pulled, where it routed, what it drafted, whether it escalated and why, and what the human did next. Append-only, retained as long as the underlying business records, queryable.
That log does four jobs. It's your evidence when a customer says nobody replied. It's your training data for tightening the rules. It's your answer in an audit or a dispute. And it's how you tune the confidence threshold with numbers instead of a hunch about how it feels.
Systems that only log errors tell you nothing about the ninety-eight percent of decisions that quietly went the wrong way.
Three ways this goes wrong
Category drift. Your business changes, a new message type appears, and the classifier keeps forcing it into the nearest old bucket at high confidence. Symptom: a category slowly swelling for no reason. Fix: review category distribution weekly, treat a shift as a signal to add a category, not to retrain blindly.
Silent routing failures. The downstream system rejects the handoff - ticket API times out, CRM field validation fails - and the message evaporates. Every route needs an acknowledgement and a dead-letter queue that a human actually watches. This one is boring and it's the one that loses customers.
Review-queue collapse. Escalations pile up, nobody triages the triage, and someone starts approving in bulk to clear it. Now you have the appearance of oversight and none of the substance. If the queue is consistently too big, the rules are wrong - fix the rules, don't lower the bar.
What to measure in the first 30 days
Not time saved. You won't have a clean baseline and any number you produce will be a story you told yourself.
Measure these instead:
- Coverage - share of messages handled without escalation.
- Escalation precision - of escalated messages, how many genuinely needed a human. Too high means your threshold is too loose; near zero means it's too tight and you're taking risk you can't see.
- Correction rate - how often a human changes the category or rewrites the draft substantially.
- Draft acceptance - how many prepared replies go out roughly as written.
- Time to first touch - the one latency number that actually matters to the person who emailed you.
After thirty days of that you can make an honest cost argument. Before thirty days, anyone quoting you a percentage is selling.
When not to do this
Skip it if your inbox volume is genuinely low - fifteen decisions a day is an annoyance, not a bottleneck. Skip it if every message really is different; unstructured, judgment-heavy correspondence is human work and pretending otherwise produces confident nonsense. Skip it if nobody will own the review queue, because unowned oversight is worse than none - it manufactures a false sense of control.
And skip it if you can't write down your routing rules today. If a human can't articulate the decision, a machine can't either. That's a process problem wearing an AI costume.
How we deploy it
Leverwork builds this as a role, not a tool you have to operate: scoped mailbox access, a closed category set derived from your actual last-90-days mail, routing into the systems you already run, drafts prepared for review, escalation rules agreed in writing before go-live, and a queryable log from day one.
We start with read, label, route, and draft. Send permission gets granted category by category, once the log earns it.