What Is an Agent Inbox? The Mailbox Your Agent Owns
An agent inbox is an email account an AI agent owns through an API. How it differs from a shared mailbox or an inbound webhook, and when your agent needs one.
- engineering
- agent-inbox
- ai-agents
- email-infrastructure
TL;DR
An agent inbox is an email account that belongs to an AI agent rather than a person, created and read through an API. This article defines the term, separates it from the two setups people often mean instead, and explains when a developer needs one and when sending mail is enough.
The phrase agent inbox now shows up in product pages, docs and design reviews. It means three different things. Sometimes it means an agent signed in to a person's existing mailbox. Sometimes it means a sending service with a webhook that forwards incoming mail to code. And sometimes it means a mailbox that exists only for the agent, created by a program and owned by no human.
Those three setups fail in different ways. The first exposes a person's private mail to whatever the agent reads. The second hands each message over once and leaves storage to you. The third is what products built for agents actually provide. Below is a plain definition and the three side by side, then what a dedicated inbox stores, where reputation lives, and whether your agent needs one.
An agent inbox is an email account created by code
An agent inbox is an email account that an AI agent owns. A program creates it with an API call. It gets its own address. The agent sends, receives and reads mail through that API, not a mail client. Nobody logs in with a password, and no person's history is inside it.
Three properties separate it from a script with mail access. The address belongs to the agent, so replies come back to the agent and not to a human. The mail is stored and grouped into threads, so the agent can read a conversation back days later. And the credentials can be scoped to that one inbox, so a leaked key exposes one agent's mail rather than a company's.
On AgentMail an inbox is exactly this: an API resource with a unique address, created on demand. One organization can run thousands. The inbox docs show how organizations, inboxes, threads and messages fit together.
Three setups go by the name, and they keep different things
What separates the three is what the agent can reach and what survives after a message arrives.
| Setup | What the agent gets | What is kept | Best for |
|---|---|---|---|
| A person's mailbox, shared with the agent | Read and send as that person, inside their account | Everything the person ever received | An assistant whose job is one person's existing mail |
| Send API plus inbound webhook | A send endpoint and one HTTP request per incoming message | Whatever your code saves | Notifications and one-off reply capture you store yourself |
| Dedicated agent inbox | Its own address, stored threads, scoped credentials | Every message sent and received, grouped by conversation | Agents that hold conversations, sign up for services, or run by the hundreds |
All three work. They answer different questions, and the wrong one shows up later as a security review or a pile of glue code.
A shared mailbox gives the agent a person's whole account
Connecting an agent to a person's Gmail or Outlook account is the fastest route to email. The account already exists. The cost is scope. The token the agent holds covers the whole mailbox: contracts, password resets, private threads, and the right to send under that person's name. Google classes the Gmail read and modify scopes as restricted scopes, the tier Google reserves for the widest access to user data.
Sending counts against the person too. Google Workspace allows 2,000 messages per user per day on paid accounts. An agent stuck in a loop spends that budget for someone who never touched it. Our post on borrowed mailboxes and sending APIs covers the account risk in more depth.
An inbound webhook hands you each message once
The second setup starts from a sending service. You point a domain's mail at the provider, and it calls your endpoint for every message that arrives. SendGrid's Inbound Parse is the classic example: it POSTs each message to a URL you choose as multipart form data.
From there, state is your code's job. Matching a reply to its conversation lands in your database. So does stripping quoted history, and so does keeping the thread for the agent's next turn. Some providers now store received mail as well, so check what yours keeps and for how long. The email API vs inbox API post compares the two kinds of API in detail.
A dedicated inbox stores the conversation for the agent
A dedicated inbox keeps the state the other two push onto you. Replies are grouped into threads automatically from standard email headers. Each message carries extracted_text and extracted_html. Those hold only the new content, without the quoted history below it. The agent reads the reply, not five copies of the earlier conversation.
Messages stay searchable by sender, subject and body, and labels let the agent record workflow state on a message. Allow and block lists decide who can reach the inbox and who it can send to. That matters, because anyone who knows an address can put text in front of the agent. The full list is in what an AgentMail inbox can do.
Reputation lives on the domain, not the inbox
Creating a new inbox does not create a new sender reputation. Mailbox providers track reputation per domain, so every inbox on one domain shares it. All inboxes on the shared @agentmail.to domain share that domain's standing, and the Free plan has no custom domains.
An agent whose sending record must stay separate from other senders needs a domain of its own. Custom domains start on the Developer plan, which includes 10. Many agents on one domain also changes routing. The catch-all vs inbox per agent post walks through it.
When a developer needs one and when a send API is enough
The job decides, not the vendor. The agent only sends receipts, alerts or a digest nobody answers: a send API is enough. The agent reads and drafts for one person: connect to that person's mailbox with the narrowest scope the job allows. The agent holds conversations, waits for replies, signs up for services or receives verification codes: it needs its own inbox.
Many agents or many customers push the same way. Each agent then needs its own key, history and audit trail. We built AgentMail for those last two cases. Mailtrap's Agent Inbox and Zoho AgentInbox also sell dedicated inboxes, and Zoho's currently takes signups through a waitlist.
What AgentMail does not do
An agent inbox starts empty. AgentMail cannot hand an agent a person's existing Gmail or Outlook history, so an assistant whose job is that history belongs on the person's mailbox. AgentMail also does not decide what the agent may do with a message. Spam detection and allow lists narrow who reaches the agent. The action policy stays in your application, including when a human approves a send.
