01
One address per job
A separate inbox keeps the blast radius small. Revoking one agent does not disturb the others, and the thread history stays with the job rather than with a person.
Use cases
What AI agents actually use email for
Four jobs worth their own inbox, and the permission, rule and thread each one needs.
The shape is the same every time
Every job below is the same three decisions: which address the mail arrives at, how much the agent may do with it, and whether a person sees the reply before it leaves.
02
One permission level
Read only, read and draft, or send. Read-and-draft is the honest default for anything that touches money or a customer relationship.
03
One rule about approval
The inbox policy decides what is held: everything, new recipient domains, anything with an attachment, or nothing at all.
Four recipes
Pick one to see the inbound message, what the agent drafted, whether it went out, and the events the API emits along the way.
Annual billing?
Can I move my seat to annual billing before renewal?
Agent
Yes — three steps in your billing page, takes a minute.
Sent without review message.received · message.queued · message.accepted
Q3 invoice · 1 attachment
Invoice attached — please confirm the PO reference.
Agent
Confirmed, PO 4412. Payment runs Friday.
Waiting on your approval message.received · approval.requested · approval.approved
Re: intro call
Does Thursday afternoon work for you both?
Agent
Thursday 3pm works — invite is on its way.
Sent without review message.received · message.queued · message.accepted
Following up on the audit
Sure — send the docs over and I'll sign today.
Agent
Sending now, signature link included.
Reply routed to the agent message.accepted · message.delivery_updated · message.received
-
Support triage
Read + send
A dedicated support address the agent reads. It answers the routine questions itself and escalates the rest, and the inbox policy decides whether a reply goes out or waits for a person.
Read the support triage guide -
Invoices and AP
Read + draft
Bills arrive at one address and the attachment bytes stay unavailable until the scan clears. The agent files the invoice and drafts the confirmation; the send waits in the approval queue.
Read the invoice intake guide -
Scheduling
Read + send
The back-and-forth about times runs on the agent's own thread, so a half-negotiated slot never lands in a person's inbox and the history stays with the job rather than with a colleague.
-
Outbound that replies
Read + send
Mail the agent sends comes back to the agent. Replies route to the inbox that sent them instead of to whoever holds the credential, so the whole exchange stays on one thread.
What none of these solves
Worth saying out loud before you wire one of them up.
It does not decide for you
These are application permissions, not judgement. An agent with send access will send what it decides to send; the approval queue exists because that is sometimes the wrong call.
It is not prompt-injection proof
Nothing written in an inbound message can widen a grant — scopes are re-derived per request — but an agent can still be talked into a bad draft. Hold sends for review where the cost of a wrong one is high.
Acceptance is not delivery
A provider accepting a message means it was queued for the internet, not that it reached a person. Delivery updates arrive as separate events, and some never arrive at all.
Start with one
The fastest honest test is a test inbox: simulate an inbound message, let the agent draft, approve it, and read the events — without a real recipient anywhere.
Test an agent's email without sending real mail · Approvals and permission controls · Connect an MCP client