The failure mode you are actually planning for
Agents are good at code and bad at APIs they have not seen. Give one a mail provider it has never been told about and it will invent the method names, retry against a surface that does not exist, and report success while nothing was delivered. The first job of an email API for agents is not capability — it is making the wrong thing impossible.
That rules out the two obvious designs. Handing the agent an inbox password grants every folder, no audit trail, and a provider-side lockout when the agent sends like a machine. And pointing it at a raw HTTP surface makes every signature it misremembers a runtime error instead of a compile error.
1. A contract the agent cannot misremember
The flowmails-sdk skill installs the SDK contract into every coding-agent session: the constructor signature, the five error classes, the retry policy, the payload shapes. One command, and the agent stops inventing sendEmail() and starts calling the real thing.
npx skills add wms-why/flowmails-sdk-plugin@flowmails-sdk
After that the integration is one typed call: fm.send(SendOptions) returns a typed SendResult, and failures branch on instanceof rather than on whatever the response body happened to say. Per-tool setup for Claude Code, Cursor, and Copilot — plus the fallback for every tool that doesn’t speak the skills protocol — is on /docs/ai-agents.
2. A blast radius you can revoke
Keys in Flowmails are bound to one of your domains, not to an account with a shared quota. That single constraint does most of the safety work: an agent cannot send as a customer, cannot reach a mailbox on another domain, and cannot take your sending reputation with it when it goes wrong. Revoke the key in the dashboard and the agent is out — no password rotation, no provider-side cleanup.
Every send lands in your own outbox, so the blast radius of a mistaken call is a row you can read and a key you can revoke. An agent that drafts a reply to a customer and stops there is useful; one that sends to whoever it inferred is a liability. Whether it sends is your agent’s decision — Flowmails does not add an approval step; the domain binding and one-click revocation are the control surface.
3. An inbox the agent can verify, not assume
The failure mode of “just send a test email” is that nobody can prove the mail arrived. Flowmails writes inbound mail to a D1 database inside your own Cloudflare account, so the question “did my verification link arrive?” has an answer an agent can read — a query, not a guess, and not a polling loop against a provider's search endpoint.
That is what ships today. A signed outbound webhook — so the agent is told when mail arrives or leaves instead of asking — ships too: point it at a URL in Settings → Webhooks and the platform POSTs to it, signed, with every attempt in a delivery log. The one half still on the roadmap is the delivery-status half: being told when a message bounced needs the receive worker to report its status transitions.
What is roadmap, stated plainly
Two things people ask for are not shipped yet, and we would rather say so than ship a button that 404s:
- Delivery-status webhook events — roadmap, not shipped: the signed webhook fires when a message arrives and when one is sent, but the delivered / bounced half needs the receive worker to report its status transitions — and it has no bounce ingestion today, so a bounce is not observable at all. Until then an agent polls the send status.
- Event-driven agent workflows — roadmap, not shipped: the platform keeps the event log and the durable wait; the agent’s own code does the matching, extraction and action. Flowmails deliberately has no rule engine — that logic stays in the agent.
Everything above is tracked in the same place as the rest of the roadmap. If you are deciding between Flowmails and building this yourself on Workers, the honest answer today is that the receive and send path is done and the orchestration layer is the part you would be writing.
Who this is actually for
You are running several small projects on several domains, you already drive a coding agent for most of your work, and you want signup tests, verification flows, billing mail, and deploy notifications to run through the same identity instead of a patchwork of aliases. If you send a handful of transactional emails a day and want them on your own domain with your own data residency, the full picture is on /for/ai-coding-agents.
