The Stack Was the Workaround

The idea was straightforward: instead of logging into the CMS, navigating menus, finding the right content block, editing it, previewing it, and hitting publish, the client could just tell an AI agent what they wanted changed. "Update the homepage banner to promote our summer campaign." "Add a new case study to the portfolio page." "Change the opening hours on the contact page." The agent would handle the rest.

It worked. The client was happy. We moved on.

But something kept nagging me. So I took a step back and asked a simple question: what did we actually build, and what was the core intention behind it?

The intention was never "connect an AI to a CMS." The intention was: make it effortless for a non-technical person to get content onto their website. The CMS was just the mechanism we happened to use. And we'd bolted an AI agent onto that mechanism to make it easier.

Which raises an uncomfortable follow-up question: if the agent is the one interacting with the CMS, why does the CMS need a human-friendly interface at all?

The interface nobody is using anymore

Picture what happens in the setup we built. The client talks to the agent. The AI agent translates that into API calls to the CMS. The CMS processes those calls, stores the content in its database, and the frontend pulls it out and renders it.

The entire visual editor, the drag-and-drop interface, the block builder, the media library with its thumbnail previews, the role-based access panel, the preview environment: none of it gets touched. The agent bypasses all of it. We built a conversational layer on top of a visual layer that is no longer in the loop.

That visual layer is not free. It's licensed software. It requires hosting. It needs maintenance, updates, and security patches. It adds complexity to the architecture. And in this setup, it's doing one job: being a middleman database with a UI that nobody opens.

Zoom out further

This is not just about one project. The entire modern web stack starts to look different through this lens.

Think about why each layer exists. You have a CMS because content editors need a friendly interface. You have React or Vue because you need components to render dynamic content from that CMS. You have server-side rendering or static site generation because you need that rendered output to be fast HTML. You have caching layers because all that rendering is expensive.

Every layer is a consequence of the one before it. And the first domino, the one that set off the whole chain, is a single constraint: non-technical people can't write HTML.

That's the entire origin story of the modern content stack. Billions in venture capital, thousands of companies, millions of developer hours, all building increasingly sophisticated toolchains to bridge the gap between "I want to say this on my website" and HTML appearing in a browser.

An AI agent closes that gap directly. Someone says what they want. The agent writes the HTML. Done.

What actually becomes unnecessary

The visual CMS editor is the obvious one. Not structured content storage itself. If you have multiple frontends consuming the same content, a headless CMS as a data layer still earns its place. But the drag-and-drop, WYSIWYG, block-editor UI that companies have spent years building, and clients have spent serious money licensing? That's what the agent replaces.

Frontend frameworks as content rendering layers come next. React, Vue, Svelte: for content-driven sites like blogs, landing pages, marketing sites, and product pages, these frameworks exist to transform structured CMS data into interactive UI. When an AI agent generates clean HTML directly, you skip the framework, the build pipeline, the hydration, and the bundle optimization. The output is lighter and faster than what most framework-based sites produce.

The SSR/SSG debate dissolves with it. Pre-rendering, hydration strategies, islands architecture, partial hydration: all clever engineering to make framework-rendered content perform well. None of it matters when you're serving static HTML that was never a framework app to begin with.

To test this, I spent a weekend wiring up three AI agents: a planner as the coordinator, a code agent, and a content agent connected to Sanity via CLI. No external tooling, just agents orchestrating each other. Content in, HTML out, deployed. First attempt, fully live. Lighter and faster than the stack we'd built for the client project that started this whole train of thought.

What doesn't go away

Architecture doesn't go away. Someone needs to decide that agents are the right approach, which content store fits, how the pieces connect, and what the output should look like. That weekend project worked because I've spent years building these things the hard way and could make those calls quickly.

APIs become more important, not less. Systems still need to communicate. Data still needs to flow. Agents are native API consumers, which makes well-designed APIs even more valuable.

In fact, this is already evolving. For the client project, we wrote custom integration code to connect the agent to the CMS. That works, but it doesn't scale: every new service means another custom connector. This is where protocols like MCP (Model Context Protocol) come in. MCP gives agents a standardized way to interact with any service that exposes an MCP server. No custom glue code per tool. A CMS, a database, a deployment pipeline, an analytics platform: if it speaks MCP, any agent can use it out of the box.

That's a meaningful shift. Traditional APIs were designed for developers to call from application code. MCP is designed for agents to discover and use autonomously. The difference matters. When an agent can browse available tools, understand what they do, and chain them together without someone hand-wiring each connection, the cost of integrating a new service drops to near zero. That's what turns the weekend experiment from a one-off into a repeatable pattern.

So the API layer doesn't just survive. It graduates from "interface between codebases" to "interface between agents and services." The companies that expose their capabilities through agent-friendly protocols will be the ones that stay relevant. The ones that bet everything on a pretty UI… not so much.

Judgment stays human. An agent produces technically correct output all day long. Knowing whether the content structure serves the user, whether the message lands, whether the architecture will hold up at scale: that's still on us.

What this means if you're in this industry

At Incentro, we do digital consultancy, so I'll be direct about it: if your value proposition centers on building websites or applications with a content management system, you're selling a solution to a constraint that is disappearing. The conversation has to shift from implementation to architecture, from building layers to knowing which layers are no longer needed.

The teams that will do well are small groups who understand systems, can design the right agent workflows, and have the taste to evaluate the output. The teams that will struggle are the ones still packaging React component sprints for content sites as their core offering.

This is not a two-year prediction. I built the alternative version over a weekend, on my couch, as a side experiment. It worked the first time.