Email for a fleet of AI agents that each need an inbox
Hundreds of agents, each with its own address, isolated from each other. What breaks at that scale, what it costs, and the three things to get right before you create the first hundred.
The problem
One agent with one inbox is easy. The interesting failures start at a hundred.
At that point the questions are not about sending email. They are: can agent 47 read agent 48's mail, what happens to the other 199 when one of them starts bouncing, which key did that send come from, and what does this cost when it works.
Isolation first, because it cannot be retrofitted
The unit of isolation is a workspace. Inboxes live in one, and a workspace-scoped key (wk_) reaches that workspace and nothing else: it cannot list, read, search or send from any other, and it cannot see that the others exist.
You get one workspace per inbox on your plan: 2 on Starter, 10 on Developer, 200 on Startup, and an extra inbox add-on ($2/month) raises both. So the ceiling is never the thing that decides your shape; the inboxes you are already paying for are.
Decide that shape before you create the first hundred, because moving inboxes later is work:
- One workspace per customer, if you are a SaaS giving each tenant agents. Blast radius of a leaked key is one customer.
- One workspace per agent, if agents are mutually untrusted or run third-party code. Costs you a workspace slot per agent, which you have, since slots track inboxes.
- One workspace, many inboxes, if the whole fleet is yours and internal. Simplest, and fine when that is true.
The thing not to do is one tenant-master key shared by everything. It reaches the entire account, and at fleet scale it will end up in a config file on a machine you have forgotten about.
create_workspace and issue_workspace_key do this over the API, so provisioning a customer and their agents is one flow.
What actually breaks at scale
One bad inbox taking the rest with it. Bounce and complaint limits are enforced per inbox, so a single agent with a bad recipient list is paused on its own. The absolute limit is measured over a rolling 7-day window, so an inbox that saw a handful of failures months ago is not permanently dead. There is a tenant-level backstop above it: enough unhealthy inboxes and the account pauses, which is deliberate, because an account spraying a bad list across fresh inboxes is the pattern that gets a sending domain killed.
A runaway loop. Two agents answering each other is unbounded and no alert stops it, so mailing the same address more than 10 times an hour from one account is refused outright. If you hit that, something is replying to its own output.
The ramp. A new account is capped at 20 sends in its first 24 hours, 50 a day for the first week, 500 a day to 30 days, then 10% of your monthly plan per day. You cannot stand up 200 agents on a fresh account and have them all send on day one. Start the account before you need it.
Not knowing which key did it. Every inbox and every connector has its own key, listed in the dashboard and revocable individually. Revoking one agent does not disturb the other 199.
Cost at fleet scale
Startup is $199/month for 200 inboxes, 200 domains and 150,000 emails. Growth past that is $2/month per extra inbox or domain, and $2 per extra 1,000 emails a month.
Worth doing the arithmetic against per-connected-account pricing elsewhere: a competitor charging around $2 per account per month reaches roughly $400/month at 200 mailboxes, against $199 here, and the gap widens as you grow. See Anjal vs Nylas for that comparison with their published numbers.
Every agent gets the same surface
Each inbox in the fleet has an address on your domain, threads with correct headers in both directions, IMAP and SMTP so a human can open it, a calendar, webhooks, and MCP access if you want the agent driven by Claude, Cursor or Codex rather than your own code.
That last point matters more at scale than it sounds: when something goes wrong with agent 47, being able to open agent 47's mailbox in Apple Mail and read what it actually sent is the fastest debugging tool you have.
The safety floor
Inbound mail is attacker-controlled text, and at fleet scale you are not reading any of it yourself. Anjal screens every inbound message on the ingest path and quarantines what it judges hostile before an agent can read it; an agent cannot release its own quarantine. That is a floor, not a boundary. The rule that holds is to gate side-effects on the sender in code, and to keep each agent's key scoped so that a compromised one reaches one workspace. Agent safety sets out the honest limits.
Fit
Good fit if you need tens to hundreds of addresses, created and destroyed by API, that must not see each other's mail.
Not a fit if you need one shared address with heavy rules; that is a routing problem, not a fleet. And not a fit if each agent must work inside a person's existing Gmail, which is a different product entirely.
Related
Other use cases
- For cold outreachBuild your own cold outreach system on AnjalCold email + LinkedIn outreach infrastructure for indie hackers and small teams. Provisioned inboxes, real LinkedIn sessions, intent signals, server-side cadence engine. Drop-in alternative to Lemlist, Apollo, Instantly — with full data ownership.
- For scheduling agentsCalendar + scheduling API for AI agentsGive your AI agent its own calendar: host events, send and RSVP to invites, check availability, and share a booking link — so a conversation can go all the way to a booked meeting without a human or an external calendar provider.
- For recruiting agentsEmail + LinkedIn API for AI recruiting agentsSource candidates from LinkedIn, message them with personalized outreach, follow up over email when a connection accepts. Reply detection, multi-account quotas, and intent signals built in.
- For sales agentsEmail + LinkedIn API for AI sales agentsBuild AI sales agents that actually work leads end-to-end — connect on LinkedIn, send personalized email, detect replies, branch the cadence, and follow up at the right moment. One API key, two channels, multi-tenant ready.
- For accounting agentsEmail API for AI accounting and finance agentsInvoices, receipts and payment requests arrive as email with attachments. Give the agent its own inbox that keeps the thread, pulls the PDF, and never lets it pay anyone on its own say-so.
- For support agentsEmail API for AI customer support agentsBuild AI customer support agents that read inbound email, draft thoughtful replies, and learn from human edits before sending. Real inbox per agent, full thread state, drafts API for human-in-the-loop.
- For ecommerce agentsEmail API for AI ecommerce agentsOrder confirmations go out, 'where is my order' comes back, and both belong on the same thread. One inbox that sends the transactional mail and reads the replies to it.
- For triage agentsEmail API for AI triage and routing agentsAn agent that reads a shared inbox, works out what each thread is, and sends it somewhere. The four things it needs that a webhook payload does not give you.
- For SaaS buildersMulti-tenant email API for SaaS buildersBuild SaaS products that give each customer their own provisioned inbox on their own domain. Workspace-isolated keys, per-tenant rate limits, scoped billing. Multi-tenancy is first-class, not an afterthought.
- For transactional emailTransactional email API for AI-powered appsSend password resets, receipts, and notifications from AI-built apps. Provisioned inbox, custom domain, ZeptoMail-backed deliverability, and per-send open + click tracking with optional opt-out for privacy-sensitive sends.
Last reviewed 2026-09-28.