Pods: multi-tenant email infrastructure as a primitive

Multi-tenancy is the property of infrastructure where many customers share the same underlying system but each one's data, credentials, and resources are isolated from every other. Your customers do not know about each other. Their data does not mix.

Most modern infrastructure has a multi-tenancy primitive. Kubernetes has namespaces, paired with RBAC and network policies. Object stores have buckets with per-tenant IAM. Auth providers have organizations. Email did not have one. Until recently, if you wanted per-customer email isolation in your product, you built it yourself with customer_id columns, scoped credentials in your auth layer, and a lot of careful authorization checks.

A Pod is AgentMail's multi-tenancy primitive for email. One Pod is one tenant: a group of inboxes, one or more sending domains, and API keys scoped to that boundary. AgentMail is email infrastructure built for AI agents, and Pods are how it handles multi-tenancy. You create a Pod with one API call, and the platform refuses to serve API access across the boundary.

The rest of this post is about why email got here last, and what the primitive looks like in production.

The pattern

Every infrastructure layer eventually grows up for multi-tenancy. Compute did it, storage did it, identity did it. Email is next.

The shape is always the same. Compute moved from bare metal to containers, and the question who owns this CPU moved out of application code and into the platform. Storage moved from disks to object stores with per-tenant IAM, and who owns this byte moved with it. Identity moved from users to tenant-aware orgs, and who is this person allowed to act on behalf of moved too.

Each time, the same thing happens: you stop checking tenancy in your handlers. The platform refuses to serve cross-tenant data. A tenant boundary stops being a column on a table and becomes a first-class object the API knows about.

Why email lagged

SMTP was specified in 1982 for a single-organization, host-centric world. Reputation lives at the domain level, and there was no clean place in the protocol to bolt tenancy on.

So for decades, builders rolled it themselves. A customer_id column on every email table, authorization checks in every handler, suppression lists partitioned in application code, per-customer DNS scripts, reputation tracked in spreadsheets.

Provider-level workarounds exist. Sending identities, subusers, message streams, SES tenants. They help, but they all isolate sending. None of them treat a customer's set of inboxes as the unit of tenancy. You get outbound separation, not a per-customer mailbox boundary on the receive side.

What a Pod is

A Pod is a dedicated group of inboxes you provision under your organization. Pods isolate multiple subtenants under one org. If you are a B2B company building agents, each of your customers gets their own Pod: their own inboxes, their own sending domains, their own scoped API keys.

The shape of the four calls:

from agentmail import AgentMail

client = AgentMail()

# 1. Create a Pod for the new customer
pod = client.pods.create(client_id="acme-corp")

# 2. Add a sending domain to the Pod
client.pods.domains.create(pod.pod_id, domain="acme.com")

# 3. Provision an inbox inside the Pod
inbox = client.pods.inboxes.create(
    pod.pod_id,
    username="support",
    display_name="Acme Support"
)

# 4. Issue an API key scoped to this Pod only
key = client.pods.api_keys.create(
    pod.pod_id,
    name="acme-service-key"
)

That key cannot read or send from any other Pod. The platform enforces it. Your code does not.

Production use cases

A few shapes this primitive shows up in.

AI recruiter agents. Each hiring company that signs up to the platform gets its own Pod. When an agent sends 5,000 candidate emails in a day and a few bounce hard, only that hiring company's reputation absorbs the hit.

AI sales and outreach agents. SDR platforms shipping agents to their customers face the same problem at higher volume. One customer's deliverability cannot be coupled to another's. A Pod per customer keeps domains, inboxes, and reputation separated so a single noisy account does not drag inbox placement for the rest of the platform.

Customer support and helpdesk agents. Every workspace using the helpdesk product handles its own inbound mail. Tickets, replies, attachments, signatures. None of it can leak across customers. With Pods, cross-tenant reads do not happen at the API level.

Testing agents. Spin up a Pod for a test run, provision inboxes inside it, run the test, tear the Pod down. Each test run is isolated from every other. No suppression-list contamination, no reputation drag, no leftover state.

Agents are the part of the system you cannot fully predict. A jailbreak, a prompt injection, a misparsed reply. Inside a Pod, the blast radius is one customer.

What it costs to wait

Three concrete costs to building this in application code instead of using a primitive.

Shared sending reputation means one customer's complaint rate degrades inbox placement for every other customer sharing that domain. Subdomain isolation helps contain the bleed but does not eliminate it.

A leaked API key without tenant scope is a cross-tenant data exposure. Per-Pod scoping makes the same leak a single-customer incident.

Building it yourself is months of plumbing. Tenant_id columns on every table. Scoped key issuance. Suppression list partitioning. Per-tenant DNS. Reputation accounting. Tenant-aware webhooks. One missed WHERE clause is a leak.

FAQ

What is multi-tenant email infrastructure? Multi-tenant email infrastructure treats each end customer as an isolated tenant with its own inboxes, sending domain, credentials, and reputation, enforced by the platform rather than by application code.

What is a Pod in AgentMail? A Pod is AgentMail's tenant primitive. It bundles inboxes, one or more sending domains, and scoped credentials into a single boundary that the API enforces. AgentMail is email infrastructure for AI agents, and Pods are how it does multi-tenancy.

How do AI agent platforms isolate email per customer? Agent platforms isolate email per customer by provisioning a tenant-scoped workspace at signup time, attaching the customer's domain, and issuing API keys that cannot read or send outside that tenant. AgentMail Pods are this primitive.

Why is multi-tenant email harder than multi-tenant data? SMTP was specified in 1982 for a single-organization, host-centric world. Reputation is anchored at the IP, the domain, and the subdomain. There was no clean place in the protocol to bolt tenancy on, so for decades it stayed in application code.

How do I provision a per-customer email environment programmatically? Four API calls in AgentMail. Create a Pod. Add a domain to it. Create an inbox inside it. Issue an API key scoped to the Pod. Documentation is at docs.agentmail.to/documentation/core-concepts/pods.