Email for AI agents
Email API for AI Agents: How AutoEmail Works
AutoEmail gives an AI agent a real, two-way email inbox it can operate over a documented REST API - read mail, search threads, draft and send replies, run outreach, manage contacts. The difference from a send-only email API: a human-in-the-loop mode that holds every agent send for your one-tap approval.
The problem
Most "email APIs" were built to blast transactional mail - receipts, password resets, notifications - one direction, fire and forget. An AI agent needs the opposite shape: a place to live. It has to receive mail, read the full thread, understand who is talking, draft a reply in context, and decide what to do next. Bolting that onto a send-only API means you rebuild inbound parsing, threading, storage, search, and state yourself before the agent can do anything useful.
And the moment an agent can send email autonomously, you inherit a new risk: it will confidently send the wrong thing. A wrong price, a wrong commitment, the wrong recipient - in a warm, professional tone, to a real customer, with no undo. The two missing pieces in the agent-email stack are the same two AutoEmail is built around: a genuine inbox the agent can reason over, and a human checkpoint on the actions that actually matter.
How AutoEmail solves it
A real two-way inbox, not a send pipe
An agent holding one API key can list and read emails, full-text search, walk conversation threads, read attachments, and manage contacts and calendar - the same state a person sees in the dashboard, exposed as clean JSON. The agent operates a mailbox, it does not just push messages.
Human-in-the-loop is a key mode, not an add-on
Every API key carries a mode. A human_in_the_loop key can never send: every reply, compose, and outreach recipient becomes a pending draft in the approval queue for a person to send. A full_autonomous key sends directly. You choose the trust level per key.
Draft now, approve later, same queue as humans
When an agent drafts, it lands in the exact dashboard queue a human already uses to approve AI replies. There is no separate agent surface to babysit - agent and human work the same inbox, and the human stays the final decision-maker on anything risky.
Built for safe autonomy
Per-key account allowlists, server-re-verified ownership on every call, fail-fast quota metering with refunds, idempotency keys, per-route rate limits, and outreach deliverability guards (dedupe window, daily cap, drip throttling, pre-send reply check) are all enforced server-side, so an agent cannot foot-gun your reputation.
Concretely, an agent starts every session with GET /me to learn its mode and which accounts it may touch, then reads with GET /emails and GET /search, and acts with POST /emails/{id}/reply or POST /emails/send. In generate mode it hands AutoEmail a brief and lets the platform write the copy using your knowledge base, global prompt, and learned lessons; in final mode it supplies its own subject and body. With a human-in-the-loop key the same calls produce drafts instead of sends - the agent's code does not change, only the key's mode does. The full surface is in the OpenAPI 3.1 spec at /openapi.json and the live, try-it reference at /docs.
This is the architecture behind the phrase "email for AI agents": not a faster way to blast mail, but an inbox an agent can genuinely live in, wrapped in the human approval model that makes autonomous email safe to ship. It is the same product a solo operator uses to approve AI replies - the API simply lets an agent be the one drafting. To go deeper, the cornerstone how-to walks through giving an agent an inbox step by step, and the concept pages below define the category.