Guides
Things you can do once an agent can send mail.
Short, practical writeups about the workflows that open up when sending is a tool your agent can call rather than a service you integrate. Mostly the ones we use ourselves.
-
Agents, MCP
Let the agent send the report
You start a long job in Codex or Claude and walk away. The result ends up in a terminal nobody is watching. One MCP server and a scoped key later, it ends up in your inbox instead.
Read it
-
Agents, outreach
Your spreadsheet is already the CRM
The list lives in a file you own. An agent reads it, writes a real message for each row rather than a mail merge, sends, and writes back what happened. No per-contact bill.
Read it
-
Agents, marketing
A campaign, without the campaign tool
HTML email is horrible to write, well documented, and barely changes, which is exactly what a model is good at. Template on our side, broadcast, done.
Read it
-
Architecture
Sending from an address with no inbox
Most of what your company sends comes from addresses nobody reads. Verify the domain and every address on it can send, with no seat licence and nothing for an agent to read.
Read it
Why these are grouped together
Email APIs have been a solved problem for about a decade. What changed is not the sending, it is who is doing it. A model that can call tools can now do the part that used to need a person: decide what to say, to whom, and when.
That turns out to remove more than it adds. You stop needing a mailbox for things that only send. You stop needing a marketing platform to hold a list you already keep in a file. You stop writing the small integration that exists only to format a message and hand it to a service.
The pieces that make it work are ordinary. A verified domain, a key scoped to sending, and an MCP server in the region your data belongs in. Nothing here needs a framework.
If you are weighing us against the alternatives first, that is on its own page, including the parts where we come off worse.