# Why does an AI agent need a different inbox anyway? (slim)

> Quynh Tran-Thanh on what an agent needs around an inbox (message discovery, context, permissions, human handoff and mailbox management), which parts an email provider takes on and which stay with your product, and how she would shortlist Anchor's email providers for a supplier agent.

- Full: https://www.anchorterminal.com/blog/why-an-ai-agent-needs-a-different-inbox.md (~8,050 tokens) · this version ~5,180 tokens · JSON https://www.anchorterminal.com/blog/why-an-ai-agent-needs-a-different-inbox.json · canonical https://www.anchorterminal.com/blog/why-an-ai-agent-needs-a-different-inbox
- Index: https://www.anchorterminal.com/llms.txt · API: https://www.anchorterminal.com/api/v1/index.json · MCP: https://www.anchorterminal.com/mcp · Updated: 2026-10-26
- Licence: CC BY 4.0, credit Anchor Terminal and link this page (https://www.anchorterminal.com/terms/#data)

By Quynh Tran-Thanh, 26 October 2026. 3,666 words, about 16 min to read.

An agent can read an email, write a reply and call an API.

An agent doesn’t always need a different email service.

1. **Message discovery.** Detect when new email arrives and trigger the right workflow, including catching up on messages missed while the agent was offline.
2. **Context.** Separate the latest request from quoted history, find attachments and connect the conversation to the current state of the task.
3. **Permissions.** Define what the agent is allowed to do. Reading a quote, drafting a reply and approving a deposit require different levels of authority.
4. **Human handoff.** Show what the agent has done, let someone take over or review its reply, and prevent both from answering at once.
5. **Mailbox management.** If each customer or workflow needs a separate mailbox, create, restrict and retire those mailboxes through the application.

These are reasons to evaluate different capabilities.

That’s the comparison I want to make: which parts of this work are we buying, and which parts are we still building?

## The work happening outside the inbox

Imagine asking an agent to collect quotes from three suppliers for an event.

The first supplier sends a PDF.

If I were doing this, I would carry some of the context myself.

Some of that information might be in email.

For an agent, we need to make those connections explicit.

A thread stores the conversation.

That distinction is easy to miss when the demo only shows one email arriving and one beautiful reply going out.

## Do you need a new provider, or better integration with your existing inbox?

Gmail already exposes threads through its API, including ordered messages, drafts and replies.

- [Gmail API](https://www.anchorterminal.com/tools/gmail-api.md), A. Threads, drafts and replies on an existing mailbox
- [Outlook Mail (Microsoft Graph)](https://www.anchorterminal.com/tools/outlook-mail-graph.md), B. The same job for Microsoft 365 mailboxes

Existing mailbox APIs on Anchor

The difference is in how much work the service packages for your application.

A dedicated inbox API can make creating an address, retrieving parsed messages and routing replies feel like ordinary application operations.

It may be much less important for one assistant helping one person with an existing mailbox.

So I would separate two decisions early: does the agent need its own mailbox, and do we need a different provider to host it?

Those are not the same purchase.

| Decision | The question | Not the same as |
| --- | --- | --- |
| Its own mailbox | Does the agent need its own address, history and access rules? | Choosing who hosts that mailbox |
| A different provider | Do we need a different provider to host it? | Deciding the agent needs a mailbox at all |

## Where the friction actually shows up

Those five requirements become easier to understand when we follow the supplier conversation through the workflow.

### 1. Message discovery

When I return to my inbox, I can see messages I missed.

With Gmail, push notifications use Google Cloud Pub/Sub.

All manageable.

A provider offering direct inbound webhooks may remove some of that plumbing.

|  | Gmail push notifications | Direct inbound webhooks |
| --- | --- | --- |
| How new mail is signalled | Google Cloud Pub/Sub, with a history ID your application uses to retrieve the changes | The provider calls your application |
| What you keep up | Watches renewed at least every seven days | Whatever the provider requires |
| When something is missed | Notifications can occasionally be delayed or dropped, so you need a recovery path | Ask what happens when your application is offline, how events are retried, and how you retrieve anything missed |

> **Product features to look for**

>

> Incoming-message notifications, documented retry behaviour, stable event IDs for deduplication, and a way to retrieve missed messages. Check whether subscriptions renew automatically and whether failed notifications can be inspected and replayed.

### 2. Context

An email might contain a two-line answer, six quoted replies, a signature and an attachment called `quote-final-v3.pdf`.

I can usually skim past the old replies.

Parsed text, attachment access and reliable threading help.

- [Mailtrap Email API + MCP](https://www.anchorterminal.com/tools/mailtrap.md), B. Structured incoming messages, conversation threading and sandbox testing

But a cleaner message still won’t tell the agent whether the event date in our spreadsheet changed this morning.

The context also includes what work has already happened.

Suppose the agent reads the supplier’s quote, starts comparing prices, then crashes.

When it restarts, the message may already be marked read.

We need explicit states such as received, processing, waiting for approval and completed.

This is familiar workflow engineering.

An inbox service can help with message IDs, delivery events and retry-safe sending.

> **Product features to look for**

>

> Parsed message bodies, quoted-reply extraction, attachment access, searchable conversation history and stable thread IDs. Look for metadata or links to your own task records, plus idempotency keys for retry-safe sends. Confirm where processing status and completed actions will be stored; conversation history alone is not task state.

### 3. Permissions

The supplier agent needs the event brief and its supplier conversations.

A separate mailbox can make that boundary easier to enforce.

And permission names deserve a closer look.

Then there’s the authority to act on the content.

Incoming messages can also contain instructions intended to redirect the agent.

The product needs to decide which actions are allowed before an email asks for them.

| Action in the supplier example | Level of authority |
| --- | --- |
| Reading a quote | Reading the supplier conversations |
| Drafting a reply | Drafting, which `gmail.compose` grants together with sending |
| Approving a deposit | Spending money, which a supplier’s email can’t grant |

> **Product features to look for**

>

> Credentials scoped to specific mailboxes or domains, separately enforced read, draft and send permissions, revocable access and action logs. Check for recipient restrictions and approval gates where needed. Verify what the service enforces itself and what your application must enforce, especially for actions outside email.

### 4. Human handoff

At some point, someone will want to take over.

Can they see the draft, the relevant messages and what the agent already did? Can they pause it? What happens if they reply while the agent is still preparing its own answer?

Resend’s recently announced Inboxes includes shared conversations, drafts and configurable agent actions.

- [Resend API + MCP](https://www.anchorterminal.com/tools/resend.md), BB. Shared conversations, drafts and configurable agent actions

But I would still test the handoff.

> **Product features to look for**

>

> Shared conversation views, editable drafts, assignment, approval controls and a way to pause the agent. Look for a record of who acted, checks that invalidate drafts after a new reply, and controls that prevent a person and an agent from sending competing responses.

### 5. Mailbox management

One supplier agent can use one dedicated mailbox.

Now creating a mailbox becomes part of onboarding.

This is where programmatic inbox creation becomes useful.

|  | AgentMail | Google Workspace |
| --- | --- | --- |
| How a mailbox is created | Inboxes are API resources | Account creation through its administration API |
| What comes with it |  | Its own licensing and administration requirements |

- [AgentMail API + MCP](https://www.anchorterminal.com/tools/agentmail.md), BB. Inboxes as API resources

More addresses alone won’t give us isolation.

> **Product features to look for**

>

> APIs to create, disable and delete inboxes; access isolation between customers; custom domains; and documented provisioning limits. Check retention, export and deletion controls, what happens to late replies after an inbox is disabled, and pricing as the number of active mailboxes grows.

## What are you actually buying?

The providers become easier to compare once the job is clear.

| Product you are building | Starting point to evaluate | Why |
| --- | --- | --- |
| An assistant that summarises or drafts replies to someone’s existing mail | Gmail API, Microsoft Graph, or a connector such as Nylas | The existing identity and history are part of the product. A new empty inbox doesn’t replace them. |
| One internal agent with a clearly separate role | A dedicated mailbox on your existing provider | You may need separation without needing a new email platform. Check access controls and administration costs. |
| A product that creates and retires inboxes for many customers or workflows | A programmable inbox service such as AgentMail; also evaluate Mailtrap’s inbox offering | Provisioning, message storage and inbound handling become recurring application operations. |
| A team where people and agents share customer conversations | Shared inbox capabilities such as Resend Inboxes, or your existing support system | Ownership, drafts, pause controls and handoffs become central to the experience. |
| A narrow workflow that receives documents and sends acknowledgements | Inbound processing plus a delivery service, potentially using Cloudflare Workers or your own application | You may be able to keep the workflow simpler than a full mailbox product. |

These are architectural starting points, not performance rankings.

- [Gmail API](https://www.anchorterminal.com/tools/gmail-api.md), A. Someone’s existing Gmail
- [Outlook Mail (Microsoft Graph)](https://www.anchorterminal.com/tools/outlook-mail-graph.md), B. Someone’s existing Microsoft 365 mail
- [Nylas Email API](https://www.anchorterminal.com/tools/nylas-email.md), A. Access to existing provider accounts
- [AgentMail API + MCP](https://www.anchorterminal.com/tools/agentmail.md), BB. Programmatically created inboxes
- [Mailtrap Email API + MCP](https://www.anchorterminal.com/tools/mailtrap.md), B. Programmable inboxes and sandbox testing
- [Resend API + MCP](https://www.anchorterminal.com/tools/resend.md), BB. Shared inboxes for people and agents
- [Cloudflare Email Service](https://www.anchorterminal.com/tools/cloudflare-email-service.md), B. Sending and incoming routing with Workers

The starting points in the table, on Anchor

I also wouldn’t create a separate inbox for every model invocation.

If you change models next month, the supplier should still be able to reply to the same address.

## How I would choose from Anchor’s email providers

The [email delivery category on Anchor](/categories/email) contains providers that can play quite different roles in this product.

For our supplier agent, I would make the shortlist around the part of the workflow we want the provider to own.

| What we want the provider to own | Providers to compare | What we still build |
| --- | --- | --- |
| The conversation layer | Resend, Mailtrap | The parts of review, history and handoff each one leaves to us |
| Getting inbound email into our product | Postmark, Mailgun | The durable conversation history and review experience |
| Infrastructure we already use | Cloudflare Email Service, Amazon SES | The logic that decides whether a quote has been approved |
| Controlled access to sending | AhaSend, SendGrid, MailerSend, SMTP2GO, Groundmail | Task state and human review |
| A customer messaging workflow | Loops, Mailjet, Brevo, Mailchimp Transactional, Zoho CPaaS | Whether an ordinary workflow does the job first |

### Buy the conversation layer or build it ourselves

**Resend and Mailtrap would be my first comparison if the product needs a persistent inbox.** Resend’s Inboxes announcement emphasises shared conversations, assignments, notes and drafts for people and agents.

|  | Resend | Mailtrap |
| --- | --- | --- |
| What it emphasises | Shared conversations, assignments, notes and drafts for people and agents | Programmable inboxes, parsed messages, threads and sandbox testing |
| Where I would start evaluating it | An operations team reviewing supplier conversations every day | A product team building its own interface and testing incoming messages and generated replies |

- [Resend API + MCP](https://www.anchorterminal.com/tools/resend.md), BB. Shared conversations, assignments, notes and drafts
- [Mailtrap Email API + MCP](https://www.anchorterminal.com/tools/mailtrap.md), B. Programmable inboxes, parsed messages, threads and sandbox testing

For an operations team reviewing supplier conversations every day, I would start by evaluating Resend’s shared workflow.

The practical test is the same: a supplier changes the quote while a person is reviewing the draft.

**Postmark and Mailgun give us a different starting point.** Postmark delivers parsed inbound email to our application as JSON through a webhook.

|  | Postmark | Mailgun |
| --- | --- | --- |
| How inbound email reaches us | Parsed inbound email as JSON through a webhook | Routing rules that forward messages to a URL or temporarily store them for retrieval |
| What to keep in mind | Our application owns the durable conversation history | Route storage is documented as lasting up to three days, so not a permanent archive |

- [Postmark API + MCP](https://www.anchorterminal.com/tools/postmark.md), B. Parsed inbound email as JSON through a webhook
- [Mailgun API + MCP](https://www.anchorterminal.com/tools/mailgun.md), B. Routing rules that forward to a URL or store for retrieval

I would consider this route if we already have the supplier dashboard, database and task engine.

Basically, are we trying to buy an inbox experience, or get email into a product we already have?

### Keep the workflow close to the infrastructure we use

**Cloudflare Email Service versus Amazon SES** is a useful comparison when the team wants to assemble more of the workflow itself.

Cloudflare connects incoming routing and outbound sending with Workers.

|  | Cloudflare Email Service | Amazon SES |
| --- | --- | --- |
| How the workflow is assembled | Incoming routing and outbound sending connected with Workers | Receiving rules that store messages in S3 and invoke Lambda processing |
| Evaluate it first if | Our application already runs on Workers | Our documents, permissions and background jobs already live in AWS |
| Also in the decision | The sending service is still labelled beta |  |

- [Cloudflare Email Service](https://www.anchorterminal.com/tools/cloudflare-email-service.md), B. Routing and sending with Workers
- [Amazon SES](https://www.anchorterminal.com/tools/amazon-ses.md), BB. Receiving rules, S3 and Lambda

If our application already runs on Workers, I would evaluate Cloudflare first.

### Buy controlled access to sending

Sometimes the agent only needs to prepare and send messages from a workflow we already control.

**AhaSend is worth comparing on the permission boundary.** Its MCP documentation describes domain restrictions, permission presets and a sandbox-only sending option.

**SendGrid, MailerSend, SMTP2GO and Groundmail** also belong in a sending evaluation: compare the required API operations, delivery diagnostics, support, account limits and costs for the actual workload.

- [AhaSend API + MCP](https://www.anchorterminal.com/tools/ahasend.md), BB. Domain restrictions, permission presets and sandbox-only sending
- [Twilio SendGrid](https://www.anchorterminal.com/tools/sendgrid.md), B
- [MailerSend](https://www.anchorterminal.com/tools/mailersend.md), B
- [SMTP2GO API + MCP](https://www.anchorterminal.com/tools/smtp2go.md), D
- [Groundmail API + MCP](https://www.anchorterminal.com/tools/groundmail.md), C

Sending providers to compare on the actual workload

### Check whether the product is really a customer messaging workflow

**Loops, Mailjet and Brevo** become more relevant when the requirement is onboarding, reminders or campaigns driven by customer data.

For a fixed reminder sequence, I would first check whether an ordinary workflow does the job.

**Mailchimp Transactional** merits a look if the team already uses an eligible Mailchimp plan, because it is an add-on.

| Provider | When it becomes relevant |
| --- | --- |
| Loops | SaaS lifecycle and transactional email |
| Mailjet | Campaign tools and developer APIs |
| Brevo | Messaging and contact operations |
| Mailchimp Transactional | The team already uses an eligible Mailchimp plan, because it is an add-on |
| Zoho CPaaS | Email belongs alongside SMS, WhatsApp or voice, subject to channel availability |

- [Loops API + MCP](https://www.anchorterminal.com/tools/loops.md), B. SaaS lifecycle and transactional email
- [Mailjet API + MCP](https://www.anchorterminal.com/tools/mailjet.md), C. Campaign tools and developer APIs
- [Brevo API + MCP](https://www.anchorterminal.com/tools/brevo.md), E. Messaging and contact operations
- [Mailchimp Transactional (Mandrill)](https://www.anchorterminal.com/tools/mandrill.md), C. An add-on to an eligible Mailchimp plan
- [Zoho CPaaS (formerly ZeptoMail)](https://www.anchorterminal.com/tools/zoho-zeptomail.md), C. Email alongside SMS, WhatsApp or voice

### The decision for our supplier agent

For a new product with people reviewing quotes and taking over conversations, I would shortlist **Resend and Mailtrap** first.

If we already have that application layer, I would compare **Postmark or Mailgun** for inbound processing, and **SES or Cloudflare** where they fit our existing infrastructure.

| If | Shortlist |
| --- | --- |
| A new product with people reviewing quotes and taking over conversations | Resend and Mailtrap |
| We already have the application layer, for inbound processing | Postmark or Mailgun |
| We already have the application layer, on our existing infrastructure | SES or Cloudflare |
| Email is only an outbound step | Sending and permissions, not an inbox platform |

I would cost the whole workflow: active inboxes, incoming and outgoing messages, attachment storage, retained history, model calls and the engineering work left to us.

## The test I would run before choosing

I would take the supplier example and deliberately make it annoying.

Deliver the same event twice.

Then inspect what happened.

Did we lose a request? Send two replies? Use an old date? Make a commitment nobody approved? Can a person understand and recover the workflow?

That gives me a much better basis for choosing a service than a list of supported tools.

An agent can use an ordinary inbox.

Sometimes a dedicated service takes a useful amount of that work off your hands.

Before buying one, I would want to know exactly which is happening.

---

More in [Opinion](https://www.anchorterminal.com/blog/opinion/index.md) · Older opinion [I stopped using git for some small things](https://www.anchorterminal.com/blog/i-stopped-using-git-for-some-small-things.md)

- Older: [Can you run Kimi K3 locally? Not on a desk, and Moonshot never said you could](https://www.anchorterminal.com/blog/run-kimi-k3-locally.md)
- Newer: [I asked an agent to buy a train ticket to Edinburgh, and the one site that worked couldn't hand it over](https://www.anchorterminal.com/blog/i-asked-an-agent-to-buy-a-train-ticket.md)
- All posts: https://www.anchorterminal.com/blog/index.md

## References

[1] Google, Gmail API, managing threads.

[2] Google, Workspace Admin SDK Directory API, managing user accounts.

[3] Google, Gmail API, push notifications.

[4] Mailtrap, agent inboxes.

[5] Google, Gmail API, choosing scopes.

[6] Anthropic, prompt-injection defences.

[7] Resend, announcing Inboxes.

[8] AgentMail, inboxes.

[9] Nylas, email API documentation.

[10] Cloudflare, Email Service.

[11] Postmark, inbound processing.

[12] Mailgun, route actions.

[13] Amazon Web Services, SES email receiving concepts.

[14] AhaSend, MCP server.

[15] Twilio, SendGrid email API.

[16] MailerSend.

[17] SMTP2GO.

[18] Groundmail.

[19] Loops.

[20] Mailjet.

[21] Brevo, API getting started.

[22] Mailchimp, transactional email.

[23] Zoho, CPaaS.

[24] Anchor Terminal, email delivery category.