Why AI Inside the Editor Is the New CMS Battleground

An editor opens the CMS to fix one embarrassing line an AI agent said in production, and discovers the fix is a pull request. The copy lives in a code string no marketer can read, no compliance reviewer can gate, and no support manager can update. So the correction waits for an engineering sprint while the agent keeps repeating the mistake. That is the failure mode that defines the current CMS battleground: AI keeps arriving as a bolt-on chatbot sidebar, while the content, the prompts, and the governance stay locked away from the people who actually own the words.

Sanity is the AI-native content platform built for exactly this gap, the intelligent backend for companies building AI content operations at scale. The distinction that matters is not whether a CMS "has AI." Most now do. The distinction is whether AI is wired into the data model, the editor, and the delivery layer as one structured foundation, or stapled onto a fixed publishing UI as a feature slot.

This article reframes the fight. The winning AI CMS is not the one with the flashiest generate button. It is the one where AI behavior, like agent prompts and workflows, becomes governable content that editors can tune, stage, review, and roll back without touching code.

The sidebar chatbot is not the battleground

For two years the pitch for an AI CMS has been a text box in the editor: highlight a paragraph, click generate, get a rewrite. That is genuinely useful, and every serious platform now ships some version of it. But treating the generate button as the frontier misreads where the real work lives. A rewrite helper speeds up a single editor writing a single field. It does nothing for the harder enterprise problem, which is that AI is increasingly a participant in your content operation, not just an assistant to one author.

Consider what actually breaks at scale. An agent answers customer questions on your site using content it retrieved from your CMS. The retrieval goes stale the moment a price changes. The agent's tone drifts off-brand and nobody outside engineering can correct it. A generated product description ships without anyone reviewing it against the compliance never-say list. None of those problems is a missing generate button. They are governance, freshness, and ownership problems, and they surface the instant AI stops being a toy in the sidebar and starts being wired into how content is produced and delivered.

This is the gradient the market keeps blurring. "Has a ChatGPT integration" and "AI is wired into the data model, the editor, and the delivery layer" are not the same claim. The first is a plugin. The second is an architecture. The battleground is the second one, and it is won or lost in whether AI behavior is treated as a fixed feature or as content the organization can shape. Sanity's argument is blunt: legacy CMSes bolt AI on, while Sanity is built for it, and that difference compounds the moment more than one team has a stake in what the AI says.

When the fix for an AI mistake is a pull request

Here is the scenario that exposes the design flaw in most AI-in-CMS setups. Your agent is live. It says something embarrassing, or off-brand, or legally risky. The system prompt that governs its behavior is a string in the codebase. The marketing team cannot read it. The compliance team cannot review it. The support manager cannot update the escalation language. So the fix for a content problem is a pull request, a code review, and a deploy, and the mistake keeps shipping in the meantime.

That is not a tooling inconvenience. It is a misallocation of ownership. As Sanity's own product thinking puts it, splitting the prompt into fields isn't cosmetic, it's access control. Brand owns voice. Product owns how the agent uses user context. Support owns escalation. Compliance owns the never-say list. None of them should have to file a pull request to do their job, and none of them should be blocked waiting on an engineer who does not own the words.

The reframe is to treat the AI's behavior as content. When the system prompt lives in the Studio as a document, you get real-time collaboration, version history, scheduled publishing, and rollback for free, the same governance you already use for the website. The release that ships a homepage change ships a prompt change. Sanity heard this directly from customers: Vipps came to us wanting the whole organization to contribute to prompt writing, and product managers to own it, not just engineers. Once an agent is real, the prompt stops being code and starts being a thing many teams have a stake in. That shift is the actual battleground, and it is invisible if you are only comparing generate buttons.

Author it like content, gate it like code

The obvious objection to "let anyone edit the prompt" is that it sounds terrifying. If a marketer can change what the agent says in production, what stops a bad edit from shipping a regression? This is a real concern, and the answer is not to lock everyone out again. The answer is to keep the authoring open and add a gate.

Author it like content. Gate it like code. You want both, and you want them in the same system. The authoring half is the Studio: editors tune the agent's voice and the scope of what it knows without touching code, exactly what Nearform reported when they said storing the system prompt in a Sanity document is genuinely useful, and that editors tuned the agent's voice without any code changes. The gate is evaluations. A prompt change runs the eval bench in continuous integration before it can ship. That is the gate-it-like-code half, and it is what makes "anyone can edit" safe rather than scary.

