DuoInbox Request early access

OPERATOR CONTROLS

Controls an operator can set, see, and stop

This page is written for the person who owns the shared inbox and for the reviewer who has to sign off on it. It lists what a team can restrict, what it can observe, what happens when Hermes — the agent that does the work — gets something wrong, and where DuoInbox is the wrong tool.

WHAT YOU CAN SET

Seven controls, and what each one holds

Each control states what it does, what it prevents, and the screen it appears on. A control you cannot find at the moment you need it is not a control.

  1. Workflow permissions

    What it does
    Each workflow is set to one of three levels: summarize only, prepare a proposed reply, or send after human approval. The level belongs to the workflow, not to the mailbox, so a billing workflow and a vendor-change workflow can sit in the same inbox at different levels.
    What it prevents
    A workflow cannot act above the level it is set to. There is no fourth level and no per-message escalation, so a permission is widened by an operator changing the workflow or not at all.
    Where you see it
    The Control view shows the active permission envelope for the running workflow: each allowed action marked allow, and external send marked blocked.

    See the three levels and what each one may not do

  2. Recipient restrictions

    What it does
    A recipient change is evaluated as its own policy check. Adding an address, replacing one, or widening a reply beyond the people already on the thread is a policy event in its own right.
    What it prevents
    A reply picking up an external address that no rule covers, and the reviewer approving it because the address was buried in a header rather than raised as a decision.
    Where you see it
    The recipient boundary check in the review queue, listed beside the proposed reply and the addresses it is directed to.

  3. Sending limits

    What it does
    Set a ceiling on approved outbound actions for a workflow. Approved sends count against that ceiling, and the count is visible before it is reached rather than after.
    What it prevents
    A rule that matches far more mail than intended turning into outbound volume. The ceiling bounds what a bad match can cost you while you fix the rule.
    Where you see it
    The Control view, as a count of approved sends against the ceiling set for that workflow.

  4. The review queue

    What it does
    Every action a workflow holds for approval waits in one queue. An item is awaiting review until a person approves it, rejects it, or edits the reply and sends it back for changes. Each item names the person who currently has it.
    What it prevents
    Approvals made without the source in view, and proposals that quietly age out because nobody owned them.
    Where you see it
    The Approvals view puts four things at the decision point at once: the source message with the account record it was matched against, the proposed reply in an editable field, the addressed recipients, and the policy checks — recipient boundary, whether the claims are grounded in the lookups the workflow allowed, whether the run stayed inside its permissions, and any note another reviewer left.

  5. The audit log

    What it does
    The mailbox event, the matched rule, the agent action, the policy checks, and the human decision are recorded as one chain, each entry timestamped and marked with its outcome: observed, allowed, or held.
    What it prevents
    Reconstructing after the fact why the agent ran on a particular message by reading the reply it produced.
    Where you see it
    The Control view, as recent workflow events in order. A reviewer can follow one message from the mailbox update that started it to the decision a named person made.

  6. Immediate stop

    What it does
    One control on the Control view stops new runs. It does not require revoking credentials, suspending the mailbox, or filing a request with anyone.
    What it prevents
    The gap between noticing something wrong and being able to act on it. Stopping new runs is not an approval decision, so anything already awaiting review stays in the queue for a person to settle.
    Where you see it
    The Control view, beside runtime state, where the operator watching the workflow already is.

  7. Slack notifications

    What it does
    Slack notifications are part of the control set, so review work can surface where the team already works.
    What it prevents
    Nothing on its own. We have not published which events post to Slack, which channel they go to, or whether a decision can be made from Slack, so treat the review queue in DuoInbox as the place decisions are made until we do.
    Where you see it
    Not documented here. The integration detail is listed as an open question rather than described.

    Read the open questions

The DuoInbox Control view showing runtime status, the active permission envelope with three allowed actions and a blocked external send, a sending limit counter, workflow health, and a timestamped list of audit events.
Control — permission envelope, sending limit, and audit events for one workflow

WHEN IT GOES WRONG

How failures are handled

Four failure modes come with putting an agent in a mailbox. Each one is handled by a specific behaviour rather than by asking reviewers to be careful.

Wrong workflow match

A message resembles a case in scope but belongs somewhere else. The item carries the rule that matched it, so a reviewer can reject it or hand it back to the team without guessing why the agent woke up. The match is visible before the reply is, which is the order that lets you catch it.

Missing or stale context

The agent has an incomplete record and a plausible sentence available to it. When required data is unavailable the run stops rather than composing around the gap, and the reviewer sees which lookups the run actually used, so a proposal built on thin evidence reads as one.

Recipient or thread drift

A reply introduces an external address, or operates on the wrong conversation. Both are treated as policy checks rather than as text inside the reply, so the reviewer is asked about the recipient specifically instead of being expected to notice it.

Repeated action

A retry risks doing the same work twice. Event identity stays stable across a retry and the activity record stays visible, so an operator can tell a retried run from a second customer request instead of answering both.

WHO THIS IS NOT FOR

Where a conventional shared inbox is enough

Three situations where you should not adopt DuoInbox. They are here so you can rule yourself out in a minute rather than in a month.

LIMITS

What is not supported

  • Mail outside Gmail. Microsoft 365 and Outlook, IMAP mailboxes, and help-desk platforms with their own ticket model are not supported. The initial product works on Google Workspace shared inboxes.
  • Agents other than Hermes. DuoInbox governs Hermes through mediated MCP access. Pointing a different agent runtime at the same controls is outside the initial scope.
  • External send without a person. No permission level, limit, or setting releases an external send without an approval. This is a design boundary, not a configuration gap.

We are not publishing dates or a sequence for anything beyond the initial Gmail and Hermes scope, so this list is what to plan against today rather than a snapshot that quietly expires.

EVALUATING THIS FOR SOMEONE ELSE

The two questions that usually come next

How does the agent reach mail at all?

The access model is the next question for most reviewers: what the agent holds, what DuoInbox mediates, and which security questions have no answer yet. All three are on one page, including the ones we cannot answer.

Read the access model and the open questions

I have a written security questionnaire

Send it. Questions with an answer get one. Questions that touch certification, attestation, data residency, or product data retention are marked as unanswered rather than filled in with something agreeable, because DuoInbox holds no certification and claims none.

Send a security questionnaire

EARLY ACCESS

Tell us the first workflow you would put a boundary around

Describe the inbox, the workflow, and the permission level you would start at. Your email and that description are stored so a person can follow up. DuoInbox does not publish a response-time commitment, so this page will not offer one.

Request early access

DuoInbox early access

Request early access to DuoInbox

Tell us your work email and the inbox workflow you would govern first.

A person reads the request and replies at the address you give. DuoInbox does not publish a response-time commitment. How your details are handled.