Architecture: how does PostHog AI edit the open email in any email editor?

Cast: Claude Opus 5.5 with Michael; deep code research on GPT-6.1 Sol. /prototype (architecture brief), with grilling.

Question

How should "PostHog AI edits the open email" be shaped, as one deep module that each email editor adopts in a few lines?

Decide, and show with a rough architecture brief and stub code:

The tool contract. A stateless MCP tool that applies design operations and returns the patched email without saving, or a tool that validates operations the frontend then applies itself. Both reuse design_operations.py; no hidden early draft, no frontend-applied sandbox tools.
What the agent sees. What attached context carries so the agent can address blocks by id (design JSON, a block outline, or a fetchable reference) within the context budget, and which trusted instruction tells it that its edits show in the open editor.
The seam. The editing seam the refactor moves every editor onto (EmailTemplater and its logic, Make it yours, the workflow step through CyclotronJobInputs, the template library, Broadcasts), and the few lines a surface adds to adopt live edit. Target keys per open email.
Sequences. How AI switches Make it yours to another email before editing it, and how the list marks changed emails.
Turn lifecycle. Lock and stop, and one-step undo of an AI turn.
The stack. Confirm or reorder the charted stack: the tool from master; the editor refactor from master; the primitive wired into the workflow step, the template library and Broadcasts; Make it yours on top of feat(workflows): attach first-run email context to posthog ai PostHog/posthog#112079; then the live-update experience. Functionality stays ahead of the experience layer.

Resolution: the brief linked from this ticket, and the implementation tickets updated to match it.