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.
AgentMail gives your agents real inboxes. Create inboxes via API. Send and receive Emails with 0 complexity. Free to start.
