Should your AI agent get its own mailbox, or work in the team's?

The two architectures

Both put an AI agent on the sending or receiving end of email. They differ in who the customer thinks they are talking to, and where the operational boundary sits.

The agent as its own sender. The agent (or the system behind it) has its own address, its own sending identity, and its own API-level access to send and receive mail. Nobody is standing behind that address reading every message; the system is the correspondent. This is the shape of transactional mail, notifications, and agents built to run a mail-driven workflow end to end, such as scheduling by email or automated outreach.

The agent inside the team's inbox. A person or a small team already owns an inbox — support@, orders@, billing@ — and the customer relationship lives there. An agent joins that inbox as one more worker: it can be triggered by a matching message, propose or send a reply, and stop for a person when a rule says to. The address stays the team's address. The agent works under the same roof as the people who already answer that mail.

The decision rule: who owns the customer relationship

Ask a single question before anything else: if a human answered this message today, whose name or which team would the customer expect to be behind the reply? If the answer is a named inbox that people already work — a support queue, an orders desk, a billing address — the customer relationship belongs to the team, and the agent should work inside that inbox under policy. If there is no such inbox, because the correspondence has always come from a system rather than a person, the agent is the counterparty and needs its own mailbox and its own sending infrastructure.

This rule does not turn on how capable the agent is, how much of the reply it writes, or how often a human reviews its work. A highly autonomous agent can still belong inside a shared inbox if the customer relationship is the team's. A simple, rules-based agent can still need its own mailbox if it is the system of record for that correspondence.

What changes with each architecture

Identity

An agent with its own mailbox is a distinct correspondent: its address, its domain reputation, its own history in the recipient's mail client. An agent inside a shared inbox has no identity of its own — every message still comes from the team's address, whether a person or Hermes prepared it.

Thread continuity

A customer who has been emailing support@ for months expects replies to keep coming from support@, in the same thread, regardless of who or what drafts them. An agent with its own address cannot preserve that continuity — a reply from a new address starts a new thread and a new relationship in the customer's eyes.

Deliverability

A dedicated sending mailbox needs its own reputation to build and its own delivery infrastructure to run correctly — that is a specialized, ongoing concern in its own right. A shared inbox already has an established sending domain; work an agent does there rides on reputation the team already has, for better or worse.

Audit

Inside a shared inbox, every agent action is one entry in a shared operating record alongside human replies from the same address — trigger, permission level, and outcome all attach to a thread the team can already see. An agent with its own mailbox needs its own audit trail, built and owned separately, because nothing else touches that address.

Blast radius

A shared-inbox agent's mistakes are bounded by the workflow rules that scope it: a recipient restriction, a sending limit, a review requirement, a kill switch that stops the specific workflow. A mistake from an agent with its own mailbox and its own sending credentials is bounded by whatever that separate system enforces — there is no shared inbox's existing controls to inherit.

Which case DuoInbox is for

DuoInbox serves only the second case. It is built for a team that already owns a shared Google Workspace inbox and wants Hermes to work inside it under policy — matched by a trigger rule, held to a permission level, restricted on recipients and sending, and stopped by a kill switch when needed. DuoInbox's initial focus is Google Workspace shared inboxes and Hermes.

If your agent is the counterparty — its own address, its own sending relationship with recipients, no existing team inbox behind it — DuoInbox is not the answer to that problem. That is an email-sending and email-receiving infrastructure decision, and it sits outside what this product offers. Look at dedicated email infrastructure for that case rather than trying to fit it into a shared-inbox tool.

If you are choosing between vendors rather than between architectures, AI agents for Gmail: sort the landscape by access model sorts published AI-agent offerings by how each one actually reaches a mailbox, sourced from each vendor's own pages.

If you recognized the second case, the governance layer this page describes — triggers, permission levels, review, audit, and a kill switch — is explained in full in the Gmail MCP for AI agents guide, which also covers how DuoInbox gives Hermes governed mail access through MCP rather than direct Gmail credentials.

Frequently asked questions

Can an agent start in the team's inbox and move to its own mailbox later?

Yes. Teams often start an agent inside a shared inbox under policy, because that is where the workflow already lives. If the agent later becomes a counterparty in its own right — sending and receiving on its own identity, independent of the team's queue — that is a separate build with its own sending identity and infrastructure, not an upgrade to the shared-inbox setup.

Does DuoInbox give the agent its own email address?

No. DuoInbox gives Hermes governed access to the team's shared inbox through MCP, scoped to a matched trigger and a permission level, rather than a mailbox or credentials of its own.

What if we are not sure which case we are?

Ask who currently owns replies to the customer when a human handles them. If the answer is a named inbox or a team, the agent joining that inbox is the second case. If there is no existing inbox because the sending party has always been a system, the agent is the counterparty and belongs in the first case.

Can the two architectures be combined for different parts of the business?

Yes, and it is common. A transactional system might send receipts and notifications on its own address, while support@ or orders@ stays a shared inbox where an agent works under policy alongside people. The two architectures answer different questions and can sit side by side.