# Why agentic email design is the future

2026-08-14

Writing HTML email is famously miserable. Outlook lays out messages with Word's rendering engine. Gmail clips anything past about 102KB, and whatever falls below the cut - your unsubscribe link, usually - only renders for someone who clicks. Dark mode inverts colors you never chose. I've spent thirty-plus years in technology, and email HTML is still one of the strangest targets I know: shipping a button that survives everywhere is a specialist skill, and the rest of us copy an old template and hope.

A capable model changes this, though not in the way you'd guess. A model writing raw email HTML makes a junior developer's mistakes, just faster. What works is constraining it, and the open-source [react.email](https://react.email) is the project that changed the game here: a small component vocabulary that compiles down to the ugly, correct stuff - table-based layout, inline styles, the Outlook conditional markup - so whole classes of breakage can't be written in the first place. Its button ships the Outlook fix whether or not you've ever heard of the Outlook bug.

That changes the game, but it doesn't end it. Take that same button. It ships the Outlook fix, and Proton's Android app still drops the label straight out of it, because the nested markup that keeps Outlook happy is exactly what Proton's sanitizer takes apart. No component library papers over that one, and dark mode is worse: Gmail and Outlook repaint your colors on their own heuristics and give you no way to ask them not to. Yahoo ignores padding on a table and honors it on the cell inside. Two clients silently drop any size you write in rem. None of that is in a spec anywhere; you learn it by shipping mail and watching it break.

So we wrote down what we learned, and it ships with the product. Point your coding agent at the fixture.email MCP and the cross-client playbook comes with it: the table-and-cell rules Yahoo needs, px-only units, plain-link buttons because of that Proton behavior, and the dark-mode strategy that actually converges - declare one mode, ship zero dark-mode CSS, and pick colors that still read after a client inverts them. Every rule in it came off a real device in a real inbox, not somebody's blog post. Your agent reads it and writes email at the floor of someone who's already been burned by all of it. Describe the email, look at the result, adjust. That used to be a specialist's week. Now it's an afternoon.

Testing email has the same split. Deterministic assertions have always been able to check that a message arrived, that a link resolves, that DKIM passes. What no selector could ever check is whether the thing still reads like a receipt on a phone, or whether the layout survives with images blocked. In practice that half mostly went untested. I know mine did. A model can form a useful opinion about it now.

So the loop looks like this: your agent writes the email inside a safe vocabulary, sends a real message to a real mailbox, proves the round-trip with deterministic checks, and then renders an advisory judgment on how it reads. The agent is already sitting in your editor. Point it at the MCP and let it show you the rest. The [docs](https://fixture.email/docs) are written for agents as much as for you.