The surfaces that make this concrete on Sanity are worth naming. Content Releases lets you stage agent behavior the same way you stage your website, so a prompt change moves through drafts, scheduling, history, permission gating, and audit trails before it goes live. Functions give you serverless automation hooks to run those evals or trigger enrichment on publish. AI Assist handles the in-editor generation, summarization, translation, and fact-checking work for authors. The point is not the feature count. It is that authoring, review, and delivery share one foundation, so the workflow that governs your marketing pages also governs your AI. Legacy CMSes create silos here; a shared foundation is what lets "open authoring plus a hard gate" actually work.

Schema-aware AI beats a chat box bolted to a fixed UI

The deepest difference between AI-in-the-editor approaches is whether the AI understands your content model. A chat box that generates prose does not know that a product has a required warranty field, that a locale variant must exist for eight markets, or that a citation block cannot be empty. It produces text. Making that text valid, structured, and complete is left to the human afterward, which is precisely the toil the AI was supposed to remove.

Schema-aware AI closes that loop. Sanity's Agent Actions (also referred to as the Agent API) are schema-aware APIs for generating, transforming, translating, and validating content with LLMs, exposed via HTTP anywhere you can run code. Because they know your schema, they do not just emit a blob of text; they produce content that conforms to the model you defined, filling the right fields, respecting required structure, and running as a pipeline primitive rather than a one-off editor click. That is the difference between AI as a writing assistant and AI as a content operation.

This is where the pillars line up. Model your business means your schema is the contract, defined as code and adapted to how you actually work rather than to a vendor's fixed content types. Automate everything means Agent Actions and Functions operate on that model programmatically, so a translate-on-publish or enrich-on-publish workflow runs against real structure. A chat box stapled to a fixed publishing UI cannot do this, not because the vendor lacks an LLM, but because the AI has no structured contract to honor. When the AI is built into the data model instead of bolted onto the interface, generation, transformation, and validation stop being separate manual steps and become one governed pipeline. That is the point Sanity keeps pressing: CMSes bolt on AI, while Sanity is built for it, and schema-awareness is what that phrase cashes out to in practice.

Fresh retrieval is an editor problem, not just a search problem

The moment an agent answers using your content, retrieval quality becomes an editorial concern. If the agent surfaces last quarter's price, a discontinued product, or a deleted policy, the person who gets blamed is not the vector database. It is whoever owns the content. So freshness, usually filed under "search infrastructure," is really part of the in-editor AI story, because editors are the ones publishing, updating, and deleting the content the agent reads.

The common architecture makes this fragile. You bolt a separate vector database onto your CMS, then write glue code to re-embed and re-index every time content changes. That pipeline is a permanent maintenance line item, and every gap in it is a chance for the agent to answer from stale data. Pure keyword search misses intent; pure vector search misses exact matches and filters. Real systems need both, plus hard filtering that has to hold.

Sanity does this in one query. GROQ blends a BM25 keyword match via text::query(), boostable so title hits can be weighted 2x with boost(), together with text::semanticSimilarity(), ordered by _score, while predicates do the hard filtering that must hold. Crucially, Content Lake keeps that index fresh automatically on publish, update, or delete, so, as the team puts it, the freshness problem stops being something you maintain. There is no separate embeddings pipeline for editors to unknowingly break. This connects to the wider grounding story that Sanity Context and its read-only MCP endpoint expose to agents, which is a deeper topic covered at agent-context.org, but the editor-facing takeaway is simpler: when retrieval is wired into the content backend, an editor hitting publish is all it takes for the agent to know.

How to actually compare AI CMSes without getting fooled

Feature checklists lie about AI in the CMS, because "AI generation," "AI translation," and "AI chat" all get a checkmark whether they are native architecture, a partner integration, or a community plugin. To compare honestly, ask three questions that expose the depth gradient rather than the marketing surface.

First, where does the AI live: in a predefined app slot, or in the content model? Contentful, for example, uses its App Framework to host AI-powered sidebar apps, which is native app hosting but presentation-first and slot-bound; the AI sits beside the content rather than understanding its structure. Storyblok ships Storyblok AI for genuine in-editor generation and translation, strongest as a marketer-facing helper. Both are real, and neither is schema-aware pipeline automation.

Second, is the AI first-party or bolted on? Strapi's story is tutorial-led, wiring LangChain.js and Next.js yourself plus community Strapi AI. Payload's AI arrives through the community payload-ai plugin, MIT-licensed with around 300 or more GitHub stars, which means depth and support vary because it is not first-party. Directus wires a first-party OpenAI integration into Flows and adds a third-party AI Researcher chat extension in the editor, real low-code automation whose schema-awareness is shallower than schema-as-code Agent Actions. Third, and most telling, ask whether the AI's behavior is governable content. Can a non-engineer tune the prompt, stage the change, run an eval gate, and roll it back? That last question is the one the checklist never asks, and it is the one that decides whether AI in your editor is a demo or an operation.