Skip to content

Blog · Workflow Automation

Can AI agents triage a shared inbox? Which actions to hand over first

How to give an AI agent your shared inbox one action at a time, and how to test it for missed urgent requests before it can move or send anything.

  • The Foregrounds
  • 17 min read
Chalk drawing of a mail sorter on black, with one envelope held forward by a blue binder clip.

For many firms, one shared inbox carries much of the client traffic. An address such as clientservices@ is open to several people with full access, and it mixes billing questions, deadline questions, document requests and newsletters. Consider an illustrative message (not from a real client), which we will return to throughout: a client's office manager writes to an accounting firm's clientservices@ inbox to say that the September invoice charged the bookkeeping retainer twice and that a state sales-tax notice has arrived. She asks someone to confirm that both are on track. Now a vendor or an internal team proposes to let an AI agent sort messages like hers. If you are still deciding whether the inbox should be your first automation at all, start with how to choose the first workflow to automate.

Agent tools are now arriving in the sector. The Thomson Reuters Institute 2026 AI in Professional Services Report, which drew on more than 1,500 respondents in 27 countries across legal, tax and accounting, corporate functions and government, found that 15% of organizations had adopted some type of agentic AI tool and a further 53% were planning for one or considering it. An agentic tool takes actions, such as filing or answering a message, so for the operations leader who owns the inbox, the question is less whether an agent will arrive than which actions it may take without a person.

This article addresses which inbox actions can move out of manual review, in what order, and on what evidence. Our view is that your firm can hand an agent its shared inbox one action at a time. Start with suggestions that leave every message in view, and keep moving, sending and forwarding with a person until a trial shows that the agent does not bury urgent requests and that your team can reverse its mistakes. We cover the actions inside "triage", why sorting is harder than it looks, mailbox access, a permission list and a trial.

Key takeaways

  • Triage is several actions, not one. Reading, labeling, assigning, drafting, moving and sending carry different risks, so each one gets its own permission.
  • Sort requests, not messages. One client email can hold a billing dispute and a deadline, and a later reply can change what is due.
  • A hidden message costs more than a wrong label. A wrong label in view is a small, visible error, but an urgent request moved out of view stays hidden until the client calls.
  • Mailbox access is an information decision. The agent can read everything its permission covers, and anyone outside the firm can write the email it reads.
  • Test for missed urgent work and recovery, not only accuracy. Turning the agent off does not put back the messages it already moved.

What an AI agent can do in a shared inbox

"Triage" sounds like one job, but in a shared inbox it covers six separate actions, and only the first four leave the inbox as the team sees it:

  • Read: open a message and its thread to work out what they say.
  • Label: attach a visible tag, such as Billing or Tax.
  • Assign: name the person who owns the request.
  • Draft: write a proposed reply that waits for a person.
  • Move or archive: take the message out of the main inbox, or mark it as done.
  • Send or forward: deliver a message to the client or to someone outside the firm.

Mailbox platforms separate some of these actions, but they draw the line in different places. Microsoft's guide to shared mailboxes in Exchange Online says that the Full Access permission lets a user read, delete and change messages, but not send from the shared mailbox without a separate Send As or Send on Behalf permission. In Google's list of Gmail permissions for app developers, by contrast, the permission an app uses to change messages also lets it compose and send email. The permission a tool asks for can therefore be broader than the job it is sold for, so the first question is what the connection allows, not only what the agent is told to do.

For the office manager's email, a Billing label changes only a tag, but moving the message into a Billing folder takes it out of the main inbox, and sending a reply puts a promise in front of the client. "The agent sorts the inbox" means something different at each step, so each step needs its own decision.

Why sorting by message misses work: two requests and changing threads

Most classification tools give each message one category, but client email often carries two requests at once, and later replies change what the firm owes. A design that labels the first message and stops will miss work that arrives later in the thread.

Her email shows both problems. A tool that must give the first email one category will probably pick Billing, because the invoice comes first, so the tax notice rides along under the wrong label. Two days later, the office manager replies in the same thread to say that the notice gives a Thursday deadline. The thread now holds a deadline but still carries the day-one Billing label, so it may sit in the billing coordinator's queue while the tax team never sees it.

