When AI agents work in your CMS: rules, content model, ownership

In some teams, AI agents already read, edit and translate content directly in the CMS. According to Sanity, whether that becomes routine or a pilot that goes nowhere depends on three gaps that technology alone does not close: written rules, a clean content model and a person who connects technology and editorial. They are more closely linked than they first appear.

The occasion is Sanity's AI Content Operations Report. Sanity is the CMS we build websites with. For the report, Sanity analysed 1.46 million calls made by AI agents through its MCP server across 12,500 organisations (September 2025 to April 2026) and interviewed twelve content leaders. We read the report at a distance: what does it show, what doesn't it, and what follows for a content team?

One caveat up front: this is vendor data from teams that had already connected Sanity to AI tools, and the report also serves Sanity as marketing, since the web version asks for an email address. It calls the teams early adopters itself, not a market cross-section. The figures work as orientation, not as market figures.

What Sanity measured and asked

A few do most of it. The top 8% of users generate 68% of the activity, using the same tools as everyone else. According to the report, the difference is organisational: one person, recurring workflows, a practice that builds up. The highest intensity per user comes from a content marketer working in a chat tool, not from a developer on the command line.

Everyday work dominates. 91% of calls are everyday tasks such as looking things up, checking, editing and publishing. The remaining 9% are projects like migration, SEO sprints or translation, and according to the report they replace weeks of work. Frequency alone, in other words, says little about value.

And rules are missing: 11 of 12 interviewed enterprise teams had no formal AI policy.

Three hurdles that belong together

The report names three gaps that technology alone does not close. We read them as a chain: the rules say what agents may do. The content model decides what they can do safely. And one person holds both together.

Rules. Instead of a six-month compliance project, Sanity recommends a one-pager with three questions: What data may go to AI tools? Who reviews AI-generated content? Which content types stay human-only? We add a fourth: who may publish? Technically this can be safeguarded. According to the documentation, Sanity's MCP server saves changes to documents in a draft or a release version, not in the published document. Publishing is a separate step: drafts can be published with a tool, whereas releases cannot be published through the MCP server, only in the Studio or via the HTTP API. Whether an agent may publish drafts depends on the role of its access and on the tools its AI client is allowed to use, and it should be a deliberate decision.

Content model. Agents read before they write. According to the report, what they find is often a structure built for people clicking through a CMS. According to the interviews, teams in sustained operation used that first read as a diagnostic and cleaned up before scaling. That is directional, but not statistically established. What a model needs for this is, in our view, much the same in most systems: clear types and fields, references instead of copies, validation rules, a draft status and bundled publishing. In Sanity, validation rules in the Studio and Content Releases cover part of this: errors show up before publishing, and changes can be bundled, previewed and traced.

Ownership. According to the report, in the teams interviewed one person was already doing the wiring, often before anyone had allowed it, and not always a developer. Sanity calls the role “AI content ops engineer”, a mix of engineering and content strategy. The report advises hiring toward this role or freeing up the person who already does it. We think the second route is the better start: name the person who already mediates between technology and editorial, and give them the mandate. As we wrote in Why digital projects fail, responsibility without a name remains an assumption.

The connection: facts need an owner

Sanity recently described what happens when everyone in a company builds an agent. The internal hackathon produced many agents, and the argument is: the number of agents is not the problem, scattered facts are, meaning policies pasted into prompts and knowledge that disappears as soon as someone deletes the agent. Sanity also implements its guardrails technically there, for example with validation in the Studio and human review of every new tool, and not with a policy alone.

The recipe Sanity derives from this is plain: keep facts in one place, let each team own its facts and record where they come from and who keeps them current. Of 61 agents entered at the hackathon, 42 worked fully or partly according to Sanity, and the failures were mostly down to missing access to a source, less to the prompts. Access and context first, more agents second. That Sanity uses its own Knowledge Bases product for this (currently in beta) is the vendor's perspective. In our assessment, the principle can be applied without that product too.

Outwardly it is the same task. The facts that make agents reliable can also make your website easier for AI tools to read: company name, services, team and descriptions, maintained once and used everywhere. How that turns into structured data, llms.txt and a sitemap is described in Getting quoted by AI. What it means for findability and visibility is covered on our page about SEO and AI visibility.

What the report doesn't show

The data comes from the vendor and from a group that was early. The report names some limits itself: the telemetry comes only from Sanity users with a configured MCP server, part of the growth comes from wider distribution rather than deeper use, and agents reading before every write is a technical necessity that says little about how teams behave. The why, organisation rather than technology, comes from twelve interviews that, by the report's own account, are not representative.

On top of that, individual figures can't be recomputed cleanly: the 8% stands in the report for two different groups, once for the most active users and once for the users in sustained operation. We therefore quote only the core figures. In practice the report works as a list of questions, not as a benchmark.

Conclusion

We read rules, content model and ownership as three sides of the same thing: it has to be clear what applies, who maintains it and what an agent may do with it. The Sanity report offers a useful list of questions, but no market figures. And the order that makes agents safer in the CMS can also make your website easier for AI tools to read.

Whether your content model is ready is something a read-through shows. If you want to place this for your team, talk to us about consulting and advisory.