Guide
Triaging a full inbox with an AI, without losing anything.
Most attempts at this fail for one reason: people ask the AI to read and act at the same time. Split it into four passes and it becomes safe, because the first two change nothing at all.
- Reading About 7 minutes
- Best for A backlog, not a normal Tuesday
- Undo Passes 1 and 2 change nothing
The short version
Survey the whole inbox without opening anything. Decide your own categories. Get the plan in writing, approve it, then let it run. Check the result in your normal mail client. Nothing in the first two passes touches your mailbox, so a pass you abandon costs you nothing.
The failure mode
Why AI email triage usually goes wrong
The instinct is to say "go through my inbox and sort it out", and the result is an assistant working message by message: read one, decide, act, read the next. That loop is how a person does it, and it is exactly wrong for a machine, for three reasons that compound.
- You cannot see the plan. By the time something is clearly going wrong, forty messages have already moved, and you are reconstructing what happened from a chat transcript.
- Categories drift. Decisions made one message at a time are made without knowing what is coming, so the same kind of message gets filed two ways depending on when it was reached.
- Every action is spent before you know if it was right. There is no dry run, so the first pass is also the only pass.
The property that makes a better method possible
Reading a message through Mailbox MCP does not mark it read. That is not a
setting and it is not a courtesy, it is what the engine does: message
source is fetched with IMAP's BODY.PEEK, the fetch that is
defined not to set the Seen flag. Marking read is a different tool,
mark_read, and it runs only when you ask.
That single property is what turns triage from one irreversible pass into a survey followed by a decision. You can look at everything, twice, from three angles, and your mailbox is bit for bit where you left it.
Walkthrough
The method, in four passes
The first two change nothing. The third changes things in an order you can walk back. The fourth is done with your own eyes, in your own mail client, because that is the only check that counts.
-
Survey, without touching anything
Ask for the recent contents of your inbox as a list. Behind that,
list_emailsreturns summaries only: sender, subject, date, flags. No bodies are fetched, so nothing is opened, nothing is marked read, and two hundred messages do not become two hundred message bodies in your conversation.Ask for patterns rather than a verdict. Which senders appear most, what is repeated, what is older than a month and still unread. You are building a picture, not making decisions yet.
-
Decide the categories yourself
This is the pass people skip, and it is the one that decides whether the result is any good. Give it three or four categories, named after what you will do rather than what the message is. "Needs a reply from me this week" is a category. "Important" is not, because nothing follows from it.
Why your categories beat its categories
An assistant asked to invent buckets will produce sensible-sounding ones like Work, Personal and Newsletters. They are useless because they describe the mail rather than your intentions, and you end up re-triaging the buckets.
-
Act in batches, smallest action first
Ask for the plan as a numbered list before anything runs. Correct it, then let it execute one category at a time. Order the actions from most reversible to least:
- Flag and mark read. Instantly reversible, and they change nothing about where a message lives.
- Move. Reversible if you know the origin, which is why the plan is in writing. Flags and the original date survive a move.
- Delete. Goes to Trash exactly as clicking Delete would. Recoverable until Trash empties, which is a deadline rather than an undo.
Run one category, then stop and look
The first batch is the test. If it did what you meant on twenty messages it will do it on two hundred; if it did not, you have twenty to put back rather than two hundred.
-
Check the result in your own mail client
Open Outlook, or Gmail, or whatever you actually use, and look. Not because we expect it to be wrong, but because the whole promise of this product is that your mailbox is unchanged except where you asked for a change, and the only way to verify a promise about your mailbox is to look at your mailbox.
The unread count is the fastest check. If it moved anywhere you did not ask it to, something read a message that should have been peeked at, and we would want to hear about it.
Pass one is a survey that changes nothing, and the free tier of 5 calls a day covers it. That is the pass that tells you whether the rest is worth doing.
Worked example
What to actually type
Three instructions, one per pass. They are deliberately plain: there is no prompt-engineering trick here, the work is in being specific about what you want and explicit about not acting yet.
Pass one, the survey
List the last 150 messages in my inbox. Do not open any of them and do not change anything. Group them by sender and tell me: which senders appear more than three times, which messages are older than 30 days and still unread, and anything that looks like it needs an answer.
Pass two, the categories
Using only that list, sort every message into exactly one of: (1) needs a reply from me, (2) needs reading but no reply, (3) reference, file it, (4) nothing, bin it. Show me the plan as a numbered list with the count in each category. Do not act on it yet.
Pass three, one category at a time
Good. Start with category 3 only. Move those into the Reference folder, and tell me exactly which messages you moved when you are done. Stop after category 3.
The two phrases doing the work
"Do not act on it yet" and "stop after category 3". Both are boring, and both are the difference between a plan you approved and a plan that ran while you were reading it.
Worth knowing
What a triage pass costs in MCP calls
Worth saying plainly rather than letting you find out midway. Every tool call counts against your daily limit, and a real triage pass is not a handful of calls.
The survey is cheap: one list_emails call returns a batch of
summaries, so a few hundred messages is a few calls, not a few hundred.
The acting pass used to be the expensive one, because moving, flagging and
marking were done a message at a time. They are not any more. Every tool
that changes messages takes a set of up to 500 in a single call:
mark_read, mark_unread, flag_email,
unflag_email, move_email and
delete_email. Sorting eighty messages into four folders is
four calls, not eighty.
Measured against a real server on 27 August 2026, at 500 messages in one
call: mark_read took 340 ms, flag_email 252 ms,
move_email 187 ms and delete_email 175 ms. Ask
for 501 and the call is refused rather than quietly acting on the first
500 and reporting success, which is the failure that matters at a ceiling.
A batch that half-works is reported honestly too: the result names which
messages it changed and which it could not, because IMAP has no
transaction to roll back.
The free tier will not do this
Free is 5 calls a day per mailbox. That is enough to run pass one and see whether the survey is useful, which is exactly what it is for. It is not enough to triage a backlog, and a page that implied otherwise would be selling you something on a false premise. Pro is £2.92 a month per mailbox, paid annually at £34.99 + VAT and raises the ceiling to 1,000 calls a day, which covers a backlog pass with room to spare.
Judgement
What to keep doing yourself
Three categories where handing over the decision costs more than it saves, learned the ordinary way.
Anything where being wrong is expensive and quiet
Invoices, contracts, anything legal, anything from your accountant. Not because an assistant sorts them badly, but because a misfiled invoice is not noticed until the point at which it matters, and by then the trail is cold.
Mail from people, as opposed to systems
Notifications, receipts and newsletters are the natural target: they are high volume, formulaic, and nothing is lost by getting one wrong. A note from a colleague is the opposite on all three counts.
The first month of anything new
A new supplier, a new client, a new system sending alerts. You do not yet know which of their messages matter, so neither does anything you brief.
Connect a mailbox and run the survey on your own backlog before deciding whether the method suits you.
Limits
Where this method breaks down
-
A small daily inbox
It is not worth the overhead on a small daily inbox. Twenty messages is faster read than surveyed.
-
Mail already deleted
It cannot help with mail that has already been deleted and emptied from Trash. Nothing here recovers anything.
-
Shared mailboxes
Shared and delegated mailboxes are not supported, so this is your own mail only.
-
Beyond the free tier
A full pass still costs more calls than the free tier allows. The sort itself is cheap now that moving and marking are batched; the survey in front of it is a call per batch of summaries.
-
No rules or automation
It does not set up rules or automation. Every pass is something you asked for, which is the design, and it means nothing happens while you are away.
How do I use AI to clear a backlog of email?
In four passes, and the order is the whole trick: survey everything without touching it, decide your categories, act in batches from the most reversible action to the least, then check the result in your own mail client. Most attempts fail because they interleave reading and acting instead.
Will it mark everything as read?
No. Reading a message through Mailbox MCP does not mark it read. The engine fetches message source with IMAP's BODY.PEEK, which is the fetch that explicitly does not set the Seen flag. Marking read is a separate tool, mark_read, and it only runs when you ask for it.
How do I stop it acting on the wrong messages?
By deciding the categories yourself and acting in batches you can inspect. Ask for the plan before the action: a numbered list of what it intends to do, which you approve or correct, and only then the doing. It is slower on the first pass and much faster on every one after it.
Does the AI read every message in my inbox to triage it?
Not unless you ask it to. list_emails returns summaries: sender, subject, date, flags. Bodies come only from read_email, one message at a time. So a survey of two hundred messages does not put two hundred message bodies into your conversation, which matters for privacy and for how long the pass takes.
Can I undo a triage pass that went wrong?
Mostly. Flags and read state flip back with one instruction. Moves reverse if you know where things came from, which is why the method asks for the plan in writing before the action. Deletes go to Trash rather than being erased, so they are recoverable until Trash is emptied, but that is a race against your provider's retention rather than a real undo.
Is this actually faster than doing it by hand?
For a backlog, clearly. For a daily inbox of twenty messages, honestly no: the survey and approval passes cost more attention than reading twenty subject lines. The method earns its keep on volume and on recurring patterns, not on a normal Tuesday.
Attribution
Sources
- RFC 9051: IMAP4rev2, the FETCH command Defines BODY.PEEK as the fetch that does not set the \Seen flag, which is the mechanism behind reading without marking read.
- The 28 tools this server exposes Which tool each action in the method above actually calls.
- What the server does with your mailbox Including the parts that are not finished.
Keep going
Read next
Run pass one for free.
5 calls a day is enough for the survey, which is the pass that tells you whether the rest is worth it. No card.