A client email with two requests marked, a billing correction and a sales-tax notice, and a later reply that adds a Thursday deadline.
One message, two requests, and a reply that changes what is due: a single Billing label covers only part of it. View full-size image

Two design rules follow:

  • Split each message into the requests it contains. Her email becomes two items, a billing correction and a tax-notice response, each with its own owner.
  • Classify the thread again on every new reply. The Thursday deadline should change the thread's priority and owner on the day it arrives, not when someone next opens the thread.

A misfiled urgent message costs more than a wrong label

Inbox errors are not equal, and the most serious ones are the errors nobody can see. A wrong label on a message that stays in the main inbox gets corrected by the next person who reads it, but a message moved into a folder nobody watches has left the team's view, so the error stays hidden until the client follows up.

Thin attention makes hidden errors more likely. Microsoft's Work Trend Index report Breaking down the infinite workday found that the average worker receives 117 emails a day and skims most of them in under 60 seconds. The figure comes from anonymized Microsoft 365 data across many sectors, not from shared inboxes alone, but it shows how little time a message gets and how easily a missing one goes unnoticed. Microsoft's shared-mailbox guide also notes that when users move items between folders in a shared mailbox, a copy goes to the Recoverable Items folder. That copy helps only if someone knows a message was moved and where to look.

For her email, the errors rank from least to most serious:

  • Wrong label, still in view: someone sees "Billing" on a tax question and fixes it.
  • Wrong assignee: the billing coordinator passes the tax notice on, which costs time but keeps it visible.
  • Filed under Billing, out of view: the service team never sees the Thursday deadline.
  • An automatic reply that misses the point: the client reads "we'll look into your invoice" and assumes the deadline is handled.

This ranking tells you what a trial must measure, because an average accuracy score hides the last two errors, and those are the ones that reach the client.

A scale of inbox errors from visible ones, such as a wrong label, to hidden ones, such as a filed message or an auto-reply that misses a deadline.
The errors worth measuring in a trial sit at the hidden end of the scale. View full-size image

Mailbox access is also an information-access decision

Connecting an agent to a shared inbox decides what it can read as well as what it can do. The connection usually covers every message in the mailbox, which can mean years of client correspondence, and because people outside the firm write those messages, anyone who can email the address can put instructions in front of the agent.

The OWASP Gen AI Security Project, an open community project that publishes guidance on risks in AI applications, calls this excessive agency: an AI system with more functions, permissions or freedom to act than its job needs. Its mailbox example is an assistant meant only to summarize incoming mail that can also send, so a crafted message tricks it into finding sensitive information and forwarding it to an attacker. OWASP's fixes are a connection that can only read mail and a person who reviews and sends every drafted reply. These steps do not make an agent safe, but they limit what one bad message can do.

Before you approve a tool, ask three questions:

  • Which mailbox does it connect to, and does that reach personal mailboxes or archives as well?
  • Which permission does it hold, in the platform's own terms, and could a narrower one do the job?
  • Does anything outside the AI model check an action before it runs, or does the agent decide for itself?

Separate classification from the actions that change the inbox

Classification, which means deciding what a message is about and who should own it, can run with little authority. Actions that change what the team sees or what the client receives need their own approval step, and the mailbox permissions should enforce that step, not only the agent's instructions.

OWASP recommends the same split: the least permission the job needs, a person's approval before high-impact actions, and authorization checked in the downstream system, such as the mailbox, rather than left to the AI model. In a published Foregrounds case study for an online retailer's carrier dashboard, the system prepares a customer email as a draft in the team's Gmail account, and a staff member edits it and decides when to send. That is an e-commerce case, but the arrangement carries over directly to a firm's client inbox.

The way to write this down is an action-permission list: a written list of inbox actions, each marked as one the agent may do alone, one it may propose for a person to approve, or one it may not do. For a client-services inbox like this one, a first version looks like this:

  • Read and suggest a label: the agent does this alone, and the message stays in the shared inbox.
  • Apply a visible label or assign an owner: the agent does this alone during the trial, and the team can see and change the result.
  • Draft a reply: the agent proposes, and a person edits and sends.
  • Move, archive or mark as done: only after the trial, and only for named low-risk categories such as vendor newsletters.
  • Send, forward outside the firm, or delete: a person does this.

