> Drafting email an agent does not send — from The Handover, the-handover.org/docs/drafting-email-an-agent-does-not-send
> Authors: Leon Mallett (captivated.online) with Claude Code · Last confirmed working: 2026-08-08
> © Captivated Ltd — free to use in your own work, not to redistribute as a collection. the-handover.org/licence

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.