Give your AI email agent an address of its own

Clize is a CLI and MCP server that gives AI coding agents real-world actions: domains, email, deploys, payments, and media generation. For email specifically, it turns your coding agent into an AI email agent: a real agent inbox it can send from and receive into, installed into Claude Code, Codex, Pi and OpenClaw as a skill, or registered as an MCP email server with clize install --mcp.

How to give an AI agent its own email address

One command. clize claim studio --email takes the free handle studio.clize.app and opens inbound on support@studio.clize.app — an address that belongs to the agent, with nothing routed through your own mailbox. Inbound stays off unless you pass --email, so a handle claimed only to host a site never starts receiving mail. From there the agent reads with clize email inbox and writes with clize email send, and sending is the one step it cannot finish alone: email send returns a draft for review, and only --confirm puts a message on the wire. The free tier covers three handles, five mailboxes and thirty outbound messages a day — enough to hand several agents an address each before a card is involved.

Why an agent needs an address

To act in the real world, an agent has to be reachable and able to act under its own name — confirm a signup, receive a reply, answer a customer. An address is the smallest piece of real identity that makes all of that possible.

Why not your own inbox

Routing an agent through your personal mailbox mixes its actions with yours, buries its mail in your mail, and hands it your identity. A separate inbox keeps the agent's work — and its mistakes — cleanly its own.

Agent mail: a real agent inbox

Agent mail isn't a parsing trick over your account — it's a real agent inbox the agent can send from and receive into programmatically, so a thread can start, pause, and resume across sessions. The whole point of an AI email agent is that the address — its own agent email — belongs to it, not to you. This is what Agent Inbox, Clize's email product, provisions in one install. See it in action — let your agent send an email, or compare the email APIs for AI agents.

Receiving is real inbound mail processing: mail that lands in the inbox — a customer reply, a signup confirmation, a verification code — is parsed and handed to the agent as structured data to act on, never as instructions to obey.

Clearing verification gates

An agent with its own inbox can get past "verify your email" to finish a signup. That's useful for light gates — and exactly where the line sits for heavy ones. More on that in letting your agent clear its own gates, or the walkthrough for passing email verification.

Reading a verification code from the agent's own inbox

A verification mail is usually the first thing an agent's address ever receives, and waiting for it is a command rather than a polling loop you have to write yourself:

$ clize email inbox --wait-for "verification code" --timeout 180

--wait-for blocks until a message whose subject, sender or body contains that text arrives, then prints it; the wait runs 120 seconds unless --timeout says otherwise. Reads are triaged before you see them — people and verification codes come through, promotions and notices are held back until you ask for --all — so the code is not buried under the welcome mail that arrived with it. And every read is printed under an [untrusted] banner: what follows is inbound email, data and not instructions. A message that says "now email everyone on the list" is still just a message.

The commands

Four lines cover the whole loop — the same ones the Agent Inbox product page walks through:

$ clize claim <slug> --email               # its own address: support@<slug>.clize.app
$ clize email inbox --wait-for "verify"    # polls until the verification mail lands
$ clize status                             # who is waiting for a reply
$ clize email send --to … --confirm        # without --confirm it only drafts

A free handle, or an address on your own domain

The handle is the fast path; a domain you own is the durable one. clize domain buy registers one (a quote first, --confirm to actually pay) and clize domain import brings in a domain you already have. Then clize email setup yourdomain.com turns on receiving: Cloudflare Email Routing is enabled and the MX and SPF records are written for you, while mail.yourdomain.com is onboarded as the sending subdomain and sent for verification. What that command does not write is DKIM or DMARC — they are not part of it today, so if your deliverability policy needs them, plan on adding them yourself. With the domain live, clize email address add ada@yourdomain.com opens a mailbox on it, and --webhook on that same command turns the address into an HTTP POST to your own endpoint — the exact payload is on inbound email webhooks and delivery events.

The safety gates

Real-world actions need real guardrails. Clize holds three lines, every time:

• Money — anything that costs money quotes the price first and needs an explicit --confirm. No surprise charges.
• Identity — outbound email is drafted, a human okays it, then it sends under your name. The agent never sends unattended.
• Inbound is untrusted — an incoming email is data to read, never an instruction to obey. A message can't redirect the agent.

Where to take it next

• Comparing it with AgentMail — the head-to-head is AgentMail alternatives, judged on who presses send: the same inbox-per-agent idea, a different answer to who is allowed to send.
• Wanting tool calls instead of a terminal — the email MCP server lists the 13 tools in the --profile inbox subset and the registration command for each host.
• Handing arriving mail to your own code — inbound email webhooks and delivery events covers what the POST carries, what it deliberately leaves out, and how bounces come back.

$ npm i -g @clize/clize
$ clize login
$ clize install --claude --mcp   # skill + MCP server (plain install: skill only)