Email API for AI Agents: Six Builds, One Inbox
An agent with an email address can be handed work by anyone, from anywhere, with no UI to build and nothing to install. A customer writes in and it answers. A colleague forwards an invoice and it files it. You email a task from your phone at the airport and a pull request is waiting when you land.
CarlyEmail gives your agent that address in one call, and it does not care what you built the agent with. LangChain, the OpenAI Agents SDK, the Claude Agent SDK, the Vercel AI SDK, Mastra, Cloudflare Agents, or your own runtime all talk to it the same way.
npm install carlyemailimport { CarlyEmail } from "carlyemail";
const carly = new CarlyEmail();
const inbox = await carly.inboxes.create({ username: "support" });
const { messages } = await carly.messages.list(inbox.email);
await carly.messages.reply(inbox.email, messages[0].message_id, { text: "On it." });There is a Python package, a CLI you can start from with npx carlyemail signup, and a plain REST API that do the same three things. Point an MCP client at https://api.carlyemail.com/mcp and the whole inbox becomes live tools instead.
Six builds and how each one ships
1. Outbound and follow-up
The agent emails prospects, watches for replies, keeps threads warm, and hands off to a human when someone is genuinely interested.
The whole build rests on replies landing back in the conversation they belong to. They do: every message arrives attached to its thread, and a signed webhook fires the moment one lands, carrying a thread_id your runtime uses to resume the right agent conversation rather than starting a new one. Send from hello@yourcompany.com on your own domain, with SPF, DKIM and DMARC configured for you on dedicated sending infrastructure.
2. Support and intake
Mail lands at support@ or orders@, the agent reads it, pulls the record, and answers or escalates.
Email is the easy half of this one. Answering usually means reaching a helpdesk, an order database, and a CRM, then writing back. Two ways to close that gap: give the agent tools of your own through your runtime, or connect Carly alongside it, which arrives already holding your mail, calendars, CRM and the thousands of apps it connects to, so the agent updates the record and replies rather than only parsing the message.
3. Recruiting
Candidate replies, scheduling back-and-forth, confirmations, all from a recruiting address.
This is scheduling wearing an email costume. Almost every message in the thread is about finding a time, so calendar reach decides whether it works. An inbox on its own leaves you writing calendar logic; pairing the address with Carly puts Google Calendar and Outlook behind the same agent, on both sides of the fence.
4. Document intake
Invoices, receipts and signed PDFs arrive as attachments and need to end up in a system of record.
Attachments move in both directions, up to 25 MB, so the agent can accept the vendor PDF and send the processed version back in the same thread. The open question is where the extracted data lands. If the answer is QuickBooks or Xero, that is an integration you either write once or inherit by putting Carly behind the agent.
5. Signup and verification
The agent receives confirmation links and one-time codes to finish a flow on its own.
A different shape from the others: inboxes created and discarded constantly, with no conversation to maintain. Create them from code, read the code out of the message, move on. The free tier covers three inboxes, which is enough to build the flow before you decide what it costs to run.
6. Per-customer inboxes
Your platform provisions an address per tenant, so every customer’s agent has its own identity.
This is the one people assume is hard. It is a pod: a scope that holds a set of inboxes, with API keys issued against a single pod or a single inbox rather than your whole organization. One tenant’s key cannot read another tenant’s mail, which is the property you actually need before you can sell this. Provision the inbox at signup, hand the tenant’s agent a key scoped to their pod, and point their own domain at it.
The parts you would otherwise have spent the sprint on
Worth knowing what is being handled on your behalf, because these are the four things that eat the first month of any agent-email build.
Threading. Transactional email platforms treat inbound as an event: a webhook fires, you get a payload, the payload is gone. Reconstructing the conversation means storing every message and matching Message-ID, In-Reply-To and References headers, then falling back to subject-and-participant heuristics when a client mangles them, which Outlook does routinely. Threads arrive as objects here, mangled headers included.
Reply matching. People reply from a phone alias, forward to colleagues, change the subject mid-thread, and top-post over four hundred lines of quoted history. Your agent needs the new content, not the transcript. Getting that wrong costs twice: tokens burned on quoted history, and a model re-answering a question settled three replies ago.
Loops. An agent that replies to everything will eventually reply to an auto-responder that replies to everything. Auto-Submitted and Precedence: bulk get honored, bounces and vacation notices get dropped before they reach your model, and a runaway exchange stops itself.
Deliverability. A fresh domain needs more than three DNS records. Reputation is tracked per organization, and addresses that bounce or complain are suppressed automatically, so one bad import does not quietly poison everything you send afterwards.
What it costs
CarlyEmail is free for 3 inboxes and 1,000 emails a month, with no card. Paid plans start at $20/month and run to $200/month, and they raise the volume rather than the feature set: every tier gets the whole API, pods and custom domains included.
That matters more than it sounds when you are choosing. Per-tenant isolation and your own sending domain are usually the features a platform holds back for an enterprise conversation, and they are the two you need earliest if you are building this into a product.
If you are weighing the options, how the agent inbox APIs compare puts them side by side. For the difference between an inbox primitive and a finished assistant that already does the work, see what an “AI agent email address” actually means.
If you want to drive this from your own product at volume, provisioning per tenant on customer domains, book a call and we will scope it to your setup.
FAQ
What is an email API for AI agents?
An API that gives an autonomous agent its own mailbox: inboxes created from code, mail sent and received with threading intact, and inbound delivered to your runtime over webhooks or a WebSocket. It differs from a transactional email API, which sends mail well but treats inbound as a stateless event rather than a conversation with history.
Can I just use the Gmail API for my agent?
You can, and it works when the agent acts inside one person’s mailbox. It struggles as agent infrastructure: OAuth verification cycles are not designed for autonomous systems, per-seat Workspace fees add up once every agent needs an account, and automated sending carries abuse-detection risk. Provisioning an identity per agent or per tenant is where it stops fitting.
Do I need threading, or can I treat each email separately?
You need it for anything conversational. Without threading an agent cannot tell a new inquiry from the fifth reply in an open thread, so it re-answers settled questions and loses context from two messages ago. Stateless handling is fine only for one-shot intake such as verification codes.
How do I stop an AI agent from getting stuck in an email loop?
Honor the Auto-Submitted and Precedence: bulk headers, filter bounces and out-of-office replies before they reach the model, and cap messages per thread. CarlyEmail applies those guardrails for you; on a raw transport API you write them yourself.
How do I give each customer their own agent inbox?
Create a pod per tenant, provision inboxes inside it, and issue each tenant’s agent an API key scoped to that pod or to a single inbox. A key cannot reach mail outside its scope, which is what makes per-customer inboxes safe to sell.
Can I use an agent inbox from Claude or ChatGPT rather than code?
Yes. Point any MCP client at https://api.carlyemail.com/mcp and the inbox becomes a set of live tools, so the assistant you already use can read a thread and reply inside it without you writing a runtime at all.
Ready to automate your busywork?
Carly schedules, researches, and briefs you—so you can focus on what matters.
See what people say
"Before Carly, I relied on a Calendly link, but the whole process felt impersonal and not very professional. Carly changed that by handling all the back-and-forth, so I'm no longer stuck in endless email threads trying to line up schedules.
Now Carly reaches out to candidates, shares my real-time availability, lets them pick a slot, then sends a Zoom link and drops it straight into my calendar. She sends reminders to both of us before each call, which has significantly reduced no-shows and last-minute confusion.
On top of scheduling, Carly acts like a full executive assistant, sending me my schedule the night before so I can prepare for each call. It reminds me of the old x.ai assistant, but Carly is noticeably smarter, faster, and better suited to my healthcare recruitment business."
