AgentMail at MCP Night 4: email as an identity layer for agents

At MCP Night 4, Adi Singh — co-founder of AgentMail — took the stage for a lightning demo with a simple pitch: your agent needs an email address, and a human shouldn't have to click around to get it one. Five minutes later he'd live-demoed an agent signing itself up for an inbox from a single prompt, and made the broader case for email as the identity layer for agents.

Here's the recap.

The problem: agents can use your product, but can they sign up for it?

AgentMail bills itself as the inbox API for AI agents — the email primitive you'd hand to Claude, Codex, Hermes, or any other agent you're building. Adi has been chewing on this since November 2024, but the idea didn't get real traction until earlier this year when the Lovable-style agent harness pattern took off and developers started asking for it.

With the signups came one piece of feedback that stuck. Someone tweeted that AgentMail required a human to first create an account with their Google or email address just to provision an inbox for their agent — and called it "the biggest epic fail I've ever seen in my life".

It's the kind of criticism that stings because it's right. The industry has spent the last year focused on what agents can do once they're inside a product, and far less on how an agent is supposed to sign up for one in the first place. If your onboarding assumes a human with a browser and a password manager, you've already lost the agent use case.

What changed: signup from a single prompt

Adi spent the weeks leading up to MCP Night fixing exactly that. The new flow: point an agent at the AgentMail site and tell it to get itself an inbox.

The landing page is intentionally minimal. It tells the agent to read a skill.md file and follow the instructions inside. No form, no OAuth dance, no human in the loop.

On stage, Adi ran the demo in Codex rather than Claude, noting that Claude is "super restrictive" about this kind of autonomous browser work. The agent visited the site, read the skill file, and AgentMail provisioned the inbox on the spot.

The obvious next question: what stops abuse?

The first thing anyone asks when you let agents self-provision email addresses is how you keep this from turning into a spam cannon.

AgentMail's answer is a deliberate trade-off. New inboxes get provisioned immediately, but they ship with a strict allow list that limits which addresses the agent can send to and receive from. Each agent inbox is also capped at 10 outbound emails per day.

That's restrictive enough to keep a runaway agent from flooding anyone's inbox, but permissive enough that the legitimate use cases — receipts, confirmations, coordinating with a known human — still work. You can loosen the limits later, but the default is "small blast radius."

Email as an identity layer

The framing Adi kept coming back to is that email functions as a de facto identity layer on the internet. Many actions and transactions land in an inbox — tax records, invoices, receipts, claims, password resets, account confirmations.

Agents don't need a new protocol for any of this. They need access to the primitive that already exists. As Adi put it, AgentMail is happy to let the folks at WorkOS build new standards — its job is to give agents better access to the ones the world already runs on.

That framing matters because it inverts a common assumption. A lot of agent infrastructure right now is designed around "what if we built a new channel just for agents?" Email is the opposite bet: the channel already exists, nearly every online service already speaks it, and the remaining work is just making it accessible to a non-human caller.

What it looks like in practice

Two use cases from the talk make this concrete.

The first is autonomous signup for downstream services. Tell your agent to go sign up for Substack using its AgentMail address, and it can spin up a browser and complete the flow end-to-end — confirmation email included — without a human in the loop. The inbox is what makes the rest of the agent's autonomy actually usable.

The second is pairing AgentMail with an agent card to capture receipts and transactions, or having the agent CC'd on threads so it can act as a personal assistant for scheduling and coordination. The inbox becomes both an audit trail and a context source — the agent sees what you see, in the channel where most business actually happens.

Why this demo stuck

Most of the agent infrastructure conversation right now is about new protocols, new transports, new auth flows. AgentMail's bet is the unsexy one: take the protocol that's been carrying internet mail since the early 1980s and make it usable by a non-human principal.

The signup-by-prompt demo is a small thing on its own, but it's a useful litmus test. If your product can't be onboarded by an agent reading a skill.md file, you're going to lose the agent-native distribution wave the same way sites without mobile views lost the mobile wave. Adi got the message from one annoyed tweet and shipped the fix in a couple of weeks. That's the right speed for this moment.

Catch the rest of the MCP Night 4 demos on the WorkOS blog, and if you're building agents that need their own inbox, AgentMail is worth a look.