USE CASE
An AI agent on a support@ inbox: triage, proposed replies, approvals
A governed agent on a support inbox reads only the one message a trigger rule matched, works at whatever permission level that workflow is set to, and stops at the recipient restrictions and sending limits your team configured. What follows is the concrete design, message class by message class, not a capability list.
Built for the teams DuoInbox targets first: 3–20 person Google Workspace teams running support@, orders@, billing@, or operations@.
MESSAGE CLASS BY MESSAGE CLASS
Which messages trigger a run, and which never do
A trigger rule matches narrowly, by message class and by sender or domain. Mail that matches nothing stays ordinary inbox work and never reaches the agent.
CAN QUALIFY FOR A TRIGGER
- Order or shipment status
- A question matched to a known order record — where it is, when it shipped, whether it was delivered.
- Billing status
- A question matched to an existing account or invoice record — balance, due date, last payment received.
- Documented password or access resets
- A request that follows a repeatable, documented procedure end to end.
- Published product or policy questions
- A question answerable from a published knowledge source, with no account-specific data involved.
- Routing an unmatched message
- Getting a message that fits no trigger rule to the right person or team, rather than answering it.
- Return or refund status checks
- Checking the status of an existing record — not issuing the refund itself.
MUST NEVER TRIGGER A RUN
- Anything that reads as a complaint escalation, a legal threat, or mentions injury, discrimination, or safety.
- A request to issue a refund, credit, discount, or fee waiver. Decisions with financial authority stay off the trigger list from the start; a person handles these.
- A message from an address on your own escalation list — legal, press, executives — or one matching a known dispute or chargeback pattern.
- A reply inside a thread a person has already flagged for manual handling.
- Anything with legal or contractual weight: cancellations, contract terms, compliance questions.
- A message with an attachment that needs manual review, such as identity documents or signed forms.
SCOPE OF ONE RUN
What the agent may see in one run
Hermes, the agent that does the work, holds no Gmail credentials of its own. When a trigger rule matches, DuoInbox mediates governed MCP access for that one run only. The run receives the matched thread and the actions its workflow permits — it does not receive the mailbox.
See how triage, proposed replies, and approvals fit together in the product
THE REVIEW QUEUE
Where a proposed reply waits, and who owns it
A workflow set to prepare a proposed reply, or to send after approval, produces an item that waits in the review queue rather than going out. On a support queue that item is concrete: the customer's message, the reply Hermes prepared, the address it would go to, the rule that matched it, and whether the recipient restriction and sending limit passed. A reviewer approves, asks for changes, or rejects it. What a review queue has to show to be reviewable sets out the general case.
Assign the queue to a role, not a person. On a 3–20 person team running one of these inboxes, that role is usually whoever already owns the workflow — call it the inbox owner, the support lead, or the queue owner. More than one person can hold the role; the point is that the queue always has an owner, not that one named individual stands behind it. Slack notifications tell whoever holds the role when an item is waiting.
RECIPIENT RESTRICTIONS AND SENDING LIMITS
Set your own values, and widen them deliberately
Recipient restrictions set who a workflow's reply may go to; an added or changed recipient is checked as a policy event of its own, not read as incidental text inside the reply. Sending limits set a ceiling on approved outbound actions for that workflow.
There is no universal right number. Treat a new workflow the way you would a new team member: start narrow — restrict replies to the customer's own address, keep the sending limit low — and watch the queue for the first runs. Widen recipient restrictions or raise the sending limit only after a run of clean approvals, and set different values for different message classes; a billing@ workflow can carry tighter limits than a general product-question workflow.
WHAT HAPPENS ON ESCALATION
What happens when a message escalates
A message that matches no trigger rule never reaches the agent; it stays ordinary inbox work for your team, worked the way it always was. A message that starts a run but hits a boundary partway through — the workflow's permission level tops out, or a policy check fails — stops there: the run does not send, and the item is left for a person, either waiting in the review queue or back in the inbox as ordinary work, depending on what the workflow permits.
Alongside that, one visible runtime control — the kill switch — stops new runs immediately. It applies whether the trigger fired correctly and something still looks wrong, or you simply want to pause while you change a rule.
THE AUDIT CHAIN
What the audit log records
One run produces one chain, recorded in order.
- The mailbox event that arrived.
- The trigger rule it matched.
- The actions the agent took inside that run.
- The policy checks that were applied.
- The human decision: approved, changes requested, or rejected.
From that chain, the queue owner can reconstruct why a run started, what it was permitted to do at the time, and which recipients an approved reply went to. For the reviewer-facing detail on access boundaries and open security questions, read Security.
A FIRST TWO WEEKS
Rolling out one workflow at a time
- 01
Pick one class, one inbox
Choose a single message class in a single inbox — billing@ balance questions, for example. Turn on summarize only. Nothing sends and nothing waits for review yet; you are reading what the agent produces before it acts.
- 02
Move that class to a proposed reply
Once the summaries look right, raise that same class to prepare a proposed reply. Name the queue owner role and staff it. Set recipient restrictions narrow and sending limits low.
- 03
Decide on send after approval, class by class
After a run of clean approvals through the queue, decide — one message class at a time — whether to allow send after approval, and whether to widen the trigger rule or add a second class. The kill switch stays available the whole time; treat it as a normal operator control, not a last resort.
For the broader framework behind these permission levels and review states, read AI email agents: a practical governance guide. If you are still deciding whether this queue belongs in a shared inbox at all, read shared inbox or ticketing system first. To place this shape against the rest of the category — native Google Groups, Gmail-layer tools, helpdesks and multi-channel suites — read team inbox software.
FAQ
Questions about running an agent on a support inbox
- Which permission level should we start with?
- Summarize only, on one narrow message class. It produces no outbound action, so you can watch how the agent classifies and reads messages before it drafts or sends anything.
- Does the agent need our Gmail credentials?
- No. Access is governed through MCP for the single matched thread of a triggered run. The agent never receives a Gmail credential or unmediated inbox access.
- Who should own the review queue?
- A role, not a person. On a 3–20 person team it's usually whoever already owns that inbox's workflow — an inbox owner, support lead, or queue owner. More than one person can hold the role.
- What happens if the agent gets a reply wrong?
- Nothing reaches a customer on its own. A proposed reply sits in the queue until a person approves it, requests changes, or rejects it. Only a workflow set to send after approval produces a blocked send waiting on that decision at all.
- Can we stop the agent immediately if something looks off?
- Yes. An immediate kill switch stops new runs. It sits beside the workflow permissions and the audit activity, so stopping the agent is an operator action rather than a support request.
- Does this apply to orders@, billing@, and operations@ too, or only support@?
- The same design applies to any of the four: support@, orders@, billing@, or operations@. What changes is the message classes you choose to trigger on and the recipient restrictions you set for each.
DuoInbox early access
Put a governed agent on your support inbox, one message class at a time.
Bring triggers, permissions, review states, and audit activity into one shared operating surface.
Request early access