How AgentMail gives every enterprise its own email infrastructure
AgentMail Outposts run the part of AgentMail that touches email inside each enterprise customer's AWS account. AgentMail still ships one release to all of them.
- to deploy an Outpost into a customer's AWS account
- 6 min
- from first design to tested end to end
- 4 weeks
- message content stored in AgentMail's cloud
- Zero
- to hosted AgentMail
- No changes
AgentMail provides email inboxes for AI agents. An inbox gives an agent an identity it can sign up and authenticate with. It can hold real conversations, with threaded replies, attachments, and multi-party threads, and keep a persistent, searchable record it can come back to later.
For most customers, AgentMail runs all of this on its own servers. It's the fastest way to start, with nothing for the customer to operate.
Some companies can't store their mail on a vendor's servers at all, and those companies tend to be the largest customers. Banks, healthcare providers and government suppliers work under policies that keep certain data inside infrastructure they control.
Their agents' email holds customer conversations, contracts, invoices, and login links. What those policies govern is who holds that data, not how well it is encrypted. These are also the biggest contracts on the table.
So AgentMail lets those companies host the email side themselves, with AgentMail Outposts. An Outpost is the piece of AgentMail that touches email (sending, receiving, storing, and searching messages) running inside the customer's own AWS account. Everything else stays with AgentMail: the dashboard, the SDKs, login, billing, events, and updates.
Architecture diagram. Outpost (Messages, Attachments, Search) connects outbound to the AgentMail Cloud (Login, Billing, Console), via no email content.
Alien gives us a Vercel-like deploy flow for infrastructure we don't own. One release, and the domains, certificates, and monitoring come with it.
Their cloud, their email data
The Outpost sends and receives the customer's mail, stores the messages and attachments, and holds the search index. All of it runs inside the customer's own AWS account, so it falls under the access rules, audit logs, retention policies, and data-residency requirements that customer already enforces everywhere else.
An administrator picks a region in the AgentMail dashboard and launches one CloudFormation stack. The stack creates only the resources the Outpost needs, and grants permissions to those resources and nothing else in the account. Setup takes about six minutes.
For the customer's developers, nothing changes: same API, same SDK, same documentation. They point the client at their own Outpost by changing one setting, baseUrl. When someone opens a message in the dashboard, the browser loads that message from the customer's own account.
Managed, not self-hosted
The customer owns the infrastructure and the data. AgentMail still operates the product.
Alien is what makes that possible. It deploys the Outpost into the customer's account and keeps operating it there, so AgentMail can ship to a customer's cloud the same way it ships to its own:
- Updates. AgentMail publishes one release and Alien rolls it out to every Outpost. No upgrade window to schedule, and no customer to coordinate with.
- Domains and certificates. Alien gives every Outpost its own address, then creates and renews its TLS certificate inside the customer's own account. AgentMail never has to issue or renew a certificate.
- Monitoring. Alien reports health and logs for every Outpost in one place, so a problem in a customer's account is visible without asking them to go look. Deployments connect outbound only. Nothing reaches into their network.
- Setup. Alien generates the branded setup portal the customer sees, and the CloudFormation template it launches, from AgentMail's own deployment definition. Neither was written by hand.
Why AgentMail didn't ship all of AgentMail
AgentMail is much more than mail handling. It's accounts and organizations, permissions and API keys, billing and limits, the dashboard, the SDKs, the event pipeline, deliverability and sender reputation. Almost none of that is sensitive, and all of it changes constantly.
Shipping the whole product into every customer's account would mean running a complete copy of AgentMail in each one. Each copy would sit inside an environment nobody at AgentMail can see into, under conditions that get stricter as the customer gets larger.
Every enterprise deal would add another installation to maintain, another upgrade to coordinate, another bug debugged over a screen share with someone else's engineer.
So the question was never how to ship AgentMail into a customer's cloud. It was how little of AgentMail had to go there. The answer: only the part that touches email content.
What keeps the data in
- Requests for sensitive data never touch AgentMail's servers. When someone opens a message or searches an inbox in the dashboard, the browser calls that customer's Outpost directly, cross-origin. The Outpost reports only non-sensitive metadata back to AgentMail (which inbox, when, how large), never the message itself. That is what the end-to-end encrypted badge in the console means.
- AgentMail can update every Outpost, and still cannot read anyone's mail. The storage is created once, during setup, and then locked. Afterward Alien has no permission to read it, change it, or delete it. Only the application code stays updatable. This isn't a promise not to look; the permission to look doesn't exist.
- If the Outpost is unavailable, the request fails rather than falling back. It's never quietly served from AgentMail's own storage instead. A silent fallback would place content in the hosted service, which is precisely what these customers' policies are written to prevent.
It took four weeks to go from first design to a deployment tested end to end: a real browser, a real AWS account, and real email sent and received. The tests confirmed that no message content left the customer's account, and an existing hosted customer was re-tested to prove nothing had changed for them.
We didn't want to compromise on product function nor the security of our customer's data. Alien gave us a way to keep email content exclusively in the customer's account while maintaining one API and one release.
What's next
Outposts run on AWS today. Alien maps the same deployment definition onto Google Cloud and Azure, so reaching customers on another cloud is a configuration change rather than a second integration to build and maintain.