{
  "data": {
    "author": "Quynh Tran-Thanh",
    "faq": null,
    "kicker": "Blog · Opinion · 26 October 2026",
    "lede": "An agent can read an email, write a reply and call an API. Gmail already has an API. So why are we building a whole new category of inboxes for agents?",
    "readingMinutes": 16,
    "words": 3666
  },
  "kind": "anchor.page",
  "links": {
    "api": "https://www.anchorterminal.com/api/v1/index.json",
    "html": "https://www.anchorterminal.com/blog/why-an-ai-agent-needs-a-different-inbox",
    "json": "https://www.anchorterminal.com/blog/why-an-ai-agent-needs-a-different-inbox.json",
    "llms": "https://www.anchorterminal.com/llms.txt",
    "markdown": "https://www.anchorterminal.com/blog/why-an-ai-agent-needs-a-different-inbox.md",
    "mcp": "https://www.anchorterminal.com/mcp",
    "slim": "https://www.anchorterminal.com/blog/why-an-ai-agent-needs-a-different-inbox.min.md"
  },
  "markdown": "By Quynh Tran-Thanh, 26 October 2026. 3,666 words, about 16 min to read.\n\nAn agent can read an email, write a reply and call an API. Gmail already has an API. So why are we building a whole new category of inboxes for agents?\n\nAn agent doesn’t always need a different email service. But when it runs a workflow, the product needs to handle work that a person would otherwise do around the inbox:\n\n1. **Message discovery.** Detect when new email arrives and trigger the right workflow, including catching up on messages missed while the agent was offline.\n2. **Context.** Separate the latest request from quoted history, find attachments and connect the conversation to the current state of the task.\n3. **Permissions.** Define what the agent is allowed to do. Reading a quote, drafting a reply and approving a deposit require different levels of authority.\n4. **Human handoff.** Show what the agent has done, let someone take over or review its reply, and prevent both from answering at once.\n5. **Mailbox management.** If each customer or workflow needs a separate mailbox, create, restrict and retire those mailboxes through the application.\n\nThese are reasons to evaluate different capabilities. They don’t automatically justify another provider. Some come with existing mailbox APIs, some are packaged by specialist services, and some remain your product’s responsibility whichever service you choose.\n\nThat’s the comparison I want to make: which parts of this work are we buying, and which parts are we still building?\n\n## The work happening outside the inbox\n\nImagine asking an agent to collect quotes from three suppliers for an event.\n\nThe first supplier sends a PDF. The second asks how many people are coming. The third replies two days later, after you’ve already changed the date.\n\nIf I were doing this, I would carry some of the context myself. I know the date changed because I was in the meeting. I remember that one quote excludes delivery. I know I can ask for a discount, but I need someone else to approve the deposit.\n\nSome of that information might be in email. Some is in a spreadsheet. Some is just in my head, which is not exactly a reliable database either.\n\nFor an agent, we need to make those connections explicit. Which event does this thread belong to? What is the current date? What has already been promised? What is the agent allowed to do next?\n\nA thread stores the conversation. Your application still needs to store the state of the work.\n\nThat distinction is easy to miss when the demo only shows one email arriving and one beautiful reply going out.\n\n## Do you need a new provider, or better integration with your existing inbox?\n\nGmail already exposes threads through its API, including ordered messages, drafts and replies. Google Workspace also has an administration API for creating users, subject to the organisation’s setup and mail licensing. Programmatic email did not begin with agents [[1]](#ref-1) [[2]](#ref-2).\n\n- [Gmail API](https://www.anchorterminal.com/tools/gmail-api.md), A. Threads, drafts and replies on an existing mailbox\n- [Outlook Mail (Microsoft Graph)](https://www.anchorterminal.com/tools/outlook-mail-graph.md), B. The same job for Microsoft 365 mailboxes\n\nExisting mailbox APIs on Anchor\n\nThe difference is in how much work the service packages for your application.\n\nA dedicated inbox API can make creating an address, retrieving parsed messages and routing replies feel like ordinary application operations. That can be useful when your product creates mailboxes for customers or workflows throughout the day.\n\nIt may be much less important for one assistant helping one person with an existing mailbox.\n\nSo I would separate two decisions early: does the agent need its own mailbox, and do we need a different provider to host it?\n\nThose are not the same purchase.\n\n| Decision | The question | Not the same as |\n| --- | --- | --- |\n| Its own mailbox | Does the agent need its own address, history and access rules? | Choosing who hosts that mailbox |\n| A different provider | Do we need a different provider to host it? | Deciding the agent needs a mailbox at all |\n\n## Where the friction actually shows up\n\nThose five requirements become easier to understand when we follow the supplier conversation through the workflow.\n\n### 1. Message discovery\n\nWhen I return to my inbox, I can see messages I missed. A background agent needs a dependable mechanism to discover them and resume work.\n\nWith Gmail, push notifications use Google Cloud Pub/Sub. The notification gives your application a history ID; it then retrieves the changes. Watches need renewing at least every seven days, and Google documents that notifications can occasionally be delayed or dropped, so applications need a recovery path [[3]](#ref-3).\n\nAll manageable. But it is integration work someone owns.\n\nA provider offering direct inbound webhooks may remove some of that plumbing. I would still ask what happens when my application is offline, how events are retried, and how I retrieve anything I missed. A webhook alone doesn’t finish the reliability work.\n\n|  | Gmail push notifications | Direct inbound webhooks |\n| --- | --- | --- |\n| 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 |\n| What you keep up | Watches renewed at least every seven days | Whatever the provider requires |\n| 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 |\n\n\u003e **Product features to look for**\n\n\u003e\n\n\u003e 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.\n\n### 2. Context\n\nAn email might contain a two-line answer, six quoted replies, a signature and an attachment called `quote-final-v3.pdf`.\n\nI can usually skim past the old replies. An agent needs the relevant content assembled for it. Sending the entire history to the model every time can add cost, noise and opportunities to confuse an old request with a new one.\n\nParsed text, attachment access and reliable threading help. Mailtrap, for example, documents structured incoming messages, conversation threading and sandbox testing [[4]](#ref-4).\n\n- [Mailtrap Email API + MCP](https://www.anchorterminal.com/tools/mailtrap.md), B. Structured incoming messages, conversation threading and sandbox testing\n\nBut a cleaner message still won’t tell the agent whether the event date in our spreadsheet changed this morning. That connection belongs in the product.\n\nThe context also includes what work has already happened. Reading something cannot mean the task is finished.\n\nSuppose the agent reads the supplier’s quote, starts comparing prices, then crashes.\n\nWhen it restarts, the message may already be marked read. Has the quote been processed? Was a reply sent? Is someone reviewing it?\n\nWe need explicit states such as received, processing, waiting for approval and completed. We also need a record of actions already taken, so a repeated event doesn’t produce another reply or another booking.\n\nThis is familiar workflow engineering. Conventional automation needs it too. The model adds another complication: it may interpret the same ambiguous request differently on a second attempt.\n\nAn inbox service can help with message IDs, delivery events and retry-safe sending. It cannot automatically make a booking in a separate system happen exactly once. Your application has to coordinate that.\n\n\u003e **Product features to look for**\n\n\u003e\n\n\u003e 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.\n\n### 3. Permissions\n\nThe supplier agent needs the event brief and its supplier conversations. It probably doesn’t need access to payroll emails.\n\nA separate mailbox can make that boundary easier to enforce. An alias forwarding into the same mailbox does not, by itself, create an access boundary. The credentials still determine what the agent can read.\n\nAnd permission names deserve a closer look. Gmail’s `gmail.compose` scope includes both managing drafts and sending emails. If your product promises “draft only”, you need to enforce that promise in the tools or service layer you expose to the agent [[5]](#ref-5).\n\nThen there’s the authority to act on the content. A supplier saying “please confirm the booking” is making a request. They are not granting the agent permission to spend the deposit.\n\nIncoming messages can also contain instructions intended to redirect the agent. A separate inbox reduces the unrelated data it can reach, but doesn’t make those instructions trustworthy [[6]](#ref-6).\n\nThe product needs to decide which actions are allowed before an email asks for them.\n\n| Action in the supplier example | Level of authority |\n| --- | --- |\n| Reading a quote | Reading the supplier conversations |\n| Drafting a reply | Drafting, which `gmail.compose` grants together with sending |\n| Approving a deposit | Spending money, which a supplier’s email can’t grant |\n\n\u003e **Product features to look for**\n\n\u003e\n\n\u003e 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.\n\n### 4. Human handoff\n\nAt some point, someone will want to take over.\n\nCan 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?\n\nResend’s recently announced Inboxes includes shared conversations, drafts and configurable agent actions. These are relevant capabilities to evaluate for a mixed human-and-agent workflow [[7]](#ref-7).\n\n- [Resend API + MCP](https://www.anchorterminal.com/tools/resend.md), BB. Shared conversations, drafts and configurable agent actions\n\nBut I would still test the handoff. Having a shared screen and preventing two actors from answering at the same time are different requirements.\n\n\u003e **Product features to look for**\n\n\u003e\n\n\u003e 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.\n\n### 5. Mailbox management\n\nOne supplier agent can use one dedicated mailbox. But suppose we offer this product to hundreds of event organisers. Each customer needs their conversations kept separate, with access we can grant and revoke independently.\n\nNow creating a mailbox becomes part of onboarding. We also need to decide what happens when a customer leaves: stop the agent, preserve the history for the agreed retention period, and handle suppliers who reply afterwards.\n\nThis is where programmatic inbox creation becomes useful. AgentMail, for example, exposes inboxes as API resources. Google Workspace also supports account creation through its administration API, but with its own licensing and administration requirements. The comparison is how well each approach fits the lifecycle of our product [[8]](#ref-8) [[2]](#ref-2).\n\n|  | AgentMail | Google Workspace |\n| --- | --- | --- |\n| How a mailbox is created | Inboxes are API resources | Account creation through its administration API |\n| What comes with it |  | Its own licensing and administration requirements |\n\n- [AgentMail API + MCP](https://www.anchorterminal.com/tools/agentmail.md), BB. Inboxes as API resources\n\nMore addresses alone won’t give us isolation. We need to check that the credentials, stored messages and application routing respect the same customer boundaries.\n\n\u003e **Product features to look for**\n\n\u003e\n\n\u003e 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.\n\n## What are you actually buying?\n\nThe providers become easier to compare once the job is clear.\n\n| Product you are building | Starting point to evaluate | Why |\n| --- | --- | --- |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n\nThese are architectural starting points, not performance rankings. Nylas documents access to existing provider accounts, AgentMail documents programmatically created inboxes, and Cloudflare documents sending and incoming routing. The exact limits and responsibilities differ [[9]](#ref-9) [[8]](#ref-8) [[10]](#ref-10).\n\n- [Gmail API](https://www.anchorterminal.com/tools/gmail-api.md), A. Someone’s existing Gmail\n- [Outlook Mail (Microsoft Graph)](https://www.anchorterminal.com/tools/outlook-mail-graph.md), B. Someone’s existing Microsoft 365 mail\n- [Nylas Email API](https://www.anchorterminal.com/tools/nylas-email.md), A. Access to existing provider accounts\n- [AgentMail API + MCP](https://www.anchorterminal.com/tools/agentmail.md), BB. Programmatically created inboxes\n- [Mailtrap Email API + MCP](https://www.anchorterminal.com/tools/mailtrap.md), B. Programmable inboxes and sandbox testing\n- [Resend API + MCP](https://www.anchorterminal.com/tools/resend.md), BB. Shared inboxes for people and agents\n- [Cloudflare Email Service](https://www.anchorterminal.com/tools/cloudflare-email-service.md), B. Sending and incoming routing with Workers\n\nThe starting points in the table, on Anchor\n\nI also wouldn’t create a separate inbox for every model invocation. The address should follow a meaningful boundary: a customer, a business role, or a workflow that needs its own history and access rules.\n\nIf you change models next month, the supplier should still be able to reply to the same address.\n\n## How I would choose from Anchor’s email providers\n\nThe [email delivery category on Anchor](/categories/email) contains providers that can play quite different roles in this product. Comparing them all on the price of a thousand sends would miss most of the decisions above.\n\nFor our supplier agent, I would make the shortlist around the part of the workflow we want the provider to own.\n\n| What we want the provider to own | Providers to compare | What we still build |\n| --- | --- | --- |\n| The conversation layer | Resend, Mailtrap | The parts of review, history and handoff each one leaves to us |\n| Getting inbound email into our product | Postmark, Mailgun | The durable conversation history and review experience |\n| Infrastructure we already use | Cloudflare Email Service, Amazon SES | The logic that decides whether a quote has been approved |\n| Controlled access to sending | AhaSend, SendGrid, MailerSend, SMTP2GO, Groundmail | Task state and human review |\n| A customer messaging workflow | Loops, Mailjet, Brevo, Mailchimp Transactional, Zoho CPaaS | Whether an ordinary workflow does the job first |\n\n### Buy the conversation layer or build it ourselves\n\n**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. Mailtrap’s agent inbox offering emphasises programmable inboxes, parsed messages, threads and sandbox testing [[7]](#ref-7) [[4]](#ref-4).\n\n|  | Resend | Mailtrap |\n| --- | --- | --- |\n| What it emphasises | Shared conversations, assignments, notes and drafts for people and agents | Programmable inboxes, parsed messages, threads and sandbox testing |\n| 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 |\n\n- [Resend API + MCP](https://www.anchorterminal.com/tools/resend.md), BB. Shared conversations, assignments, notes and drafts\n- [Mailtrap Email API + MCP](https://www.anchorterminal.com/tools/mailtrap.md), B. Programmable inboxes, parsed messages, threads and sandbox testing\n\nFor an operations team reviewing supplier conversations every day, I would start by evaluating Resend’s shared workflow. For a product team building its own interface and spending significant time testing incoming messages and generated replies, I would start with Mailtrap. Both could make the shortlist; that’s where I would focus the evaluation, not a claim that either exclusively serves that use case.\n\nThe practical test is the same: a supplier changes the quote while a person is reviewing the draft. Can the product make the old draft visibly stale and stop it being sent? Check what the provider supports and what your application must implement.\n\n**Postmark and Mailgun give us a different starting point.** Postmark delivers parsed inbound email to our application as JSON through a webhook. Mailgun offers routing rules that can forward messages to a URL or temporarily store them for retrieval. That lets us build around incoming email without adopting a shared-inbox product [[11]](#ref-11) [[12]](#ref-12).\n\n|  | Postmark | Mailgun |\n| --- | --- | --- |\n| 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 |\n| 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 |\n\n- [Postmark API + MCP](https://www.anchorterminal.com/tools/postmark.md), B. Parsed inbound email as JSON through a webhook\n- [Mailgun API + MCP](https://www.anchorterminal.com/tools/mailgun.md), B. Routing rules that forward to a URL or store for retrieval\n\nI would consider this route if we already have the supplier dashboard, database and task engine. Our application would own the durable conversation history and review experience. Mailgun’s route storage is documented as lasting up to three days, so I wouldn’t treat it as our permanent archive.\n\nBasically, are we trying to buy an inbox experience, or get email into a product we already have?\n\n### Keep the workflow close to the infrastructure we use\n\n**Cloudflare Email Service versus Amazon SES** is a useful comparison when the team wants to assemble more of the workflow itself.\n\nCloudflare connects incoming routing and outbound sending with Workers. SES receiving rules can store messages in S3 and invoke Lambda processing. Neither architectural route decides whether our supplier’s quote has been approved; we build that logic [[10]](#ref-10) [[13]](#ref-13).\n\n|  | Cloudflare Email Service | Amazon SES |\n| --- | --- | --- |\n| How the workflow is assembled | Incoming routing and outbound sending connected with Workers | Receiving rules that store messages in S3 and invoke Lambda processing |\n| Evaluate it first if | Our application already runs on Workers | Our documents, permissions and background jobs already live in AWS |\n| Also in the decision | The sending service is still labelled beta |  |\n\n- [Cloudflare Email Service](https://www.anchorterminal.com/tools/cloudflare-email-service.md), B. Routing and sending with Workers\n- [Amazon SES](https://www.anchorterminal.com/tools/amazon-ses.md), BB. Receiving rules, S3 and Lambda\n\nIf our application already runs on Workers, I would evaluate Cloudflare first. If our documents, permissions and background jobs already live in AWS, I would evaluate SES first. Existing operational knowledge can matter more than saving a small amount on sending. Cloudflare’s sending service is still labelled beta, which also belongs in the decision.\n\n### Buy controlled access to sending\n\nSometimes the agent only needs to prepare and send messages from a workflow we already control. We don’t need another conversation store.\n\n**AhaSend is worth comparing on the permission boundary.** Its MCP documentation describes domain restrictions, permission presets and a sandbox-only sending option. Those are concrete things to test if one agent should operate on one business domain without being able to send a live campaign. They do not grant or enforce authority to approve a supplier deposit in another system [[14]](#ref-14).\n\n**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. Their sending capabilities alone don’t settle the separate question of who stores task state or handles human review [[15]](#ref-15) [[16]](#ref-16) [[17]](#ref-17) [[18]](#ref-18).\n\n- [AhaSend API + MCP](https://www.anchorterminal.com/tools/ahasend.md), BB. Domain restrictions, permission presets and sandbox-only sending\n- [Twilio SendGrid](https://www.anchorterminal.com/tools/sendgrid.md), B\n- [MailerSend](https://www.anchorterminal.com/tools/mailersend.md), B\n- [SMTP2GO API + MCP](https://www.anchorterminal.com/tools/smtp2go.md), D\n- [Groundmail API + MCP](https://www.anchorterminal.com/tools/groundmail.md), C\n\nSending providers to compare on the actual workload\n\n### Check whether the product is really a customer messaging workflow\n\n**Loops, Mailjet and Brevo** become more relevant when the requirement is onboarding, reminders or campaigns driven by customer data. Loops combines SaaS lifecycle and transactional email; Mailjet combines campaign tools and developer APIs; Brevo exposes messaging and contact operations [[19]](#ref-19) [[20]](#ref-20) [[21]](#ref-21).\n\nFor a fixed reminder sequence, I would first check whether an ordinary workflow does the job. Adding an agent makes sense when interpreting the response changes what needs to happen next.\n\n**Mailchimp Transactional** merits a look if the team already uses an eligible Mailchimp plan, because it is an add-on. **Zoho CPaaS** merits a look if email belongs alongside SMS, WhatsApp or voice, subject to channel availability. Those existing product requirements may drive the choice more than an agent-specific feature [[22]](#ref-22) [[23]](#ref-23).\n\n| Provider | When it becomes relevant |\n| --- | --- |\n| Loops | SaaS lifecycle and transactional email |\n| Mailjet | Campaign tools and developer APIs |\n| Brevo | Messaging and contact operations |\n| Mailchimp Transactional | The team already uses an eligible Mailchimp plan, because it is an add-on |\n| Zoho CPaaS | Email belongs alongside SMS, WhatsApp or voice, subject to channel availability |\n\n- [Loops API + MCP](https://www.anchorterminal.com/tools/loops.md), B. SaaS lifecycle and transactional email\n- [Mailjet API + MCP](https://www.anchorterminal.com/tools/mailjet.md), C. Campaign tools and developer APIs\n- [Brevo API + MCP](https://www.anchorterminal.com/tools/brevo.md), E. Messaging and contact operations\n- [Mailchimp Transactional (Mandrill)](https://www.anchorterminal.com/tools/mandrill.md), C. An add-on to an eligible Mailchimp plan\n- [Zoho CPaaS (formerly ZeptoMail)](https://www.anchorterminal.com/tools/zoho-zeptomail.md), C. Email alongside SMS, WhatsApp or voice\n\n### The decision for our supplier agent\n\nFor a new product with people reviewing quotes and taking over conversations, I would shortlist **Resend and Mailtrap** first. I would compare the effort needed to build review, history and handoff around each.\n\nIf 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 email is only an outbound step, I would narrow the decision to sending and permissions instead of buying an inbox platform.\n\n| If | Shortlist |\n| --- | --- |\n| A new product with people reviewing quotes and taking over conversations | Resend and Mailtrap |\n| We already have the application layer, for inbound processing | Postmark or Mailgun |\n| We already have the application layer, on our existing infrastructure | SES or Cloudflare |\n| Email is only an outbound step | Sending and permissions, not an inbox platform |\n\nI would cost the whole workflow: active inboxes, incoming and outgoing messages, attachment storage, retained history, model calls and the engineering work left to us. These are evaluation priorities based on documented capabilities, not results from hands-on tests. Anchor’s grades also assess public evidence and agent readiness; its category page says performance and task-success testing are pending [[24]](#ref-24).\n\n## The test I would run before choosing\n\nI would take the supplier example and deliberately make it annoying.\n\nDeliver the same event twice. Restart the agent after it drafts a reply. Change the event date halfway through. Let a person answer first. Ask the agent to confirm something outside its authority.\n\nThen inspect what happened.\n\nDid we lose a request? Send two replies? Use an old date? Make a commitment nobody approved? Can a person understand and recover the workflow?\n\nThat gives me a much better basis for choosing a service than a list of supported tools.\n\nAn agent can use an ordinary inbox. The product challenge is making the work around that inbox explicit enough to run without a person quietly filling in the gaps.\n\nSometimes a dedicated service takes a useful amount of that work off your hands. Sometimes it gives you a nicer API while the hard decisions remain yours.\n\nBefore buying one, I would want to know exactly which is happening.\n\n---\n\nMore 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)\n\n- 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)\n- 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)\n- All posts: https://www.anchorterminal.com/blog/index.md\n\n## References\n\n[1] Google, Gmail API, managing threads. Source for threads with ordered messages, drafts and replies through the API. https://developers.google.com/workspace/gmail/api/guides/threads\n\n[2] Google, Workspace Admin SDK Directory API, managing user accounts. Source for creating users through the administration API, subject to setup and licensing. https://developers.google.com/workspace/admin/directory/v1/guides/manage-users\n\n[3] Google, Gmail API, push notifications. Source for Pub/Sub delivery, history IDs, renewing watches at least every seven days and notifications that can be delayed or dropped. https://developers.google.com/workspace/gmail/api/guides/push\n\n[4] Mailtrap, agent inboxes. Source for structured incoming messages, conversation threading, programmable inboxes and sandbox testing. https://mailtrap.io/agent-inbox/\n\n[5] Google, Gmail API, choosing scopes. Source for `gmail.compose` covering both managing drafts and sending email. https://developers.google.com/workspace/gmail/api/auth/scopes\n\n[6] Anthropic, prompt-injection defences. Source for instructions in incoming content intended to redirect an agent. https://www.anthropic.com/research/prompt-injection-defenses\n\n[7] Resend, announcing Inboxes. Source for shared conversations, assignments, notes, drafts and configurable agent actions. https://resend.com/blog/announcing-inboxes\n\n[8] AgentMail, inboxes. Source for inboxes as API resources created programmatically. https://docs.agentmail.to/inboxes\n\n[9] Nylas, email API documentation. Source for access to existing provider accounts. https://developer.nylas.com/docs/v3/email/\n\n[10] Cloudflare, Email Service. Source for sending and incoming routing with Workers, and the sending service's beta label. https://developers.cloudflare.com/email-service/\n\n[11] Postmark, inbound processing. Source for parsed inbound email delivered as JSON through a webhook. https://postmarkapp.com/developer/user-guide/inbound\n\n[12] Mailgun, route actions. Source for routing rules that forward to a URL or store messages for retrieval, for up to three days. https://documentation.mailgun.com/docs/mailgun/user-manual/receive-forward-store/route-actions\n\n[13] Amazon Web Services, SES email receiving concepts. Source for receiving rules that store messages in S3 and invoke Lambda. https://docs.aws.amazon.com/ses/latest/dg/receiving-email-concepts.html\n\n[14] AhaSend, MCP server. Source for domain restrictions, permission presets and sandbox-only sending. https://ahasend.com/docs/mcp-server\n\n[15] Twilio, SendGrid email API. Source for SendGrid as a sending provider. https://www.twilio.com/en-us/products/email-api\n\n[16] MailerSend. Source for MailerSend as a sending provider. https://www.mailersend.com/\n\n[17] SMTP2GO. Source for SMTP2GO as a sending provider. https://www.smtp2go.com/\n\n[18] Groundmail. Source for Groundmail as a sending provider. https://groundmail.dev/\n\n[19] Loops. Source for SaaS lifecycle and transactional email. https://loops.so/\n\n[20] Mailjet. Source for campaign tools and developer APIs. https://www.mailjet.com/\n\n[21] Brevo, API getting started. Source for messaging and contact operations through the API. https://developers.brevo.com/docs/getting-started\n\n[22] Mailchimp, transactional email. Source for Mailchimp Transactional as an add-on to eligible plans. https://mailchimp.com/features/transactional-email/\n\n[23] Zoho, CPaaS. Source for email alongside SMS, WhatsApp and voice, subject to channel availability. https://www.zoho.com/cpaas/\n\n[24] Anchor Terminal, email delivery category. Source for grades that assess public evidence and agent readiness, with performance and task-success testing pending. https://www.anchorterminal.com/categories/email\n",
  "meta": {
    "attribution": "Anchor Terminal (https://www.anchorterminal.com)",
    "attributionRequired": true,
    "credit": "CC BY 4.0, credit Anchor Terminal and link the page or API address you took it from (https://www.anchorterminal.com/terms/#data)",
    "docs": "https://www.anchorterminal.com/docs/",
    "generatedAt": "2026-10-26",
    "license": "CC-BY-4.0",
    "method": "https://www.anchorterminal.com/benchmark/",
    "methodology": "0.6",
    "openapi": "https://www.anchorterminal.com/openapi.json",
    "preview": false,
    "run": "2026-10-01",
    "runLabel": "October 2026 research run",
    "terms": "https://www.anchorterminal.com/terms/#data"
  },
  "page": {
    "breadcrumbs": [
      {
        "name": "Home",
        "url": "https://www.anchorterminal.com/"
      },
      {
        "name": "Blog",
        "url": "https://www.anchorterminal.com/blog/"
      },
      {
        "name": "Opinion",
        "url": "https://www.anchorterminal.com/blog/opinion/"
      },
      {
        "name": "A different inbox for agents",
        "url": ""
      }
    ],
    "description": "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.",
    "facts": null,
    "h1": "Why does an AI agent need a different inbox anyway?",
    "image": "https://www.anchorterminal.com/assets/og/blog-why-an-ai-agent-needs-a-different-inbox.png",
    "path": "/blog/why-an-ai-agent-needs-a-different-inbox",
    "published": "2026-10-26",
    "section": "blog",
    "title": "Does an AI agent need its own inbox? Gmail, AgentMail and Resend | Anchor Terminal",
    "toc": null,
    "updated": "2026-10-26",
    "url": "https://www.anchorterminal.com/blog/why-an-ai-agent-needs-a-different-inbox"
  },
  "tokens": {
    "markdown": 8050,
    "slim": 5180
  },
  "version": 1
}