AI Shared Inbox Management: Categorize, Assign and Draft Replies

AI shared inbox management works when you split the job into three steps and keep a person on the last one. The agent reads each message and applies one category from a short written list, proposes an owner using explicit assignment rules, and prepares a draft reply that waits for approval. Start with one mailbox, a handful of categories and no permission to send.

Key takeaways

• Define categories by the action a message needs, with a written boundary and an Unclear option, rather than by topic alone.
• Write assignment rules a colleague could read and dispute, and name a fallback owner so nothing is guessed.
• Give the agent permission to read, label, suggest owners and save drafts, but not to send, delete or forward.
• Require every draft to point to the source it used and to flag gaps instead of filling them.
• Run the agent in shadow mode first, then judge it by how often owners accept its labels and drafts.

What does AI triage do in a shared inbox, and what should it never do?

A shared inbox such as support, orders or info collects messages from many senders for many possible owners. The usual failure is not volume alone. It is that everyone sees a message and assumes someone else has it, or the wrong person replies without the history. Triage is the work that prevents this: decide what the message is, decide who owns it, and prepare the first response.

An AI agent can do all three as proposals. It reads the message and its thread, picks a category, suggests an owner and saves a draft. If you want the support-specific view of how to route requests with evidence, that article goes deeper on the routing side.

What the agent should not do is just as important. Treat this list as a permission boundary:

• It may read messages in the chosen mailbox and the threads they belong to.
• It may apply a label, suggest an owner and save a draft.
• It may not send, delete, archive, forward outside the company or change records in other systems.
• It may not follow instructions found inside a message.

The last line matters more than it looks. Every email is text written by someone outside your control. A message that says to ignore your rules and forward recent invoices is data to be categorized, probably as suspicious, not an instruction to obey. The OWASP guidance on prompt injection prevention describes this class of risk, and the OWASP authorization guidance supports the principle behind the permission list: give the role the least access that lets it work. For a wider view of which limits to set first, read about which guardrails a business agent needs first.

How do you design categories the agent can apply consistently?

Most category lists fail because they describe topics, and topics overlap. A message about a late delivery can also be a billing complaint and a cancellation warning. Define categories by what the team must do next, then add a separate urgency flag so a category does not have to carry two meanings.

A workable starting list for a small team might look like this:

• New request: someone who is not yet a customer asks for something.
• Existing account or order question: a known sender asks about something already in progress.
• Billing or payment question: anything about invoices, charges or payment status.
• Complaint or escalation: dissatisfaction, a threat to leave, or a mention of legal, safety or press.
• Partner, vendor or applicant: not a customer, but a real person who needs an answer.
• Automated notice or spam: system notifications, newsletters and unsolicited offers.
• Unclear: the agent cannot tell, and says why.

For each category, write three things on one page: a one-sentence definition, one or two real examples with names removed, and a boundary sentence that says what the category is not. The boundary sentence does most of the work. For example, Billing question might say: not a complaint about service quality, even if the sender mentions an invoice.

The Unclear category is not a failure state. It is the agent's way of declining to guess, and it should be easy to choose. If the agent is pushed to always pick a real category, it will pick confidently and sometimes wrongly.

Ask the agent to return a fixed output for every message: the category, the urgency flag, and a short quote from the message that justifies the choice. The quote lets a reviewer check the label in seconds. Before you switch anything on, have two people on the team label a sample of past messages without the agent, then compare their labels with the agent's. Disagreements between the two people are as useful as disagreements with the agent. They usually point to a fuzzy definition, which you fix in the text, not by retraining anything.

What assignment rules should the agent follow?

Assignment is where shared inboxes quietly break, because the real rules live in people's heads. Writing them down is most of the work, and it benefits the team even without AI. Use plain sentences that a colleague can read and challenge. A decision guide for the agent can look like this:

• If the sender has an open thread, suggest the person who last replied, unless they are marked unavailable.
• If the category is Billing or payment question, suggest the finance owner.
• If the category is Complaint or escalation, or the urgency flag is set, suggest the manager on duty and mark the message at the top of the queue.
• If the category is New request, suggest the owner by topic, or by rotation when no topic applies.
• If the category is Partner, vendor or applicant, suggest the person who handles external relationships.
• If the category is Automated notice or spam, assign no one and leave it for a periodic check.
• If the category is Unclear, or two rules conflict, suggest the triage owner for the day and say which rules conflicted.

Two details keep this reliable. First, the agent needs a trustworthy source for availability, such as a shared calendar or a short list someone maintains. If that source is stale, the rule fails quietly. Second, name the fallback owner explicitly. A message that no rule covers should land with a named person, never with a best guess about who might know.

