Inbox cleanup is an appealing task to delegate to an AI assistant. There is plenty of repetitive work, the results are immediately visible, and the instructions sound simple: remove old newsletters and leave the important messages alone.
The difficulty is hidden inside “important.” A newsletter can contain an account change. A promotional-looking message can include a receipt. An old automated email can still be the only useful record of a customer interaction.
In one recent cleanup, I kept the scope to older newsletters in a single personal inbox. Selected messages were moved to recoverable Deleted Items. The operation did not include permanently purging mail or expanding into other mailboxes. Borderline messages from the initial selection were restored, and their original read state was checked.
That restoration step is the part worth paying attention to. A useful cleanup system needs a credible way to identify, reverse, and verify its own changes. The smaller inbox is only one part of success.
Give cleanup a precise boundary
“Clean my email” leaves too much room for interpretation. It can mean archive, delete, unsubscribe, mark as read, reorganize folders, or create rules for future messages. These actions have different consequences.
For this task, the boundary was narrow: one personal inbox, older newsletter-like messages, recoverable moves. Financial records, account correspondence, and customer-related records were treated conservatively. The task was not permission to reorganize the entire account.
A reusable brief should identify the mailbox, source folder, cutoff date, permitted message categories, destination, and protected categories. It should also say what to do when classification is uncertain. I would use “leave it in place and flag it for review” as the default for ambiguous messages.
The exact cutoff is a user choice. Once agreed, the implementation should store an explicit date and timezone rather than repeatedly reinterpret “old.” Otherwise a resumed cleanup can quietly include messages that were outside the original selection.
The same principle applies to scope across accounts. Access to several inboxes does not imply that a cleanup request covers all of them.
Treat false positives as the expensive error
Cleanup has asymmetric failure costs. Leaving an unwanted newsletter in the inbox is usually a small inconvenience. Moving a message that the user needs can hide an obligation or interrupt their work.
That should influence both classification and evaluation. A system optimized for the largest number of messages removed will feel productive while making the wrong trade-off. I would rather leave uncertain candidates alone and explain why.
Sender identity is helpful but insufficient. The same service can send marketing, billing, security, and account notices. An unsubscribe footer is also a weak signal by itself. A message's purpose matters more than whether it shares a layout with a newsletter.
The conservative checks should therefore look for evidence that the item is a routine publication and for reasons to preserve it. An account-specific issue, a transaction record, a direct exchange, or an unresolved request should push the decision toward leaving the message untouched.
These are proposed review criteria, not a claim that a classifier can reliably infer importance from every email. Some messages will remain ambiguous even after inspection. Keeping them is an acceptable result.
Design restoration before the first move
In the cleanup described here, Deleted Items provided a recoverable destination. That was materially different from permanently purging the selected messages.
However, Deleted Items is not durable storage. Microsoft's recovery documentation describes different recovery paths and retention behavior across Outlook variants and account configurations. Some settings can also empty Deleted Items. A workflow needs to check the relevant account's behavior rather than promise that restoration will always remain possible. Microsoft's deleted-item recovery guide
For a future implementation, I would decide the restoration route at the same time as the move route. Can the system locate each moved item? Does it know the original folder? Can it preserve or restore relevant message state? How long is the recovery path expected to remain available?
If those answers are missing, the cleanup should stay at the candidate-list stage. A dedicated review folder might be appropriate for a different approved workflow, but the assistant should not silently substitute it for the destination the user chose.
Recoverability should be a checked property of this operation in this account.
Keep an action manifest
A cleanup manifest records enough information to explain and reverse each change. It should be created as part of the operation, rather than reconstructed after somebody notices a missing message.
The following is an illustrative schema. It describes what I would want an implementation to retain; it is not a dump of the personal inbox:
1run:2 scope: one_authorized_inbox3 cutoff: explicit_date_and_timezone4 destination: deleted_items5 permanent_purge: false6item:7 source_locator: provider_reference8 destination_locator: recorded_after_move9 original_folder: inbox10 original_is_read: false11 reason: routine_newsletter_before_cutoff12 status: moved_and_verified13 restoration_status: not_requestedIn practice, the record needs real provider references and a precise cutoff. It should also support preserved, failed, uncertain, and restored outcomes. A single “processed” flag hides too many states.
The manifest is itself sensitive operational data. It may reveal which messages exist in a mailbox even if it contains no bodies. Store the minimum needed, keep it private, and avoid turning an inbox cleanup into an unnecessary email archive.
The value is straightforward: when the user says a selection was too broad, the system has a bounded list of its own changes to inspect.
Plan for identifiers and partial completion
Restoration can fail even when the classification was sound. One easily missed implementation detail is message identity after a move.
Microsoft Graph's ordinary Outlook item identifiers can change when items move. Graph offers an immutable-ID option that remains stable across folder moves within the same mailbox, with documented exceptions such as moving to an archive mailbox. A connector may or may not expose this option, so the workflow must account for the identifiers it actually receives. Microsoft Graph immutable identifiers
The move API also returns a message resource. An implementation should record the returned reference and inspect the destination rather than assume that its pre-move reference will keep working. Microsoft Graph message move
None of this makes a multi-message cleanup atomic. A run may move some items, fail on others, and lose a clear response for another. The manifest needs to represent that partial state honestly.
After an uncertain response, inspect the source and destination before trying again. Otherwise a retry can operate on the wrong assumption about where a message currently lives.
Check the result in the destination
A successful tool response is useful evidence, but the end state deserves its own check. The cleanup should verify that selected items reached the agreed destination and that the intended messages, rather than merely an equivalent number of messages, were moved.
Counts alone are weak evidence. New mail can arrive during a run. A mailbox can synchronize asynchronously. Two unrelated changes can cancel each other out in an inbox total. Item-level checks provide a stronger link between the selection and the result.
In the anonymized cleanup, a manifest and destination verification supported that review. Borderline items were restored after the initial selection, and their original read state was checked.
That last detail matters because a user's mailbox includes attention state as well as content. Restoring an unread message as read can make it easier to miss. Returning a message to the wrong folder can preserve the bytes while disrupting the user's system for finding them.
Where an attribute was not captured or cannot be verified, the report should say so.
Make a correction change the rule
When borderline items are restored, the operation has learned something about the selection boundary. Continuing with the same broad criteria would repeat the mistake.
I would pause the affected category, identify why it was misclassified, and narrow the rule before continuing. That might mean protecting account-specific notices from a sender whose generic newsletters remain eligible. It might also mean leaving a whole ambiguous category for manual review.
The correction should remain scoped. One restored message is evidence about that decision; it does not automatically establish a permanent preference for every sender or future cleanup.
A good completion report can stay short: what category was moved, where it went, what was preserved, what was restored, and whether any changes remain unverified. If there were mistakes, mention the correction plainly rather than burying it under the removal total.
This gives the user a way to assess the operation without asking them to audit every successful move.
Undo has limits
Restoration reduces the cost of an error, but it does not erase every consequence. A hidden message can be missed before it is restored. A deadline can pass. A recovery window can expire. Another client or person can change the same message while cleanup is running.
For that reason, an undo path does not justify broader scope or weaker selection. It complements conservative decisions and explicit authorization.
The same design applies beyond email: file organization, contact deduplication, ticket updates, and document cleanup all benefit from knowing the starting state, recording changes, and checking the result. Each system has different reversibility limits, so the restoration plan needs to fit the operation.
Before I trust an assistant with cleanup, I want answers to four questions: what may it change, what will it preserve, how will it account for each change, and how will it verify a correction?
A quieter inbox is useful. Being able to understand and repair the work is what makes that usefulness dependable.