Drafting email an agent does not send

For an agent asked to prepare an email or newsletter issue. Two parts: where the agent’s job stops, and the ways email is not the web.

The boundary: draft, validate, hand over

An agent prepares content. A human previews and sends. The agent does not send, does not schedule a send, and does not trigger anything that would deliver to a list.

This is not timidity, and it is not about the quality of the draft. Sending is irreversible, outbound, and audience-facing — three properties that together put it firmly in the category where a human belongs at the decision point. A bad paragraph on a website is edited in a minute; a bad paragraph in twelve thousand inboxes is an apology, an unsubscribe spike, and a permanent record. There is no recall.

The same boundary applies to anything sharing those properties: posting publicly, messaging customers, filing something with an external body, spending money.

What a good handover looks like:

• One file per issue, in a known location, in a documented format.
• Validated before it is handed over, against a schema, so a missing or malformed field fails loudly rather than surfacing at send time.
• Complete — no “the human will fill in the subject line”. An incomplete draft transfers work rather than finishing it.
• Reviewable in the form it will be sent, so the person approving sees what recipients will see, not a source file they have to imagine rendered.

If the pipeline has a preview step, a test send, and an approval before the real send, the agent’s job ends at the first of those.

Email is not the web

Rendering is a decade or two behind, and the failure modes are unlike browser ones because the recipient cannot refresh, cannot debug, and will not tell you.

Images are blocked by default in many clients. Never put essential content only in an image — not the headline, not the call to action, not the offer. Use absolute HTTPS URLs, always with meaningful alt text, because the alt text is what a large share of recipients will actually read.

Web fonts are commonly stripped. Specify font stacks with system fallbacks rather than a single family name, and check that the layout survives the substitution rather than assuming it degrades gracefully.

Do not rely on dark mode. Client support is inconsistent and some clients invert colours in ways nobody designed for. Design for light, and check that a naive inversion does not make anything unreadable.

Keep it tight. Short summaries with real links outperform long copy, and the constraint improves the writing anyway.

Test in the clients your audience actually uses, not the one you use. The gap between “renders correctly in my client” and “renders correctly” is where most email bugs live.

Why this belongs in an agent’s context

An agent that can draft an issue can almost always also send one, because the sending mechanism is right there and usually a single command. The boundary is therefore not enforced by capability — it has to be written down, and it has to be written down somewhere the agent reads before it starts, rather than discovered in review afterwards.