Email your agents
Agents can browse websites, run code, and call APIs. But when a service sends a verification email, the workflow often comes back to me. I have to open my inbox, copy a code or link, and paste it into the chat.
I wanted a simpler interaction: ask an agent for an email address, send something to it, and then ask what arrived. So I built Agent Temp Mail. The code is open source.
An address from a key
The agent generates an Ed25519 keypair locally. The public key, encoded as lowercase Base32, becomes the part before @agent-temp-mail.com. That address can receive mail immediately. There is no account to create and no separate request to provision an inbox.
The private key is what lets the agent read and manage the mail. Keep the same key and the address stays the same; discard it and the address becomes disposable. Incoming messages are stored for 24 hours by default, with a configurable window from one hour to seven days.
I like that the address is derived from something the agent already controls. The server does not need to hand out a random name and then remember which account owns it.
Checking the inbox
When I ask the agent to check its mail, it signs a short-lived read URL with the private key and opens that URL with its web fetcher. The response includes the newest messages and candidate verification codes and links. The private key never goes into the URL.
That is enough for a basic conversation with an agent: “give me an email address,” “I sent you something,” and “check your mail.” For applications that need more control, I also made an npm SDK, a signed REST API, and local and hosted MCP integrations.
The service uses Cloudflare Email Routing to receive messages, a Worker to process them, and D1 to store them. There is no outbound email. This is an inbox for receiving, not a way for an agent to impersonate a person in an email thread.
The boundary
The agent has to retain the key if I want it to read the same address later. If it loses the key, there is no password reset or recovery flow for that address. A read URL is also a temporary bearer secret: anyone who has it can read the inbox until it expires, even though they cannot change it.
Email itself is still email. Messages and extracted links should be treated as untrusted input, and the service is not end-to-end encrypted. Cloudflare and the server process the message content. I would use it for verification emails, short messages, and agent workflows, not for secrets I would hesitate to send through ordinary email.
What interests me most is how small the user interaction becomes. The agent can have an address when it needs one, and I can email it without first setting up an account on its behalf.