Your Draft Toggle Isn't a Review Layer. Agent-Edited Sites Need Branching.
Framer shipped branching for agent edits in June 2026. Most platforms still offer a draft toggle. The difference is not a UX preference. It is a structural one.
The draft/publish toggle had a good run. When a human wrote each edit, the toggle made sense: one change, one session, one review, one flag. You either published it or you did not. That binary captured what the review process needed to capture.
In June 2026, Framer shipped branching as the core mechanism for reviewing agent edits before they reach production.[1] The announcement got real attention: #1 on Product Hunt the day after launch, 556 upvotes.[2] Framer is not alone in the "safe AI editing" conversation. WordPress.com, Webflow, and every major platform now has some version of an answer to the question of how to keep a human in the loop. The answers are not equivalent.
We covered who holds authority over agent edits in a CMS context. This post is about what shape that authority checkpoint needs to take. A toggle and a branch are not the same structural unit, and the distinction only becomes obvious once the edit volume goes up.
Review branch: a parallel workspace state where an agent's edits live in isolation from the live site until a reviewer compares them against production, approves the batch, and merges. A draft toggle is binary (live or not); a review branch is structural (separate, comparable, and mergeable).
Two Platforms Called It Safe. One Built Something Different.
In March 2026, WordPress.com extended its MCP integration from read to write: 19 new abilities across posts, pages, comments, categories, tags, and media. New posts default to draft. Every change requires explicit human approval before taking effect.[4][6]
Webflow, which now describes itself as the agentic web platform for modern businesses, shipped AEO: a closed-loop system where agents surface broken links, outdated schema, and missing alt text, prepare recommendations, and enable direct publishing of accepted changes from within the platform. The vendor description: "closed loop from measurement to recommendation to execution."[5] Webflow now positions itself around agents and humans in one shared workspace: "Bring team members and AI agents into one shared workspace, with design systems to keep everything on brand."[3]
Then on June 16, Framer shipped branching.[1]
The surface framing looks similar: Framer Agents work inside the canvas, handling page generation, responsive breakpoints, content updates, SEO metadata, broken-link and accessibility audits. External agents connect via tools like Claude Code, Cursor, and Codex.[1] The team described the design intent: "Humans bring taste, judgment, and control."[1]
The mechanism is different. In the WordPress and Webflow AEO model, a change either is or is not live, with a human acceptance step in between. In Framer's model, changes land in an isolated branch. You review and compare against live production. You merge approved work. You publish when ready.[1]
The first instinct is to file all of these under the same label: safe AI editing. They are not the same category.
The Toggle Made Sense When Humans Set the Edit Rate
This is not an argument that the toggle was a design mistake. It was not.
The draft-default binary works at human edit cadence. When a marketer or developer makes a change, they were present for the conversation that created it. They know what the change is. They know what it should look like. The review step is mostly confirmation. The toggle captures what they actually need to know: is this ready to be live?
WordPress and Webflow AEO both built the draft-default and accept/reject step into the architecture deliberately, as the default state, not as a configurable safety option you turn on if you are worried.[4][5] That is a design choice from two independent teams, and it reflects sound reasoning about what the review layer needs to do when humans make changes at human speed.
One session. One draft. One toggle. The reviewer and the author are often the same person, or at minimum in the same conversation. The review surface matches the edit volume.
Agents Change the Edit Rate. The Toggle Does Not Scale.
Framer Agents do not make one change at a time. They generate pages, update responsive breakpoints, rewrite content, edit SEO metadata, and audit broken links and accessibility across a canvas in a single session.[1] External agents connect tools like Claude Code, Cursor, and Codex to act on the same site.[1] This is not one-change-at-a-time editing.
When a batch of agent edits arrives at a toggle, the reviewer faces one question: is this live or not? The toggle cannot show which of the 17 changes introduced the layout break. It cannot show what the metadata looked like before. It cannot let you approve the content rewrite while rejecting the SEO update. The flag is a binary. The edits are not.
This is not a failure of the toggle as a feature. It is a mismatch between the tool and the context it now operates in. The toggle was designed to answer "is it live?" for one change, made by one person, at one moment. Applied to a batch of autonomous edits, it answers the same question with less information than the reviewer actually needs.
Framer stated the design principle directly: "Humans bring taste, judgment, and control."[1] Taste and judgment require seeing what changed, in isolation, before deciding. A flag does not provide that. A branch does.
A Branch Is a Different Structural Unit, Not an Upgrade
Here is the precise distinction worth holding onto.
A toggle answers: is this change live?
A branch answers: what changed, compared to what was live before, and do I want it?
These are not the same question. The second one requires three things a toggle cannot provide: isolation (the change lives in a separate state from production), comparison (you see the branch against the live site), and a merge-or-reject decision point (you choose which changes come in, not just whether the whole batch goes live at once).
Framer 3.0's branching gives reviewers all three. Changes land in an isolated branch; you review and compare against production; you merge approved work; you publish when ready.[1]
The branching principle is not proprietary to any one product. The design argument for state created directly rather than retrofitted is relevant here: the interesting question is not which platform ships a "branching feature" but whether the architecture keeps the agent's workspace structurally separate from the live site. Boomlink, built as an MCP-native site builder, separates the agent's AuthoringWorkspace from the published state by design. Publishing creates an immutable SiteVersion snapshot from a workspace branch reference (mainBranch / promoteBranch); version numbers auto-increment and cannot be reused. A/B traffic splitting across published versions and rollback are both supported. The agent's edits and the live site are separate states with a versioned boundary between them. That is not a git pull-request workflow with named reviewers and required approvals, but the structural unit is the same: workspace versus live, versioned, not flagged.
The toggle gives you a gate. The branch gives you a gate you can see through.
The Counterargument: Is Not a Good Preview Mode Enough?
Most platforms offer preview modes. Many generate shareable preview links. Some show you a live render of the staged version before it goes public. If you can see the change before it goes live, what does a branch add?
A preview mode shows you the change. A branch isolates the change from production so a team can review it without affecting the live site, compare it side by side against what is currently there, and make a merge-or-reject decision that is recorded.
The operational difference: preview is a read surface. A branch is a separate state.
Webflow positions agents and humans in one shared workspace, with design systems to enforce brand consistency.[3] That is a coherent model: shared state, each recommendation previewed and accepted before going live.[5] Isolation is not the goal because the workspace is designed to be shared. Preview gates individual changes as they arrive.
Where preview becomes harder to use: when the reviewer was not part of the conversation that created the change. The agent made 23 edits across four sections. The preview shows you the result. It does not show you which edit changed what. If the layout broke somewhere in the middle of that batch, the preview shows you a broken page; the branch would have let you step through changes in isolation and locate the one that caused the problem.
Preview is adequate when the reviewer knows what to expect because they specified the change. It is less adequate when the agent worked autonomously and the reviewer is seeing the result for the first time across many modified sections.
What to Ask When You Choose a Platform for Agent-Edited Sites
The capability question is settled. WordPress has MCP write access. Webflow has AEO. Framer has native agents and external-agent connections. Every major platform now has an answer to "does it support AI agents?" A related but separate question is whether your site is structured so agents can understand and surface it for AI search. We covered the open spec trying to solve that.
The question that is not settled: when an agent edits my site, can I see that edit in isolation, compare it to what is live now, and decide before anything goes public?
That question has two parts. First, structural isolation: does the platform keep the agent's workspace separate from the live site, or does the agent write directly into shared production state? Second, comparison: can you see a meaningful diff, not just a preview render, before accepting?
A platform that keeps agent edits in a separate workspace with a versioned boundary before publish is offering the branching principle, whether or not it uses that word. Boomlink's architecture separates the agent's AuthoringWorkspace from the live site; publishing creates an immutable SiteVersion snapshot from a branch reference; rollback is one step. The structural boundary is real: workspace versus live, versioned, not flagged.
See how Boomlink separates agent edits from your live site.
The question to take to any platform you are evaluating: what is the structural unit for review? If the answer is a toggle, know what that buys you and what it does not. If the answer is a branch or a workspace-to-live boundary with versioning, know what that buys you too. They are different tools for the same job. The job is harder now that agents are doing the editing.
The toggle was a reasonable answer to a problem that has since changed shape. When humans made the edits, at human speed, one change at a time, a binary was the right level of abstraction. The reviewer knew what they were approving.
Agents edit at a different rate, across more surfaces, without the reviewer in the conversation. The review layer that fits that context is a branch: a parallel state you can examine, compare against production, and decide on before anything goes live. Several platforms shipped that answer in June 2026. It is now the right question to ask of any platform you let touch your site.
See how Boomlink separates agent edits from your live site.
References
- Framer Blog, "Introducing Framer Agents, Branching, and the new Community" (published 2026-06-16). Framer 3.0 launched branching so agent changes land in an isolated branch where you review and compare against production, merge approved work, and publish when ready. Framer Agents generate pages, responsive breakpoints, content, SEO metadata, and audit broken links and accessibility. External agents connect tools such as Claude Code, Cursor, and Codex. Vendor framing: "Humans bring taste, judgment, and control." https://www.framer.com/blog/framer-3/
- Product Hunt, Framer launches page (captured 2026-06-24). Framer 3.0 was ranked #1 product of the day for 2026-06-17, with 556 upvotes. Used as industry-signal corroboration for the scale of attention the branching launch received. https://www.producthunt.com/products/framer/launches
- Webflow homepage (captured 2026-06-24). Webflow describes itself as "The agentic web platform for modern businesses" and positions agents and humans together: "Bring team members and AI agents into one shared workspace, with design systems to keep everything on brand." Attribution: vendor self-description. https://webflow.com/
- WordPress.com Blog, "AI agents can now create and manage content on WordPress.com" (published 2026-03-20, updated 2026-05-15). WordPress.com extended MCP from read to write with 19 new abilities across posts, pages, comments, categories, tags, and media. New posts default to draft; every change requires explicit human approval before taking effect. https://wordpress.com/blog/2026/03/20/ai-agent-manage-content/
- Webflow Blog, "Introducing Webflow AEO: an agentic, closed-loop system for AI discovery" (published 2026-05-20). Agents identify site issues, prepare recommendations, and enable direct publishing of accepted changes. Vendor description: "closed loop from measurement to recommendation to execution." You accept recommendations before they go live. https://webflow.com/blog/introducing-webflow-aeo
- TechCrunch, "WordPress.com now lets AI agents write and publish posts, and more" (published 2026-03-20). Independent-outlet corroboration that WordPress.com extended MCP from read to write; every change requires user approval, posts default to draft. https://techcrunch.com/2026/03/20/wordpress-com-now-lets-ai-agents-write-and-publish-posts-and-more/