Email operations for AI agents
Email marketing your coding agents can run
SendOps gives coding agents something conventional email platforms do not: a reviewable email program in plain text and native tools for live operations. Agents can draft SendQL audiences, SendFlow journeys, and email templates in Git, then use scoped MCP tools to inspect data, prepare broadcasts, and read results. Humans keep the merge, confirmation, consent, and approval controls.
Updated September 1, 2026
The Problem
Click-ops can't be delegated
Your agent ships product code every day — migrations, refactors, whole features, reviewed and merged like anything else. Then the work touches email, and the delegation dead-ends at "log in and click around."
Your codebase
The agent reads the current state as files, proposes a diff, runs it through CI, and a human reviews exactly what will change before it merges. That loop is why you trust it with production code.
Your email platform
Most email platforms still reduce campaigns to state inside a dashboard. There is no definition to read, no diff to propose, and no tool an agent can call — so the only route left is driving a browser, and nobody code-reviews a screenshot.
The result: the one growth channel with the best-understood mechanics is the one your agent can't help with. Not because the work is hard — because there is no artifact to review and no tool to call.
Two ways to work
Git for the program. MCP for the live operation.
Coding agents are strongest when the work has a readable form and the system exposes clear tools. SendOps provides both, without turning your dashboard or AWS account into something an agent has to click through.
Author in Git
Segments are SendQL predicates, workflows are SendFlow files, and templates can be React Email components. An agent edits an ordinary branch, SendOps validates the definitions and renders previews, and a human reviews and merges the pull request before the default branch deploys.
Operate through MCP
An authorized agent can inspect sending health, preview an audience, maintain contacts and lists, author email assets, prepare a broadcast, read results, and review DMARC posture through native tools. OAuth permissions determine which tools it can see and use.
How SendOps connects →The Insight
Everything is text
Campaign definitions on SendOps have a plain-text representation that can live in your repo. If it can be a file, an agent can author it — and a human can review it.
attr.plan in ["pro", "team"] and count(open within 60d) = 0 and last(order) < now - 90dA segment is one SendQL query over attributes, raw events, consent, and list membership. This one: paying customers who haven't opened anything in 60 days and haven't ordered in 90. Readable in a diff, checkable by a compiler.
workflow "Cart abandonment" v1 {
enter on event cart_updated where not exists(order within 1h)
exit "purchased" when exists(order)
wait 1 hour
hold out 10%
send "cart-reminder" via topic marketing
repeat up to 2 every 24 hours until exists(order) {
send "cart-nudge" via topic marketing
}
}A drip campaign is a .flow file — entry triggers, waits, branches, holdout groups, and bounded repeats, with SendQL as the condition language throughout. The same file renders as a visual canvas in the dashboard, losslessly, in both directions.
import { Html, Body, Heading, Text, Button } from "@react-email/components"
type Props = { name: string; cartUrl: string }
export default function CartReminder({ name, cartUrl }: Props) {
return (
<Html>
<Body>
<Heading>Still thinking it over?</Heading>
<Text>Hi {name}, your cart is saved and waiting.</Text>
<Button href={cartUrl}>Finish checking out</Button>
</Body>
</Html>
)
}A template is a React Email component — the format your agent already writes fluently. SendOps compiles it to SES-native Handlebars on deploy, so what runs in production is exactly what SES expects.
SendQL and SendFlow are small, human-readable domain-specific languages with published grammars — that structure is what makes them easy for an agent to author and for a reviewer to check. Campaign definitions can live in Git. Contacts, list membership, consent, activity, suppression, and delivery data remain operational data in SendOps, where an authorized agent reaches them through the native MCP server or the Public API.
How a definition reaches production
The same review loop your agent already runs for product code, applied to campaign definitions.
- 1
Prompt your agent
"Win back paying customers who've gone quiet — a three-email sequence over two weeks, with a 10% holdout so we can measure it." Plain English, in the terminal you already live in.
- 2
The agent drafts a branch
A SendQL segment, a .flow workflow, and the React Email templates it references — ordinary files on an ordinary branch, alongside the rest of your code.
- 3
SendOps validates on push
Syntax for every file, SendQL analysis against your real attribute and event registries, template reference checks, and rendered previews — so a hallucinated field or a broken merge tag dies in CI, not in an inbox.
- 4
You review the PR like any code
The proposed campaign is one readable diff: who it targets, what it says, when it sends, when it stops. Ten minutes of review instead of an afternoon of dashboard archaeology.
- 5
Merge, and SendOps deploys
A proposal only becomes live on merge. Sends then go out through your own Amazon SES — your domains, your reputation, $0.10 per 1,000 — with consent checks and frequency caps applied to every single send.
Not every agent action needs this loop. Reversible MCP operations — looking up a contact, maintaining list membership, recording activity, saving a draft — can happen in one step once permission is granted. The pull request is for definitions that deploy; the confirmation gates are for work that reaches an inbox.
From request to reviewed work
Ask for the outcome. Review the artifact and the impact.
Target customers
Describe the audience in plain language. An agent can draft the SendQL predicate, validate it against your attributes and activities, and preview the current count before you save it.
Audience and SendQL →Create and maintain lists
An authorized agent can create list definitions, maintain contact membership, and explain the difference between a fixed List and a dynamic SendQL Segment. Consent and suppression still determine who may be mailed.
Lists and segments →Build lifecycle campaigns
Ask for an onboarding, renewal, or win-back journey. The agent can author a SendFlow workflow with triggers, waits, branches, exits, and frequency controls, then estimate enrollment before activation.
Drip workflows →Author email templates
An agent can write or update React Email and template content, render it with test data, and send a test. In a connected Git repository, the production change becomes a pull request for human review.
Email templates →Prepare broadcasts
An agent can compose a draft, choose an audience and template, preview the result, and send a test. Before the real broadcast sends, SendOps shows the audience and requires explicit confirmation.
Broadcasts →Investigate and improve
Ask why a message failed, how deliverability changed, which contacts are suppressed, or what is sending as your domain. The agent can inspect live SendOps evidence and return an answer tied to the underlying data.
DMARC monitoring →Guardrails in the platform
The agent can prepare consequential work. It cannot hide the consequence.
SendOps enforces the boundary independently of the agent. A broadcast cannot send on the first MCP call; the confirmation step shows who it will reach. A workflow cannot activate without showing enrollment impact, and workflows activated through MCP keep send approval enabled. Git-backed template changes become pull requests. Consent, suppression, and frequency controls are checked when email is sent, regardless of who authored it.
An agent cannot merge a pull request, publish DNS records, advance a DMARC policy, disable send approval, or carry out a privacy-request deletion. Those steps stay with a person, whichever surface the work was drafted on.
FAQ
Agents and email, answered
Can coding agents really build email campaigns in SendOps? +
Yes. A coding agent can author SendQL segments, SendFlow workflows, and email templates as text, then submit the changes through the same Git review process as application code. With an authorized MCP connection, it can also work with live contacts and lists, prepare broadcasts, inspect reports, and perform other permitted operations. The artifacts, previews, audience counts, and confirmation steps remain visible to your team.
What is the difference between Git, MCP, and the Public API? +
Git is the reviewable source of truth for supported campaign definitions. MCP exposes SendOps as native tools an authorized AI client can understand and use. The Public API is the HTTPS and JSON surface for applications and backend integrations. A team may use all three: Git for reviewed definitions, MCP for agent operation, and the API for product integration.
Can an agent email my entire audience without asking? +
Not through the SendOps MCP server. Sending a broadcast requires an explicit second-step confirmation after SendOps shows the audience. Activating a workflow also requires confirmation after the enrollment impact is shown, and workflows activated through MCP retain send approval. Consent, suppression, and frequency controls still apply when messages are sent.
Does an agent change production templates directly? +
Not when the organization is connected to Git. The agent's template change opens a pull request. A human reviews and merges it, and SendOps deploys the merged default branch. The agent cannot merge the pull request itself through SendOps.
Do contacts and list membership live in Git? +
No. Git can hold supported definitions such as a List's schema or a Segment's SendQL rule. Contacts, List membership, consent, activity, suppression, and delivery data remain operational data in SendOps. Authorized agents work with that data through MCP or the Public API.
Get Started
Give your agent an email program
The free plan is $0 with unmetered volume and no contact limits — you pay only SES's $0.10 per 1,000, in your own AWS account. Connect SES, connect a repository if you want reviewed definitions, and authorize your agent through the native MCP server for live work.