AgentMail

Hosted email-inbox API designed for AI agents to own and operate, not for humans to read in a mail client. Each agent gets a real address (*@agentmail.to or a custom domain), can send and receive messages, manage threads and drafts, and stream incoming mail over WebSockets or webhooks. Marketed under the umbrella site agent.email and the docs at docs.agentmail.to.

What's actually different from sending email through SMTP

Three things separate this from "use SendGrid from your agent":

The inbox is the unit. Agents don't just send — they receive, reply, search threads, label, and draft. The API treats an inbox as a first-class object with REST endpoints for messages, threads, drafts, attachments, and labels.
Push, not poll. Realtime delivery is WebSocket-native (and webhook-optional). Agents don't burn tokens running a poll loop.
Onboarding is inverted. The agent signs itself up first, then mails one specific human asking to be claimed. Until claimed, the inbox can only send to that one address, capped at 10 mails/day. See inverted-claim-onboarding.

How an agent gets started

From the public skill.md:

1. POST sign-up with { human_email, username }
2. Send an introduction email to the human asking them to claim you
3. Human either replies with the OTP they got, or signs up on the console
   → restricted mode lifts

Restricted mode allows exactly one operation — send_message to human_email, max 10/day. Everything else (custom domains, additional inboxes, allowlists, pods, search) returns an error until the human OTP step completes.

API shape

Base: https://api.agentmail.to/v0. The REST surface covers:

Agents — the API-key principal
Inboxes — addresses owned by the agent
Messages / Threads / Drafts — content
Domains — custom domains with SPF/DKIM/DMARC
Webhooks — outbound event subscriptions
Pods — multi-tenant isolation (an agency-style customer hosting many sub-agents)

OpenAPI 3.1 spec and AsyncAPI 2.6.0 spec (for the WebSocket events) are published.

Integration surface

AgentMail leans hard into the llms-txt / skill.md convention — the docs are pitched at the LLM reading them, not the developer. Concrete integrations:

MCP server for Claude Code, Cursor, and any MCP client
CLI as the human escape hatch
Skills for OpenClaw and Claude-style harnesses
Dedicated bindings for Google ADK (adk-go), OpenClaw, Replit, LiveKit Agents, Sim.ai

The payments hooks — x402 (HTTP 402 with crypto settlement) and MPP (Stripe machine-to-machine) — push agent-native commerce: an agent that receives an invoice email can pay it without a human in the loop.

Where it fits

For local agent experiments, email is rarely the bottleneck — you can SMTP relay through your own Postfix and call it done. AgentMail becomes interesting when:

The agent needs to receive email reliably, including replies that thread correctly
The human-in-the-loop reviewer (human-in-the-loop) is going to read drafts before send
You're building a fleet of agents and want per-agent isolation (pods)
You want the agent to handle attachments, forwarding, and label-based workflow without writing a mailbox parser

The closest open analog would be running JMAP (or Stalwart) and writing an agent SDK on top — which is a six-week project before you've handled deliverability.

Limitations to flag

Closed source. API access is the product; there's no self-host story.
Single vendor. Custom domains help but don't make the agent portable — the inbox state, threads, and webhooks live in AgentMail.
Pricing not on the homepage. Plans are gated behind sign-up; custom-domain support is paid-tier only.
No human IMAP. A human can read the inbox via the console UI, but there's no IMAP/JMAP escape if you want to wire it into Thunderbird or Apple Mail.

Why this is on the toolbox and not the watchlist

Watchlist criteria target alpha-stage / single-author / single-platform projects where the question is "will this exist in a year." AgentMail is a funded commercial SaaS — the question is different ("does the lock-in risk outweigh the build-vs-buy savings"), and the answer is project-specific. Tracking it as a known option is enough; no re-check date.