Why headless CMSs are built for this moment
We have been building this way at Two Point O since 2018, and I still remember how hard those early conversations were. I would be halfway through explaining why content should be split from presentation, and someone would stop me: “Yes, but Bert, we just want a website.” Fair enough, from where they sat. So we discussed it, sometimes tooth and nail, and we often lost the discussion. The website, we kept saying, was only one thing the content would ever have to do. We were early, and it did not always feel like a winning position in the room. That separation is normal practice now, and honestly, I think we have the agents to thank for finally settling the argument for us.
The distinction under it still matters. A web CMS assumes content is pages: edited through forms, pushed out to one website. A CMS, the way I mean it, holds structured content and leaves presentation to whatever reads it downstream. The website is one thing it feeds, not what it is. For years that split was mostly an argument about reusing content across channels. It turns out to be exactly what agents need.
A page is one way content gets rendered, not what it is.
Knut MelvaerPrincipal Developer Marketing Manager at Sanity
An agent does not care about your hero image or your layout. It wants to know a product has a price, that the price is a number tied to a spec and a legal line, and that changing it once changes it everywhere. The headless platforms we build on already model content like that. They are not racing to become agent-ready. They were built on the same separation that lets an agent read, query and act without guessing. The argument that used to be about going headless is now an argument about governance.
INSIGHT
One thing I want to be clear about, though. The platform hands you the primitives. The governance does not exist until someone models it: the relationships, the rules each agent works under. That modelling is the real work, and it is bigger than it looks in a clean demo.
In plain terms, the platform is a well-wired but empty building. Someone still has to decide which room holds what, and who gets a key to which door. Doing that for your content, naming what each thing is, mapping how the pieces relate, and setting what an agent is allowed to touch, is the actual job. It is where most of the risk quietly sits, and it is a large part of what clients bring us in to do.
What do AI agents actually need from a CMS?
Digital leads ask me this constantly, so here it is without the hedging. Three things, and a decent CMS is where all three live:
Meaning it can read: A content model with typed fields and real relationships is your organisation’s knowledge, not just editorial scaffolding. Format text nicely and you get a page. Model it and you give an agent something it can reason about.
One source of truth: If the footer, the comparison table and the product page all point at one product object, an agent that changes the price changes all three at once. There is nothing to keep in sync, because there were never separate copies to begin with.
Permissions that actually hold: Who can read, who can draft, who can publish. The system has to enforce that, not the prompt.
Miss any of these and you do not have a governance problem later. You have it immediately.
Why structure beats letting the agent work it out
There is a tempting counter-argument here: models keep getting better, so why not let the agent read the raw files and figure it out? The evidence on where agents fail is why I do not buy it.
Agents are strong on a single, contained change. Ask them to keep many places consistent at once and they fall off a cliff. When Scale AI introduced SWE-bench Pro in late 2025, the leading models were scoring around 70% on standard single-issue tasks but only about 23% on the harder ones that span many files at once. Models have climbed since, but the shape holds. Keeping a product’s positioning consistent across a page, a table and a footer is that same problem, and it is exactly where agents are still weakest.
Structure does not make the agent cleverer. It removes the need for cleverness.
A reference means the price lives in one place and everything else reads it. That stays true no matter how good next year’s model gets. I would rather design the problem out than bet on the model being careful enough this quarter.
Governance belongs in the system, not the prompt
If you take one thing from this, take this. A system prompt is just the instructions you give an agent up front, something like “you may read products but never change a price.” It is a request, not a lock. The agent reads that instruction in the same stream as everything else, including the content it is working on. So a customer message or a product note with the right words buried in it can nudge the agent straight past your rule. You told it no. The text told it yes. That is why the OWASP Top 10 for large language model applications, the security community’s reference list, says plainly that a system prompt is not a security control, and points you instead at permissions the platform enforces, with every agent on the least access it needs.
This is not theoretical. Air Canada was held liable when its own chatbot gave a customer the wrong answer about a fare. You own what your agents say and do, every time. So the sentence that matters, “this agent may read products, draft price changes, and publish nothing,” needs to be something the platform can enforce at the API. A git branch rule cannot say that, and neither can a vector database API key. A governed CMS can, through roles, staged releases, approval steps and a record of who changed what.
Where the CMS should stop
I should be honest about the boundary, because the hype will happily blow past it. The CMS is the right home for governing content and the permissions agents work under. It is not the right home for orchestrating your whole operation. Most of the coordination in content work happens upstream, in planning and review tools, long before anything lands in the CMS. Push all of that into the content platform and you have quietly rebuilt the monolith headless was meant to kill. Govern content and access in the CMS. Let the workflow orchestration live closer to where the work actually happens.
How to proceed
If you want to make your content safe for agents to operate on, I would start small and concrete:
Audit the model first: Are your prices, claims and policies typed fields with real relationships, or are they buried in rich text and PDFs? What an agent cannot parse, it cannot govern.
Hunt down the copies: Every fact living in more than one place is a future inconsistency. Move them to references.
Scope permissions at the API: Decide what agents may read, draft and publish, and enforce it in the platform, not in a prompt.
Run the test: Point an agent at your content and watch where it flies and where it stalls. That gap is your governance backlog.
Get this right and it pays off twice. You are less exposed when an agent slips, and you end up with content an agent can quote accurately and consistently wherever it turns up, which is increasingly how customers find you. That last part is measurable now. When Google shows an AI summary, people click through to a website in just 8% of searches, against 15% without one. The answer itself is becoming the destination, and being the source it quotes correctly is what keeps you on the map.
So the question I care about is not whether the CMS is dead. It is which platform gives your people and your agents a place they can both work safely, and who does the modelling that makes it real. My honest read: the platforms that separated content from presentation years ago start this race a long way ahead.
Get a second pair of eyes
I am still working out where the edges of this sit, especially the line between what a CMS should govern and what belongs elsewhere in the stack. If you are experimenting with agents against your own content, I would like to hear where it worked and where it broke for you.
Those failure points tell us more about the right architecture than any vendor deck does. Pointing an agent at a real content model and mapping where it stalls is something we do with teams, so if you want a second pair of eyes on yours, I am glad to get into it.
Book a call with us