The New (Agentic) Era of Content Management

For a long time, choosing a CMS was a largely settled question. WordPress (and to a lesser extent, Drupal) had become ubiquitous for a majority of SMBs. Shopify thoroughly dominated the ecommerce arena, and a few site builders like Webflow and Framer competed in their own space. DXPs offered extended functionality and assurance at scale, covering the needs of larger organizations and the enterprise. But for many, the decision was largely a factor of content models, editor experience and hosting cost. We’ve seen the headless disruption crack and fracture the ecosystem over the last few years, but in a large part, choosing the right CMS had become formulaic.

Now, that same math isn’t mathing anymore. The foundation of what a CMS is and who it serves has changed, yet again.

There used to be two core groups involved in that process: the IT teams, engineers and developers who build and maintain the technology itself, and the marketers, content producers and editors who create and own what goes in it. 

In 2026, there’s a new seat at the table: agents. AI-powered users working on behalf of both of those other groups are increasingly desired from the business side and supported by the technology itself. It’s a facet to the conversation that, just six months ago, we never needed to discuss, but could now be a deciding factor.

Industry-Wide Change

If we look across the market, we see the same moves happening at nearly the same time at virtually every tier.

WordPress 7.0 was released just this month and added a new Abilities API, an MCP Adapter and built-in AI Connectors for the major model providers. The month prior, in April, Cloudflare released EmDash, going even further: a CMS built from scratch via code generation around the premise that AI agents should be first-class users, and shipped with a full MCP server and documentation designed for AI ingestion and agentic workflows.

It’s not just the SMB-focused open source where these shifts are happening, but in the Large Business and Enterprise market as well, where more robust CMS/DXP offerings are undergoing their own changes. 

Sanity holds itself out as a “content operating system” and invested heavily in their MCP tooling — agents working from Cursor or Claude Code can query content, manage releases and deploy schemas directly while keeping all the platforms content type rules-enforcing behavior. Contentstack has launched Agent OS, reframing their DXP around what it calls context management rather than content management. Adobe, Contentful, Storyblok… the list runs the full length of the market, buoyed by the need for speed in large organizations and measured by the weight of incumbency and risk-averse compliance requirements.

These changes also open the door to meaningfully different, agent-forward, right-sized bespoke CMS solutions. There, the big question is less “Is there a community for this software? Can I hire a dev team to work with it?” and more “Can our agents work with this?” The speed of agentic development may see stripped-back content frameworks become more valuable than fully-fledged CMSes in the first place — something we’ve deployed internally through Claude to enable some teams to punch way above their technical expertise’s weight.

Regardless of the scale, these aren’t bolt-on chatbots or the Third Coming of Clippy — they’re architectural, bedrock product decisions to change the core functions of their platforms to include AI. When we see platforms this different — a 22-year-old open-source incumbent, serverless challengers, headless leaders and enterprise DXPs — all rebuild around agent access in the same year, we know the game has changed.

A Richer Alphabet Soup

The already ridiculous cacophony of Martech acronyms and initialisms has a newcomer as well.

Many are already familiar with the concept of an API. It’s been the model for how software has talked to other software for decades. Think of it as a set of specifically shaped wires, capable of communicating certain information with the right request: add this information to your list of posts, you get a new post with content; fetch this information about a user ID, you have a purchase history; push this information to another server, you send an email. APIs are precise and reliable, but expect the operator to understand the specific shape of all those wires and what exactly they can communicate, in which format, to where.

MCP — the Model Context Protocol — is newer, and it’s not built for systems to talk to systems, or for engineers and developers to extend functionality or create integrations. It’s for AI agents. Instead of requiring the agent to memorize all those wiring structures and conventions, the MCP server gives it a complete map with a guide. The agent can ask, in effect, “What can I do here?” and get a structured response back. Critically, it also holds context across a task, meaning multi-step procedures don’t restart from zero at every step.

