Most "AI-ready CMS" checklists ask whether a vendor has shipped an AI feature: a writing assistant, an auto-tagger, an alt-text generator. As if a CMS becomes AI-ready the moment it ships a button that calls OpenAI. That framing confuses using AI to generate content with building a content platform that AI can operate. Those are different architectures, and only one of them survives contact with what's actually coming.
Here's the useful question instead: when an engineer on your team opens Cursor tomorrow morning and tells it to add a new content model, wire up a lifecycle hook, and extend the admin UI, can your CMS be driven that way, or does the agent have to guess? That's the real axis of "AI-ready." Everything else is marketing.
This piece lays out how to evaluate a headless CMS against that axis.
1. The two meanings of "AI-ready," and why the industry keeps conflating them
There are two distinct capabilities people describe with the same phrase.
The first is AI operating on content: an agent reads entries, drafts new ones, tags assets, translates copy, answers questions by retrieving from your content lake. This is table stakes now. Contentful, Sanity, Strapi, Storyblok, Hygraph, Payload, Directus, DatoCMS, Prismic, Agility, Kontent.ai, AEM, Sitecore, Optimizely, dotCMS, Umbraco, Webflow: all of them have shipped an MCP server in the last twelve months, and most of those servers read and write content. If this is your bar, you don't have a shortlist problem. You have a dozen vendors who clear it.
The second is AI operating on the platform itself: an agent that doesn't just edit a blog post, but defines the content model, generates the GraphQL resolvers, writes the lifecycle event handler, extends the admin UI, and ships infrastructure changes. This is what we at Webiny mean by "AI-programmable," and it's a materially different problem. It requires that the platform's own extension surface, its APIs, its project structure, its conventions, be legible to a coding agent, not just to a human developer reading docs on a second monitor.
A CMS that writes your blog posts is table stakes. The target is a CMS your team can rebuild to fit the business in an afternoon.
If you're evaluating platforms, decide which of these two you actually need before you look at a single feature matrix. Most enterprises need both. Many only realize it after they've picked a vendor optimized for the first and discovered the second is where the cost lives.
2. What to check when AI will operate on your content
If your use case is retrieval, generation, tagging, chat, or anything else where a model reads from or writes to the content layer, here's what matters, roughly in the order I'd check it.
API surface, not just API presence. Every headless CMS has an API. The question is whether that API exposes everything an agent needs, content, assets, taxonomies, workflows, permissions, versioning, through one coherent interface. GraphQL is better suited here than REST because it's self-describing: an agent can introspect the schema and discover what's available. Webiny exposes a GraphQL API across the Headless CMS, File Manager, and Tenant Manager, and the schema reflects your content models directly. Strapi, Sanity (via GROQ and GraphQL), Payload, and Hygraph are similarly structured. Platforms that only offer REST, or that gate the richer surface behind enterprise tiers, cost you later.
Where the data actually lives. If you plan to fine-tune a model on proprietary content, or run retrieval over it inside your own VPC, you need the content and the model to sit in the same trust boundary. SaaS CMSs, Contentful, Sanity, Storyblok, Hygraph, Contentstack, keep the backend on their infrastructure. You can pull content out via API, but you cannot put your inference next to the data. Self-hosted platforms, Webiny on AWS, Strapi, Payload, Directus, Drupal, let you co-locate. For regulated industries this isn't a preference, it's a procurement requirement, and Salesforce's acquisition of Contentful has made the data-sovereignty conversation sharper for anyone running sensitive content on a SaaS backend.
MCP server, and specifically what it does. The protocol has standardized in a year. The useful question now is: what does this vendor's MCP server expose? Sanity's MCP has 40+ tools covering content operations. Strapi's went GA in June and manages content directly. Webiny's MCP, deliberately, does something different: it exposes the platform's extension surface to coding agents, not its content. If you need an agent that edits entries, Webiny's MCP is not the one you want today. That's the honest answer. If you need an agent that builds the CMS itself, keep reading.
Governance that AI inherits. An AI agent writing to your CMS is a user. It needs an identity, a role, a permission scope, an audit trail. If the platform's role-based access control, versioning, approval workflows, and audit logs don't apply uniformly to API traffic, you've just given a stochastic process unaudited write access to your production content. Webiny's publishing workflows, audit logs (Enterprise), and roles apply to API calls the same as they do to editor sessions. Check this on every platform you evaluate. The answer is often worse than you'd expect.
3. What to check when AI will operate on the platform
This is the harder evaluation, and it's where most vendor pages give you nothing to work with.
Can an agent define a content model from a prompt, end to end? Not "can it generate a schema in a chat window." Can it create the model, register it with the API layer, apply it to the running system, and have the admin UI reflect it, without a human stitching the pieces together? Webiny's answer is that content models can be defined in code, through the API, or in the UI, and the local MCP server (@webiny/mcp) gives coding agents like Claude Code, Cursor, and Copilot structured knowledge of the APIs and extension patterns needed to do this. The agent isn't guessing from scraped docs; it has list_webiny_skills and get_webiny_skill as structured tools.
Project structure legibility. An agent working on your CMS has to understand where things go. If every extension lives in a different plugin folder with its own conventions, if admin customizations are coupled to a specific build config, if lifecycle hooks are registered through a mechanism that isn't documented in a way an agent can retrieve, the agent fails silently, or worse, succeeds in ways that break on upgrade. Webiny v6 collapsed the monorepo into a single-package project structure specifically for this reason: fewer places where an agent can get lost.
Extension surface, not just content API. The CMS has to expose its own composition, lifecycle events, dependency injection, infrastructure, admin UI, through interfaces an agent can actually use. This is where most "AI-friendly" CMSs reveal they meant something smaller than they said.
Version-tagged knowledge. This one is subtle and matters. If an agent is working against docs that drift from the installed version, it will hallucinate confidently. Webiny's docs MCP serves version-aware documentation; the local MCP ships skills tied to the version you've installed. Ask every vendor how their agent-facing knowledge is versioned. If the answer is "we point agents at our public docs site," that's not an answer.
I'll concede the obvious weakness here: most of the AI-on-content work, the parts that marketing teams actually feel today, is further along on other platforms than it is on Webiny. Sanity's Content Agent is GA. Strapi's content MCP is GA. Webiny's in-product AI is an early preview, and we say so. If what you need in the next quarter is an editor-facing AI assistant that drafts and translates, buy that from someone shipping it today. If what you need is a platform your engineers can rebuild with agents over the next three years, the evaluation flips.
4. The honest shortlist criteria
Strip the brochure language off and you're left with five questions:
- Does the backend run where my data has to live?
- Does the API expose everything an agent needs, through one coherent schema?
- Is there an MCP server, and is it the kind of MCP server I need: content operations, platform extension, or both?
- Do governance, permissions, and audit apply uniformly to agent traffic?
- Can my engineers extend this platform with an agent, or only around one?
Any CMS worth your shortlist should answer four of those five with a straight yes. If a vendor needs a slide deck to answer any of them, that's the answer.
Frequently asked questions
What should I look for in a CMS if I plan to use AI?
Start with where your data needs to live, because that constrains everything else. Then look at the API: GraphQL with full schema introspection is substantially easier for agents to work against than a patchwork of REST endpoints. Check whether the vendor ships an MCP server and read its tool list carefully. "Has MCP" means very little now; what the server actually exposes means everything. Finally, confirm that your access control, versioning, and audit logging apply to API traffic the same way they apply to editor sessions, because an AI agent is a user with a very fast typing speed.
What's the difference between AI-powered and AI-programmable?
AI-powered usually means the vendor added AI features to the product: a writing assistant, auto-tagging, a translation helper. AI-programmable means developers use AI to build and extend the platform itself: generating content models, writing lifecycle logic, extending the admin UI, shipping infrastructure. Most CMSs are moving toward the first. Webiny is built around the second. Both matter; they're different problems solved by different architectures.
Can AI agents build and configure content models directly in a headless CMS?
In a few platforms, yes. The requirement is that the CMS exposes its content model definitions through an API an agent can call, and ideally through an MCP server that gives the agent structured knowledge of how models relate to resolvers, UI, and lifecycle hooks. Webiny does this via @webiny/mcp, which lets Claude Code, Cursor, Copilot, and similar tools work against the actual installed version of the platform rather than scraped documentation. Several other vendors are moving in this direction, but the state of the art is uneven. Check what the agent can actually do before you believe the marketing.
Is a self-hosted CMS necessary for AI integration?
Not for every use case. If you're using AI to draft marketing copy or generate alt text, a SaaS CMS is fine. If you're running retrieval or inference over proprietary content, if you're in a regulated industry, or if your security team has strong views about where training data lives, self-hosting stops being optional. Webiny runs serverless in your own AWS account, which keeps content and inference inside the same trust boundary; Strapi, Payload, Directus, and others offer self-hosting on different stacks. Decide this based on your data classification, not on preference.
