Published July 13-17, 2026
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
1
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.
2
Why the Old Editor breaks
A template produces a document; a living email is an application.
Figure 1 — The template editor produces a document: fixed, identical, inert. The factory produces an application: live, per-recipient, learning.
The cleanest way to see the problem is to name the category. A template editor produces a document — a fixed artefact, complete at the moment of saving. A living email is an application — a small program that runs when opened, responds to the recipient, talks to a data source, and records what happened. These are different kinds of thing, made by different kinds of tool. This is why the instinct to ‘add AMP support’ to an existing editor never quite works. You cannot bolt application behaviour onto a document tool and get an application tool; you get a document tool with a confusing new tab that produces broken applications. The right mental model is not ‘next-generation template builder’. It is an experience compiler: the marketer states what the email should do, and the tool assembles the experience that does it.
Five things a living email needs that a template cannot give.
Be specific about what is missing. First, interactivity — the blocks must do something when tapped, which means each block carries logic, not just appearance. Second, per-recipient composition — the email is a template-of-one, filled differently for each person. Third, live data binding — a balance, a delivery status, a price, fetched at the moment of opening rather than baked in at send. Fourth, memory write-back — every interaction routed back to the brand’s record of the customer. Fifth, dual rendering — an AMP version and an HTML fallback, kept in lockstep, from a single definition. Each is a discipline a template editor has no concept of. The missing capability is not in the marketer. It is in the instrument.
The trap: asking the marketer to become an engineer.
Faced with this, the tempting answer is the wrong one: give the marketer the raw materials and let them assemble the application by hand. Hand-author the AMP. Maintain the HTML fallback in parallel. Wire the data calls. Set up the memory routing. Test across a dozen clients that each render AMP slightly differently. This does not scale, for a simple reason. The people who make marketing emails are marketers, and they will not become engineers to send a newsletter — nor should they. A handful of sophisticated brands will hire the talent and produce a few beautiful living emails a quarter. That is not a channel; it is a craft project. For living emails to be the default, the engineering has to disappear from the marketer’s job entirely. The marketer’s job is to know the customer and the message. The tool’s job is everything else.
3
The Factory
The bar: as easy as making an HTML email today.
Start with the design constraint that governs everything else. A living email must be as easy to make as a static one is today — not almost as easy, not easy-with-training, but genuinely as fast and as approachable as dragging blocks into Bee. If composing a living email takes a marketer materially longer than composing a static one, the static one wins every deadline, and living emails stay rare. This means the factory cannot expose any of the underlying complexity — not the AMP, not the fallback, not the data plumbing, not the memory wiring. Familiar on the surface; entirely new underneath.
Seven layers, from intent to memory.
The cleanest way to describe the factory is as a stack of layers, each one absorbing a discipline the marketer used to lack. At the top sits the Intent Layer: the marketer states the job — ‘a Notify email for a delayed shipment’ — and the system begins from purpose, not a blank canvas. Below it, the Block Layer supplies governed, reusable live components. The AI Composition Layer turns them into a customer-specific draft. The Data Layer binds the email to CRM, CDP, catalogue, orders, loyalty, and automation. The Rules and Governance Layer decides what each surface is allowed to carry. The Render and Fallback Layer emits valid AMP and a genuinely good HTML fallback in lockstep. And the Memory and Measurement Layer writes every interaction back to the Context Graph. Each layer is a thing the marketer would otherwise have had to be an engineer to handle — absorbed into the tool, where it belongs.
Figure 2 — The seven layers of the Living Emails Factory. The marketer states intent at the top; a sendable, living, learning email falls out of the bottom.
Block-based, but the blocks are alive.
The factory keeps the one thing about the old editor that works — composition by block — and changes what a block is. In the old editor, a block is an image or a piece of text: pure appearance. In the factory, a block is a live component — a poll, a product carousel, a live-status panel, a size picker, an ActionAd slot — and each carries its own logic, its own data binding, its own AMP build, its own HTML fallback, and its own memory hook, all packaged inside it. The marketer drags in a ‘poll’ the way they used to drag in an image, but the poll arrives complete. The complexity does not vanish — it is packed inside the block, where the marketer never has to see it.
Figure 3 — Anatomy of a live block. The marketer drags it in like an image; the logic, dual render, data binding, and memory hook are pre-engineered once and ride along inside.
Governance is not a constraint bolted on; it is a layer.
The Rules and Governance Layer is where SNR stops being a diagnostic and becomes enforcement. A Notify email may carry live status and a service next-step, but not a random reward mechanic. A Sell email may carry preference capture and first-party cross-sell, but not open third-party demand. A Relate email can carry a Magnet, Mu, one governed ActionAd, and a funding layer, because that is the surface designed to hold them. The factory reads the SNR mode of the email and only offers the blocks that mode permits. The factory does not just make a living email possible; it makes the wrong living email impossible — which is what keeps a bank’s Notify surface from ever sprouting a points game, and a Sell email from leaking a competitor’s ad.
4
From Marketer Workflow to Agentic Workflow
AI-composed, not hand-built.
Blocks lower the floor; AI removes it. The factory’s composition layer is agentic: the marketer states an intent — ‘a Tuesday Relate email for lapsed customers, light, with a poll and a Mu reward’ — and the agentic layer drafts the email, choosing blocks, writing copy, setting the personalisation rules, and proposing the fallback. The marketer then edits and approves rather than building from a blank canvas. The marketer moves from maker to editor — from assembling the email to judging the one the factory proposed — because the fastest way to make a living email as easy as a static one is to not start from nothing at all.
A workshop of named agents does the engineering the marketer used to outsource.
Behind the factory sits the M-Agents collective, pointed at composition, and it is useful to name the division of labour. An Intent Agent maps the brief to an SNR pattern. A Block Agent selects the right interactive modules. A Content Agent drafts the copy, tone, and variants. A Data Agent binds the right fields from the right systems. An AMP Agent and a Fallback Agent render the experience across client conditions. A Policy Agent checks brand rules, legal constraints, and SNR appropriateness. A QA Agent previews the output and flags issues. A Memory Agent defines which interactions count as learning signals and how they are written back. The engineering did not disappear from the living email; it moved from the marketer to the agents.
Figure 4 — The marketer directs; a workshop of agents builds; TwinFactory fills per recipient; and the SNR governance layer decides what each surface may carry.
The Factory builds it; TwinFactory fills it.
The division between the two engines is clean and worth stating plainly. The Living Emails Factory is the authoring environment — it makes the living email and produces the template-of-one, a structure with the personalisation rules expressed but the individual values unfilled. TwinFactory and the BrandTwins it maintains fill it — the BrandTwin for each customer decides which products, which tone, which offer, which timing, drawing on that customer’s record in the Context Graph. One produces the template-of-one; the other produces the one. Together they turn a single composition into a million individually-composed emails, none of which the marketer assembled by hand.
5
From Editor to Factory
This is a category shift, not a feature.
It would be a mistake to read this as ‘a better email editor’. The Living Emails Factory is a different category of tool, the way a spreadsheet is a different category from a calculator. The template editor made documents; the factory makes applications that are plugged into the business, composed by AI, filled per recipient, governed by SNR, and learning by default. The right comparison for what email creation becomes is not Bee with more blocks — it is the move from designing a page to operating a system. It is the point where the brand’s data, its personalisation engine, its agentic layer, and its memory all meet, in a tool a marketer can use without help.
The tooling is the moat.
The living-email thesis will not be won by the team with the best deck, or even the best conceptual architecture. It will be won by the team that makes creation easy. The leap from static email to living email is not primarily a content leap; it is a tooling leap. Whoever makes that factory real will not merely improve email production — they will redefine what email can be, because the factory is the bottleneck through which every other part of the living-email argument has to pass to reach an actual inbox.
Who builds the living email?
The answer, finally, is layered. The marketer builds it, in the sense that they direct it — they bring the customer knowledge, the message, and the judgement. The factory builds it, in the sense that it supplies the live blocks, composes the draft, enforces the governance, and hides the complexity. TwinFactory builds it, in the sense that it fills the template-of-one per recipient. And the agents build it, in the sense that they do the engineering the marketer used to outsource and never sees. No single one of them builds the living email; the system does, with the marketer at the helm — the only configuration that scales, because it is the only one that keeps the marketer a marketer while the email becomes an application.
**
The static email had its editor. The living email needs its factory — and the factory is the product that lets everything else exist.