Living emails will not exist until they are as easy to make as static ones — which means the next email tool is not an editor but a factory that compiles experiences
The Production Gap
The architecture essay argued that the static template is obsolete, and that AMP, AI, ActionAds, and Atomic Rewards can rebuild Sell, Notify, and Relate into living surfaces. It made one concession near the end and then moved on: living emails are materially harder to produce than static ones, and the tooling to make them is itself something to be built.
That concession is the whole subject of this essay. A living email that only an engineer can build will never be sent at scale, because the people who make marketing emails are not engineers — they are marketers who today drag image blocks into a template. The answer is a new kind of authoring environment — a Living Emails Factory — that makes a living email as easy to compose as a static one, connects to the brand’s data by default, and hands the engineering to AI rather than to the marketer. The tooling is not a support layer beneath the thesis. The tooling is the product.
**
Every part of the living-email argument assumes the email gets built. The interactive poll, the live-on-open status, the per-recipient hero, the funded ActionAd, the memory write-back — each is described as though it simply appears in the inbox. None of the prior work said how. The gap between ‘this is what a living email does’ and ‘here is how a marketer makes one’ is where most good ideas about email quietly die. A static promotional email can be assembled by one person in an afternoon using tools that have existed for fifteen years. A living email — interactive, personalised per recipient, bound to live data, rendering in both AMP and HTML, and writing its results back to memory — is, with today’s tools, a small software project. No marketing team ships a small software project every Tuesday.
Today, an email is built by dragging images into a template.
Look at how marketing email is actually made. A marketer opens a drag-and-drop editor — Bee, the editor inside their ESP, or a builder an agency maintains — and drags in a banner, a row of product images, a block of text, a button, a footer. They style it, preview it, and send. The output is an HTML document: a fixed arrangement of images and text, identical for everyone who receives it, that does nothing once it lands. This toolchain is mature, fast, and widely understood. That is its strength and the reason it persists. But every assumption it rests on is an assumption a living email breaks. The block is an image. The output is a document. The content is the same for everyone. Nothing updates after send. Nothing is remembered.
