Email addresses as agent identity: giving every AI agent its own inbox

Every multi-agent system eventually hits the same awkward question: who is this agent, and how do you prove it?

We ended up answering it with email. Not because email is elegant, but because it is the one identity primitive that every service on earth already accepts.

The problem with a shared inbox

The first version was simple: one mailbox, one API key, agents identified by a header. It broke in three predictable ways.

1. Attribution. When three agents send from the same address, the recipient cannot tell them apart, and neither can your logs.
2. Blast radius. One leaked key exposed every agent's mail. Rotating it meant redeploying everything.
3. Rate limits and reputation. A noisy agent drags the whole mailbox's deliverability down with it.

Per-agent disposable addresses

The rule we settled on: one address per agent, minted on demand, revocable independently.

• Addresses are generated, not registered. [email protected] exists the moment an agent is provisioned.
• Each address carries its own credential. Revoking one agent does not touch the others.
• Inbound and outbound are the same namespace, so an agent can receive a verification code at the address it signs up with.
• Addresses are disposable by default. An agent that finishes its task can be buried and its address retired.

Why this matters for OTP flows

This is the part that actually bit us. Agents increasingly need to sign up for services, which means receiving one-time codes. A shared inbox forces you to poll a single message stream and guess which code belongs to which agent. With per-agent addresses, the routing is structural: the code arrives at the address that requested it. No guessing, no correlation table.

The subtle trap is timing. Codes expire. If your agent polls a mailbox that has 40 unread messages from other agents, it will happily grab a stale code. Our rule now: the address is created before the signup request, and we only accept messages that arrived after that timestamp.

What email gives you for free

• Delivery semantics other channels lack. It works when the agent has no phone number, no OAuth consent, no app install.
• A paper trail. Every message is an immutable record you can audit later, which matters when a human asks "why did this agent do that?"
• Federation. No one has to integrate with you. Your address is just an address.

What it costs you

• Deliverability is a real job. SPF, DKIM, DMARC, and a warm-up plan are not optional.
• Spam is inbound too. An address that is public will be scraped. Per-agent addresses actually help here: burn it, mint a new one.
• Email is not a queue. Treating SMTP as your message bus produces duplicates and reordering surprises. We keep an internal queue and use email only at the edge.

The design rule we would keep

Identity should be a string you can hand to a stranger, that costs nothing to create and nothing to destroy.

An email address satisfies that. A UUID in a header does not — it means nothing to the verifier. If you are building agents that touch the outside world, mint them addresses, not IDs.

We run a service that does exactly this — disposable inboxes for AI agents — but the design above is what we would build again regardless of vendor.