Why bother? API-only platforms can be automated, but every integration must follow that wiring diagram precisely. It’s custom-built, rigid and breaks when the API changes. An MCP-capable platform can be operated by any agent that speaks the protocol, and adapts as underlying capabilities change. 

MCP doesn’t replace APIs. In fact, it usually sits on top of them. But that’s the difference between a platform an agent can use and a platform an agent can use intuitively. That difference is exactly what WordPress 7’s MCP Adapter and Sanity’s MCP tooling are built to deliver, and what EmDash was designed around from day one.

And, like all of this, it’s moving fast. MCP servers are available for many platforms, but often in a beta or experimental capacity. WordPress’s latest update has already been receiving lots of necessary feedback to shore up the new work they’ve done. The reality is that these shifts are more indicators of platform direction than settled core features… for now. But those signals mean a lot when CMS decisions are increasingly critical to business success.

Generative AI in the CMS

The other big shift is generative work moving inside the CMS itself. Adobe, WordPress and Contentful all aim for their version of the same fundamental loop: connect your AI model of choice (ChatGPT, Claude, etc.) one time, configure it with their system and use it to draft and generate text, images, alt text, ledes, summaries or translations directly in the editor. No separating tooling, no copy-pasting. 

It’s another step in the direction of the CMS as the home for content creation, not just management, and it can be a big shift in thinking about how editors and content teams shift their ways of working to embrace a more efficient model, while also presenting some new challenges: the UX of writing in a CMS is often compromised by the complexities of blocks, components, elements and all the rest of the UI. This new system is intended to incorporate the collaborative shift of co-authoring with an agent or LLM — either the person or the machine can handle the bulk of the copywriting, and either can handle the work of transforming and adjusting that content to fit the mechanics of the CMS.

Planning for the Agentic Unknown

We’ve all read the headlines. AI deletes a critical production database. An agent emails exactly the wrong email to exactly the wrong email list. A new production or website was launched that exposes sensitive customer PII. The instinct is to read those as proof the technology is reckless, which, compared to a person who knows their job and reputation are on the line, it may be. But we read those situations differently and look at them as evidence of failed AgentOps, not unavoidable costs of working with AI.

Infrastructure and technology systems already embrace the concept of defense in depth — not a single guardrail, but several, each independent and built on the assumption that mistakes happen and that no plan or person is perfect. Some of that lives in instructions: the prompts, skills and configuration files that scope what AI agents are supposed to do. But the most reliable guardrails aren’t instructions — they’re permissions. 

The principle of “least privilege” long predates AI, but is perfectly applicable here: give any actor only the minimum access its job requires and nothing more. An AI agent working on a specific project held in a specific repository can’t wipe an entire team's GitHub if there’s a hard limit on what it can touch in the first place. Instructions are, ultimately, suggestions to prevent a dangerous action. Layered permissions make the dangerous action impossible.  

This reality shapes the infrastructure we recommend and builds on decades of technology improvement. Cheap snapshots, point-in-time restore and read replicas are nearly ubiquitous among providers, but were often seen by teams as “nice-to-haves”. The reality is that those types of technology are more critical than ever when the speed of agentic work means dozens of things can go wrong in seconds. 

Technology that was frequently discussed in the context of “disaster recovery” is now something we look at as an operational requirement for agentic projects.

The Challenge To Keep Up

All of this is moving now, and it’s unlike almost anything the industry has had to absorb. EmDash was created and launched in less than three months. Virtually every CMS has had significant updates in their AI capability in just the last six months. It’s very possible that while I was writing this, infrastructure platforms rolled out MCP updates and new database concepts, like branched-state-restore from Neon. 

We won’t pretend we’ve permanently solved this, because nobody has. What we can do — what our human-centered approach and technology-agnostic approach demands — is to remain deeply informed and positioned to look over that horizon. By understanding what tomorrow will bring, we can make better decisions with our partners and clients — and their agents — today.