An Email Address for Your AI Agent's Signups

Your AI agent can have its own email address for signups by getting its own AgentMail inbox. The agent receives verification mail there and replies from it, and at apps that accept AgentID, our sign-in for AI agents, the same address signs it in without a verification email at all.

Almost every signup on the internet ends with the same step: we sent you an email, click the link. For a person that takes ten seconds. For an agent it is where the job stops, because the email lands somewhere the agent can't reach, or somewhere it shouldn't. The address you give an agent decides who reads its mail, who it appears to be, and how you take the access back later. We'll compare the usual choices, then build the one that works, from creating the address to pulling the link out of the verification email.

Why shouldn't the agent sign up with your personal address?

The agent shouldn't sign up with your personal address because every email the service sends then goes to you, and the account is yours rather than the agent's. You become the relay for every verification code, or you give the agent access to your whole mailbox so it can find them itself. Can an AI agent have its own email address makes the broader case; for signups, the problem is concrete.

A shared address also blurs who did what. The service sees you, so the receipts, the password resets and the support replies all come back to you, and when you want the agent gone you are closing your own account or changing your own password. Run three agents this way and you have three agents' worth of service mail mixed into yours, with nothing to say which agent triggered which email.

Which kind of address should an agent sign up with?

An agent should sign up with an inbox designated for that agent. The two common alternatives each fail on at least one of the things a signup needs.

A catch-all looks cheap, but it is a mailbox nobody owns in particular. Every agent's codes arrive in the same place, so one agent can read another's, and there is no identity attached to any of them. Cutting off one agent means changing the routing that every other agent depends on.

How does the agent create its inbox?

The agent creates its inbox with one API call, and the call is safe to repeat. Pass a clientId and AgentMail treats it as an idempotency key, so running the same setup twice returns the same inbox instead of a second one. The address can sit on the default domain or on a custom domain you verify, and the pricing page lists how many inboxes and domains each plan includes.

Each inbox is a real mailbox with its own stored history and automatic threading, so the agent can come back to a service's earlier emails when it needs them. From the agent's side it is just an address it can hand to any signup form. If you would rather set one up by hand first, agentmail inboxes create --display-name "Research Agent" does the same from the CLI.

How does the agent catch the verification email?

The agent catches the verification email by listening on its inbox, with a webhook or a websocket in production, or by polling in a short script. The Node script below creates the inbox, waits for the signup email to arrive, and pulls the first link out of it. Polling keeps it self-contained; in a long-running agent, subscribe to the message.received event instead.

import { AgentMailClient } from "agentmail";

const client = new AgentMailClient({ apiKey: process.env.AGENTMAIL_API_KEY });
const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));

// 1. Give the agent its own address. clientId makes the call idempotent,
//    so rerunning the script returns the same inbox.
const inbox = await client.inboxes.create({
  username: "research-agent",
  displayName: "Research Agent",
  clientId: "research-agent-inbox-v1",
});
console.log(`Sign up with: ${inbox.email}`);

// 2. Wait for the verification email: a plain list with a label check.
let received = null;
for (let i = 0; i < 100 && received === null; i++) {
  const { messages } = await client.inboxes.messages.list(inbox.inboxId, {});
  received = messages.find((m) => m.labels.includes("received")) ?? null;
  if (received === null) await sleep(3000);
}
if (received === null) throw new Error("No verification email within five minutes.");

// 3. Read the body and pull out the first link.
const message = await client.inboxes.messages.get(inbox.inboxId, received.messageId);
const link = message.text?.match(/https:\/\/\S+/)?.[0];
console.log(`Verification link from ${received.from}: ${link}`);

In a real agent, match on the sender or subject as well, so a newsletter that arrives first isn't mistaken for the verification email. When the service writes back and expects an answer, the agent replies from the same inbox with client.inboxes.messages.reply, and the reply stays in the service's thread. Email threading for AI agents covers how that works.

What does the same address do at apps that accept AgentID?

At apps that accept AgentID, the same address signs the agent in, and there is no verification email to wait for. The inbox address is the agent's AgentID, and the app receives it already verified, checked live when the sign-in token is minted.

That turns the script above into a fallback rather than the main path. Where an app shows a Continue with AgentID button, the agent signs in as itself; where it doesn't, the agent signs up with the address and reads the code. The app gets an identity, not a mailbox: signing in grants no access to the agent's mail. What the app can do is write to the agent, so onboarding, receipts, invoices and support replies arrive where the agent can read and answer them. The steps for the agent's side are in how to give your AI agent its own identity with AgentID, and the AgentID overview on AgentMail explains how it fits with the inbox.