We Didn't Add Chat to a CMS. We Made Conversation the CMS.
Most platforms are retrofitting MCP onto dashboards and editors that already exist. We went the other direction — and the design choice cost us something real.
The industry right now is moving fast in one direction. WordPress.com, Framer, and the major platforms are wiring MCP integrations so AI agents can manage existing sites through natural conversation. The workflow is: chat with Claude or ChatGPT, and those agents take actions on your existing CMS. That's not a criticism. It's a reasonable response to what users already have.
We went the other direction and built conversation as CMS from the ground up. Not by accident.
What these retrofit integrations have in common is that the CMS is still the CMS. The conversation is a new way to drive it, but the underlying model (pages, posts, draft states, publish buttons, version diffs) remains the authority. An agent speaks; the dashboard listens; the interface is still the interface. WorkOS put it plainly in early 2026: the industry is moving from "apps with AI" to "AI with apps," with conversation becoming the layer that sits in front of everything.[2] That framing is accurate. It also still describes a world where the app is the thing being wrapped.
What changes when you don't wrap anything? When the conversation is the CMS, not a remote control for one?
That's the question we started with.
What the rest of the industry is actually building
In March 2026, WordPress.com announced that AI agents (Claude, ChatGPT, and others) can now create and manage content directly on WordPress.com sites through natural conversation: 19 new writing abilities across posts, pages, comments, categories, tags, and media. New posts default to draft, and explicit human approval is required before changes take effect.[1]
That last design choice is telling. The draft/approval safety step exists because the underlying model (the WordPress post, the page, the published/draft binary) is what actually holds the site's state. The conversation can touch it, but the conversation isn't it. You're sending instructions to a system with its own structure, and that structure is the authority over what's live.
This isn't a flaw in the retrofit approach. For the hundreds of millions of sites already on WordPress.com, meeting people where they are is the right call. The distinction I'm drawing is about what the model assumes. A retrofit assumes a content model (drafts, pages, publish steps) that predates the conversation. A conversation-first design assumes no such model. The conversation creates the model as it goes.
Why we started from the conversation instead
The honest answer is that we started by watching how non-technical marketers actually work, and the dashboard pattern didn't match it.
What we kept seeing: marketers don't think in pages-and-publish-states. They think in "I want this to say something different" and "the pricing changed, update it everywhere." The workflow is already conversational. The intent is immediate. The current structure of the site is mostly invisible to them. They interact with the outcome, not the thing underneath it.
The market gave external signal that conversational building is becoming mainstream. Lovable, one of the larger natural-language-first builders, reported adding $100M in a single month in early 2026, reaching roughly $400M ARR with 146 employees.[3] Those are company-reported figures via TechCrunch; I'm treating them as directional, not audited. The direction, though, is clear: building through conversation isn't a niche behavior anymore.
The architectural decision we made is that a conversation utterance is a version. Not a representation of a version stored somewhere else, but the version itself. Boomlink's content-publishing layer has native version snapshots with traffic weights; the sandbox-editing lifecycle ties directly to the conversation's state. When you describe a change, that conversation drives state, and that state is the site. The conversation is the version history.
I want to be precise about what that claim is and isn't. It's a design stance, an honest description of how the flow is experienced, not a feature guarantee that every utterance is a production-safe commit. The philosophical framing is mine; the architecture underneath it is real.
What disappears when conversation is the CMS
Three things aren't there. Each absence is a decision.
No save button. When a conversation utterance creates a version, save is implicit. There's no separate draft state the user has to manage. You can't accidentally have two versions of the truth: the thing in the editor and the thing that was saved. There's only one, because the editor and the source of truth are the same object.
No separate version history. Scrolling back through the conversation is reverting. The history panel you'd find in a traditional CMS isn't a separate system. It's the thread you're already reading. This turned out to be more legible to some users than a version diff, and less legible to others. I'll come back to that.
No manual publish step. Publishing is part of the conversation lifecycle. When you've described a site and confirmed it, that conversation state is what's live. There's no export button separate from what you just said.
If you've read about why the production step is the bottleneck for non-technical marketers, these three absences are the reason that bottleneck shrinks. The steps aren't faster — they're gone. That's a different kind of claim, and it matters to get it right.
What we learned about how non-technical marketers actually work
Some of what the design choice revealed was validating. Some of it was genuinely surprising, and I'd rather be honest about both.
The pattern that fit the thesis most cleanly: non-technical marketers don't save-and-publish. They iterate. They describe what they want, look at what appeared, describe what should be different, and repeat, until it's right. Then they want it live without another step. The model we built is designed exactly for that sequence, and it matched naturally.
The thing that challenged us: some users wanted a dashboard to audit what they'd built. Not to manage it. To audit it. To see the structure of the site separately from the conversation that created it. The conversation log was the audit trail, but it didn't look like a dashboard, and for users who wanted a bird's-eye view before committing to a change, the absence of a visual overview was real friction. Trust had to be earned through the conversation itself, because there was nothing else to fall back on.
The version history cut both ways. "Here's what you said four exchanges ago" is easier to understand than "here are the lines that changed between v7 and v8." But a conversation includes intent and context alongside state changes, which isn't always what you want when you're trying to isolate a specific edit. We're still working through what the right shape of that tradeoff looks like.
I'm not reporting these as problems we've solved. They're the honest counterweight to the philosophy.
There are two real answers to the same design question. You can retrofit conversation onto an interface that already exists: add capability without asking users to change their mental model, meet the install base where it is. That's a legitimate bet, and the major platforms are making it well.
Or you can start from the conversation and ask what disappears when you do. You give up the familiar structure. You ask users to extend trust to a model they can't see the shape of. In exchange, you get a workflow that matches how non-technical people actually think about their sites, and a set of absences that, if you're honest, are genuinely better than the things they replace.
Neither choice is obviously right. The question worth asking is what each one assumes about how people want to work. That assumption drives everything downstream. The one-source-of-truth model is only as useful as the interface that maintains it.
If this framing changed how you're thinking about the question, pass it to someone else building in this space.
References
- WordPress.com Blog — "AI agents can now create and manage content on WordPress.com" (published 2026-03-20, updated 2026-05-15). 19 new writing abilities across posts, pages, comments, categories, tags, and media; new posts default to draft with explicit human approval required before changes take effect. https://wordpress.com/blog/2026/03/20/ai-agent-manage-content/
- WorkOS Blog — "The shift from apps with AI to AI with apps: Why your next app should live inside Claude" (2026). Strategic framing: "from apps with AI to AI with apps"; "the battle isn't whether AI is embedded in your app … it's whether your app can embed in AI." References the 2026-01-26 Anthropic/OpenAI MCP Apps announcement. Attribution: WorkOS; strategic claims are opinion, not independently verified. https://workos.com/blog/building-mcp-apps-inside-claude-chatgpt
- TechCrunch — "Lovable says it added $100M in revenue last month alone, with just 146 employees" (published 2026-03-11). Company-reported figures: ~$400M ARR, +$100M in a single month, 146 staff. Reputable outlet reporting vendor-stated numbers; not independently audited. Used as directional market signal only. https://techcrunch.com/2026/03/11/lovable-says-it-added-100m-in-revenue-last-month-alone-with-just-146-employees/