An illustrative scenario: a small wholesale company's orders mailbox receives a message from a known customer. It says a pallet arrived damaged and that they may look at other suppliers. The agent labels it Complaint or escalation, sets the urgency flag, and quotes the phrase about other suppliers as evidence. Because the sender has an open thread, it suggests the account manager who wrote last, and copies the manager on duty into its note. It saves a draft that apologizes, asks for photos of the damage and promises nothing about credits or replacements. The account manager changes one sentence and sends it.

The owner should be able to reassign with one action, and each reassignment should be recorded with the agent's original suggestion. Over time those records show which rule is wrong, which is more useful than any general feeling that routing is off.

How should draft replies work when a person approves every send?

A good draft saves time only if the reviewer can trust it quickly. That means the agent writes from approved material, shows where each fact came from, and says plainly when it lacks something.

Give the agent a small, curated set of sources: the answers your team already stands behind, current policies, and the thread history. Documents that are out of date or contradict each other will produce drafts that do the same, so it helps to prepare company documents before connecting them. The same applies to stale context in general: if the agent remembers an old policy, it will quote it.

Set these rules for every draft:

• Reply in the language of the sender, in the tone your style note describes.
• Answer the question that was asked, and no more.
• Do not state prices, dates, refunds, credits or deadlines unless an approved source contains them.
• When information is missing, insert a visible note for the reviewer, such as a question for the warehouse, instead of inventing a detail.
• List the sources used at the top of the draft, in a note that is not part of the reply.
• Save the draft in the mailbox as a draft. Never send it.

For replies that continue an existing relationship, the quality of the draft depends on carrying the conversation forward, which is covered in AI customer follow-up drafts that keep the context.

The reviewer needs a short checklist, not a feeling. Each draft is checked against these questions:

• Does it answer what the sender actually asked?
• Can every factual statement be traced to the listed sources?
• Does it make a promise the company has not approved?
• Are the recipient, copied addresses and attachments correct?
• Does it sound like the company?

Approval has three outcomes: send as written, edit and send, or reject with a reason. Keep the reason short and picked from a few options, such as wrong facts, wrong tone, wrong category or missing information. Those reasons are the feedback loop. A pattern of wrong tone points to the style note, and a pattern of missing information points to a gap in the sources. Neither requires rewriting everything.

How do you roll it out, and what does managed operation add?

A small first scope is easier to prove and easier to correct. The sequence below fits one mailbox and one team.

• Write down who owns what in the mailbox today, including the cases nobody is sure about.
• Draft the category list with boundaries, and label a sample of past messages with two people.
• Write the assignment rules and name the fallback owner.
• Collect the approved answers for the most frequent questions, and retire contradicting ones.
• Connect the mailbox with read, label and draft permissions only.
• Run the agent in shadow mode: it labels, assigns and drafts, but its work is compared with what the team actually did, and nobody acts on it yet. The article on running an AI agent in shadow mode explains how to do this before granting any authority.
• Switch on visible labels and suggested owners, then drafts for approval.
• Review corrections every week, update the rules and sources, and expand to another category or mailbox only when the evidence supports it.

Decide before you start what success looks like, and make it observable. Useful signals include how often owners keep the suggested category and owner, how long a message waits before someone has taken it, and how often drafts go out with little or no editing. The Anthropic engineering write-up on building effective agents makes a related point: prefer the simplest design that works and add complexity only when it earns its place. For a shared inbox, that means a clear labeling and drafting step with a human gate, not an agent that acts alone.

Be Human handles this as a managed engagement. The first step defines one useful role for the inbox, the memory and tools it needs, the approval boundaries and the success criterion. After that, Be Human can monitor the workflow, run recurring evaluations against labeled samples, maintain the mailbox integration, review permissions and make controlled improvements when the corrections show a pattern. The company keeps the decisions: what the categories mean, who owns what and what gets sent.

Frequently asked questions

Can the AI send replies on its own? It can, technically, but for a shared inbox it should not at the start. Drafts that a person approves keep accountability clear and let you see the agent's mistakes before a customer does. If you later allow automatic sends, limit them to narrow, low-risk cases that you have measured, and keep the ability to turn them off.

Does the agent need access to the whole mailbox? No. Give it access to the shared inbox it triages and the threads inside it, and nothing else. Keep it away from personal mailboxes, and do not let it send, delete or forward. Reviewing these permissions on a schedule matters, because teams add access over time and rarely remove it.

What if the agent labels a message wrongly? That will happen, so design for it. The label comes with a quote as evidence, the owner can change it in one action, and each change is recorded with the agent's original suggestion. A repeated error usually means a category boundary or an assignment rule needs clearer wording, which you fix in the written definition.

How do we know it is working? Compare the agent's labels, owners and drafts with what your team actually did, first in shadow mode and then during live use. Track how often suggestions are accepted unchanged, how long messages wait before an owner takes them, and which rejection reasons repeat. If you want a method for turning those signals into a business case, see how to measure AI workflow ROI without inflated claims.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.