The list then drives the mailbox setup: if the agent may not send, its connection should not hold a permission that allows sending, so a manipulated agent still cannot send.

How to test the agent before it moves or sends anything

Run the trial with every message still in view, and measure the failures that matter: missed urgent requests, two-request messages, and threads that changed after the first label. Then rehearse recovery before the agent may move anything.

Recovery needs a rehearsal because switching an agent off does not undo its work. Microsoft's Recoverable Items copy and the Gmail trash help, but Google's Gmail permission list shows that its broadest mail permission lets an app delete messages permanently, bypassing the trash, so the permission a tool holds sets what your team can recover.

A trial plan for that inbox has five steps:

  1. Run the agent in suggestion mode. It applies labels and assignments only, and every message stays in the shared inbox.
  2. Seed the queue with known test cases. Add urgent and two-request messages that the team writes in advance, including the double-billed retainer with the tax notice and a follow-up that adds the Thursday deadline.
  3. Count the misses that matter. Record each urgent request the agent sent to the wrong owner or category, and how long the team took to find it.
  4. Log every action with a way to reverse it. The log shows what the agent did, when, and how to put it back.
  5. Switch the agent off for a day. Check what the team must clean up by hand, and confirm that the inbox still works without it. It is the same rehearsal we recommend before any AI implementation handover.

A trial counts as evidence not because it ran for a set number of weeks, but because the seeded urgent cases reached the right person and the team showed that it could reverse the agent's actions.

What to do next

  • Start with suggestions the team can see. Let the agent label and assign, and keep every message in the shared inbox during the trial.
  • Write the action-permission list before you choose a tool. Mark each action as one the agent does alone, one it proposes for approval, or one it may not do, then grant the narrowest mailbox permission that matches the list.
  • Classify requests and threads, not just messages. Require the agent to split multi-request emails and to reclassify a thread on each reply.
  • Measure missed urgent work and recovery. Track every misrouted test message and how long it took to find, and rehearse reversing a mistaken move before the agent may move anything.
  • Expand one action at a time, with a named owner. Each new permission follows a trial result and an owner's review of the exception log (the record of what the agent could not handle), not a date on the calendar.

Questions buyers ask

Can an AI agent send replies from our shared inbox?

Technically yes, if the mailbox permission it holds allows sending, but we recommend keeping sending with a person at first. A reply is the one inbox action you cannot take back, and it can commit your firm to a date, a fee or an answer. Let the agent write its draft in the shared inbox, and have the person who owns that client edit and send it. Once drafts for one type of message consistently go out with only small edits, you can decide whether routine replies, such as confirming that a document arrived, may go out on their own.

Does the agent need access to the whole mailbox?

Usually not. It needs only the access that your action-permission list calls for, so an agent that only labels and assigns should not hold a permission that lets it delete or send. Ask the vendor which permission the connection uses, in Microsoft's or Google's own terms, and whether it reaches only the shared inbox or other mailboxes and archives too. Where the platform offers a narrower permission that still does the job, use it, because a crafted email can try to make the agent use any access it has.

What happens to our messages if we switch the agent off?

Nothing moves back on its own. Labels stay where the agent put them, and messages it moved or archived stay in their new folders, so your team has to find and restore them by hand. That is why the trial needs a log of every action the agent takes, including the folder each message came from. Before you let the agent move anything, switch it off for a day during the trial and time how long the clean-up takes.

How do we know the trial worked?

Judge it on the urgent requests, not on overall accuracy. A high accuracy score can still hide the one tax deadline that went to the wrong person, and that is the error a client notices. Seed the trial with test messages your team writes in advance, including two-request emails and threads where a later reply adds a deadline. If every one of them reached the right owner while still in view, and your team could reverse the agent's actions, you have the evidence to trial the next permission; if one did not, find out why before you expand.

Hand your shared inbox to an AI agent one action at a time, and keep moving, sending and forwarding with a person until a trial shows that your team can find and reverse the agent's mistakes. To plan that boundary and build an agent that works within it, see our approach to agentic systems.

Start withthe businessproblem.

Thirty minutes. Tell us what's slow or manual today, and we'll tell you honestly whether we can fix it.

30 minutes