AI-NATIVE SHARED INBOX FOR GOOGLE WORKSPACE
A shared inbox where the AI teammate works under workflow rules
DuoInbox is a shared inbox for Google Workspace teams of roughly 3 to 20 running a support@, billing@, orders@, or operations@ address. Hermes, the agent that does the work, sits in that inbox as a teammate whose permissions are set for each workflow rather than once for the whole mailbox.
This page follows one message the whole way: what wakes the agent, what a single run can reach, which of the three permission levels applies, and where a person has to decide before anything leaves your domain.
HOW IT WORKS
From arriving message to approved reply
- 01
A message arrives in the shared inbox
DuoInbox watches the Google Workspace mailbox your team already reads. The message lands in the shared inbox as it always did, visible to people from the first second. Nothing is held back while the rules are evaluated.
- 02
Workflow rules evaluate the message
A workflow is defined by what may start it: the sender, the sending domain, and the intent of the message. A rule for billing questions from a known customer domain is a workflow. “Every new email” is not, and DuoInbox is not built to run that way.
- 03
No match means it stays the team's work
Most mail matches nothing, and nothing happens to it. The agent is not woken, no run exists, and the thread is ordinary inbox work owned by a person. Matching is the exception you configure, not the default.
- 04
A match starts a run inside that workflow
The run receives the matched thread and only the actions the workflow allows. It reaches mail through governed MCP access that DuoInbox mediates rather than through Gmail credentials of its own, so a run cannot widen its own scope to the rest of the mailbox.
- 05
Consequential actions stop in the review queue
Anything the workflow marks for approval stops with the source message, the proposed reply, the recipients, and the policy checks side by side. Until a person decides, external send is blocked.
MCP gives an agent email tools. DuoInbox gives it triggers, policies, and approvals. The Model Context Protocol makes a mailbox action callable; on its own it does not decide which message should wake an agent, which workflow applies, or what that workflow permits.
PERMISSION LEVELS
Three permission levels, set per workflow
These are all of them. There is no fourth level, no hidden escalation, and no way for a run to exceed the level its workflow is set to. A workflow set to summarize only cannot compose a reply, whatever anyone asks it for.
| Permission level | The agent may | The agent may not |
|---|---|---|
| Summarize only | Read the matched thread and post a summary where the team already works. | Compose a reply, change the thread, or send anything. |
| Prepare a proposed reply | Compose a reply and hold it on the thread as a proposed reply awaiting review, with its recipients shown. | Send that reply. External send is blocked at this level, including to people already on the thread. |
| Send after human approval | Send the version a person approved, to the recipients that were on screen when they approved it. | Send before that approval, or add a recipient the approval did not cover. A recipient change is checked as its own policy event. |
Permission levels are one half of the operator surface. Recipient restrictions, sending limits, the audit log, and the control that stops new runs sit beside them. See what an operator can set and stop.
Which workflow would you put behind an approval gate first?
Request early accessREVIEW QUEUE
The review queue is where the consequential moment happens
A proposed reply and an approved send are different events, so they are different states. These are the states an item can hold, and each one names who currently owns it.
- Agent working
- The run is in progress inside its workflow. Nothing has left the mailbox.
- Awaiting review
- A proposed reply is ready and needs a person. This is the state that decides whether the workflow is working.
- Changes requested
- A reviewer returned the proposal with a note instead of approving it. The item stays in the queue under the same thread.
- Approved
- A person accepted the version in front of them. What happens next is set by the workflow's permission level, not by the agent.
- Rejected
- The proposal is closed without sending and the thread goes back to the team as ordinary inbox work.
- Failed
- The run stopped before it produced anything to review, for example because required context was missing. It stays visible in the queue rather than disappearing.
- Paused
- An operator stopped new runs. Existing items keep their state and no new work is started until someone resumes it.
The queue needs a named owner
An agent that prepares work still needs a person who handles the queue, decides what happens when an item ages, and changes the rule when the same wrong match keeps arriving. DuoInbox makes the state visible; it does not appoint that person. A queue nobody owns becomes a second backlog instead of less inbox work.
AGENT OWNERSHIP
Your agent, not a bundled one
A bundled agent asks you to trust what a vendor's software does inside your mailbox. DuoInbox is the other half of that arrangement. The agent stays yours: you own it, you change it, and you can take it away.
DuoInbox supplies the parts that decide whether it should act at all — the trigger that matches a message to a workflow, the policy that says what that workflow permits, and the approval boundary that holds an external reply until a person accepts it.
That division is what a security review has to look at. The agent holds no Gmail credentials. It reaches mail through governed MCP access that DuoInbox mediates, one matched thread at a time, which is why adding a teammate does not mean handing over the keys to the mailbox.
SUPPORTED TODAY
What DuoInbox supports, and what it does not
-
Gmail on Google Workspace
A shared mailbox such as support@, billing@, orders@, or operations@, read by a team of roughly 3 to 20 people.
-
Hermes as the agent
Hermes is the agent that does the work: it reads the matched thread, prepares the summary or the proposed reply, and stops where the workflow says stop.
-
Slack notifications
Items awaiting review are announced in Slack, so the queue is not something a person has to remember to open.
Not supported
Mail providers other than Gmail on Google Workspace are not supported. If your shared inbox is on Microsoft 365, on a hosted IMAP mailbox, or on a help desk with its own ticket model, DuoInbox does not apply to it.
We have not settled the exact Slack notification behaviour, so nothing on this page should be read as a specification of it. We are also not naming a date for anything beyond Gmail and Hermes, because we do not have one to give.
EARLY ACCESS
Name the workflow you would govern first
Tell us the inbox, the messages that would match, and the permission level you would set. Your email and that description are stored so a person can reply. We have not set pricing or packaging, so nothing here implies a price, a plan, or trial terms.