We're living in an interesting time. That deserves its own conversation, but today I'm focused on delivering maximum signal per unit of time for anyone whose work intersects with headless CMS.
Over the last five years, I've been involved in 30+ projects in this space — building, advising, reviewing. Beyond that, I regularly audit other teams' projects already running in production. This text is written for those familiar with the domain: specific products and mechanics named, no foundational explanations. For those unfamiliar, well, we now have LLMs.
The main thesis of this text is simple. The problems with headless CMS are old, documented, and largely unchanged. What's new is the alternative. Start with an honest map of the market. Most content sites never reach for a headless CMS at all — they run on WordPress, on a site builder, or now on something like Lovable. Plenty of them never needed a CMS in the first place. The headless world is the slice above that: teams whose site outgrew a builder's ceiling and who got pushed onto Contentful, Sanity, or Storyblok because that looked like the only serious option left. Inside that slice, a minority genuinely need what headless offers, and for them it should stay. The rest inherited an architecture built for someone else's scenario — and for the first time, there's a third option between the no-code ceiling and full headless complexity. The numbers below carry the argument; I'll keep my thumb off the scale.
The headless CMS concept appeared earlier than most think. Directus was created in 2004 — by founder Ben Haynes's own account, long before the term 'headless CMS' even existed. The term itself only entered circulation around 2014. But the essence was already clear: separate the content editing layer from the rendering layer.
The idea is correct. Monolithic CMS platforms like WordPress held us hostage to their architecture. Templates, plugins, themes, all fused together. Headless promised stack freedom: pick any frontend, render where you want, scale how you need.
When Contentful arrived in 2013, then Sanity and Storyblok in 2017, they landed in the right place at the right time. The agency market was migrating to Next.js, companies wanted to escape WordPress, and here was a ready solution with a clean dashboard and an API. It sold well. The headless CMS market is estimated at roughly $817M in 2024 and projected to reach $7.1B by 2035, a 22.6% CAGR according to Future Market Insights.
For its time, it worked.
The standard sales deck for any headless CMS between 2018 and 2022 looked roughly the same. Omnichannel, developer freedom, scalability, SEO boost, performance, and editors who would never bother developers again.
Let's go through this honestly.
Omnichannel. This is one of the central marketing claims of the entire industry. But if you look at actual deployments, the client cases of Contentful, Sanity, Storyblok, the overwhelming majority are marketing sites, landing pages, and corporate resources. One main channel, one frontend. True omnichannel, where the same content simultaneously lives on the web, in a native app, on IoT devices, and in voice interfaces, is a project, not an architectural property of the CMS. Everyone pays for it. A few actually use it.
SEO and performance. A headless CMS does not directly affect these metrics at all. The result is entirely determined by who built the implementation and how. Which framework, which rendering strategy (
Editors without developers. Contentful looks like a form builder with nested entries. To make sense of it, an editor needs days at minimum, and only if the project was built well. Sanity Studio can be customized beyond recognition, but who will customize it? The developer. Storyblok with its Visual Editor came closest to a real no-code experience, but even there the price is paid in specific constraints on data architecture.
Along with the headless CMS hype came an entire industry of agencies proudly calling themselves "best Sanity agency" or "certified Contentful partner." Some of them are actually competent. Most are not.
When I audit projects built by others, and I do this regularly, the picture varies. The hardest part of these conversations is explaining to a team that invested $50K to $100K that they were given a bad project. Especially when they themselves can't assess the scale of the problem, because they don't know what it should look like.
This isn't the exception. This is the pattern.
The worst part is that it's not only architecture that suffers. If an agency doesn't understand technical SEO, and most don't, a migration from WordPress to headless can destroy organic traffic you built over years. Not because headless is bad, but because redirects are done wrong, canonical tags are placed sloppily, structured data gets lost. The client won't see this at acceptance. And I'm not even talking about AEO, which at its current stage of development sits roughly where early Google bots were when they couldn't parse client-side JS.
Technically, you can always migrate off a headless CMS. Export JSON, move the data. No one is holding you.
In practice, migration means rebuilding the project from scratch. Because your code was written against the Contentful SDK, your TypeScript types were generated from Contentful schemas, your editors were trained on the Contentful UI, your pipelines hooked into Contentful webhooks.
Recognition arrives at the worst moment. Concrete examples of what that moment looks like in practice.
Contentful, content types. One of the most frequently discussed ceilings on Reddit:
This isn't an edge case. 48 content types is a real ceiling for a non-trivial marketing site.
Contentful, locales. The free plan gives you two locales. Lite ($300/month) gives three. You need a fourth language? Welcome to Premium, where the price is custom and determined in a call with sales. According to Vendr, Contentful contracts average in the mid-five figures, and enterprise deals climb into six figures. Large multi-locale deployments go significantly higher.
Storyblok, the 2025 pricing rework. In April 2025, Storyblok rolled out a pricing restructure with a 60-day grace period. A G2 review from one client:
Sanity, per-seat math. A typical Growth plan for 50 users at $15/seat with the needed add-ons (SAML SSO $1,399/mo, Dedicated Support $799/mo, an additional dataset $999/mo) comes out to $3,947/month, or $47,364/year. And that's before Enterprise. Meanwhile, one viral article in production driving bot traffic to an unprotected Sanity endpoint can produce a surprise bill, a known case from the developer community.
When it became clear that LLMs are serious, almost every headless CMS pushed toward AI. Some even began calling themselves AI-native.
Let's look under the hood.
Sanity launched an official remote MCP server at
Contentful shipped an official MCP server — open source, with a hosted beta — alongside "AI Actions," a feature with a GUI in Premium plans that lets you generate and transform content. Sanity, in its own documentation, characterizes the competition more dismissively:
Storyblok has an AI Suite on a credit model (25K credits on Starter, scaling to 1M on higher plans). Content generation, visual editing assistance. In practice, an LLM assistant inside an existing editor.
In all three cases, the LLM is an additive feature on top of an existing architecture. Content models, editorial workflows, the data storage schema, all remain unchanged. An AI layer that knows how to work with this was added on. This is not AI-native architecture. This is AI-enabled legacy architecture. And I'm not even mentioning that you can't bring your own agents, your own models. Once again, everything has been decided for you.
It's worth restating the thesis. An AI layer bolted onto an editor built for humans is not an architecture built for agents. A minority of teams on headless are genuinely well served by it. The rest pay for infrastructure designed around someone else's problem, and they pay more every year.
In December 2025, Lee Robinson, for five years VP of Product at Vercel and now at Cursor, published a post with a telling title: "Coding Agents & Complexity Budgets." In it, he describes migrating cursor.com away from a headless CMS, back to Markdown and code. In three days. Spending $260 on tokens. With agents.
Concrete numbers. 322,000 lines of code deleted, 43,000 added. Build speed doubled. CDN costs dropped. And most importantly, the team got back the ability to work with the site through agents directly, instead of through a CMS abstraction on top.
His phrasing is precise:
Sanity responded with a public post called "You should never build a CMS," and that title itself is telling. They're right that for a team of ~50 developers who all write code, markdown files in the repo work. They're also right that the complexity of content operations returns over time. Scheduling, reverts, previews, cross-page references. But their response doesn't address the main question. Why do existing CMSes integrate so poorly with agents that reasonable people prefer to migrate to markdown?
Sam Seely formulated it most concisely on Twitter:
Because the alternatives were worse. Or used to be.
WordPress in 2025 is technical debt, security issues, and PHP-era architecture. Builder, Webflow, and similar tools are no-code with a ceiling you hit very fast on any non-trivial project. Against this backdrop, headless CMS remained a strong choice. If you got lucky with your implementation partner, you got what you were promised. Not because Contentful or Sanity are good in themselves, but because the partner did everything right.
That's an important distinction.
Payload v3, released in November 2024, was a good signal in the right direction. MIT license, self-hosted, architecturally embedded directly into a Next.js app, into the
For symmetry. Directus, one of the oldest players in the category, went the opposite direction. A few years ago it switched from GPLv3 to Business Source License (BSL) 1.1, with a carve-out for organizations with annual revenue or funding below $5M. This is a telling pattern. "Open" players are gradually closing.
So yes, headless CMS remains a working choice. But for the first time in many years, alternatives have appeared that put the very necessity of this complexity in question.
When Anthropic launched Claude Design in April 2026, it wasn't trying to do Figma better. VentureBeat described it precisely: Claude Design is "a standalone product accessible to founders, product managers, and marketers who have never opened Figma." Expanding the user base of design to non-designers, that's the real competitive pressure, not feature parity with professional tools.
Anthropic's emphasis: "giving designers room to explore widely and everyone else a way to produce visual work." The key phrase is "everyone else." The target is not designers. The target is everyone who used to need a designer.
The market reaction speaks for itself. Figma's stock dropped ~7% on launch day, even though Anthropic officially called Claude Design a complementary product.
This is the same mechanism that should now happen to content operations.
Not because headless CMS is bad. But because LLMs change who produces content and how. Content is increasingly generated, transformed, localized, and validated with the participation of agents. An architecture where the LLM is a third-party client to an API designed for a human editor cannot be effective in this world by definition. Not because it was built poorly, but because it was designed for a different task.
For the last six months, I and a small team have been building agntcms. It's an attempt to answer the same shift Claude Design captured in design.
Technical boundaries for context. Open source, MIT license. A framework, not a service. Next.js under the hood. Claude Code as the first agent runtime, with other agents to follow as their tooling matures. Not headless, not monolithic. A third form, for which a settled term doesn't yet exist.
What this means in practice. A marketer, through their own agent, adds a page, restructures a block, localizes content. Not through a developer ticket. Not through a visual editor with a ceiling. Through conversation. A founder, through their own agent, runs a content migration or adjusts SEO. The developer is not pulled in for every button change, because for most requests they don't need to be.
This is the same logic Anthropic applied with Claude Design to Figma. Design used to be a profession with a barrier to entry. Now "everyone else" can produce visual work. Content operations used to require either a developer or an editor trained to navigate a dashboard. Now that same "everyone else" can work with content through their own agent.
Not for everyone. agntcms isn't for editorial teams of 50 with five-tier approval workflows. Not for omnichannel scenarios with native apps and smart-watches. Not for teams that don't yet work with agents. Those tasks stay with headless — the minority of cases it was actually designed for.
Let me close where I started. Headless CMS stopped being a safe default the moment a site outgrows a builder. The teams who truly need its complexity are a minority, and it should stay theirs. The rest — marketing sites, landing pages, content portals, and corporate resources pushed past the no-code ceiling — overpay for someone else's scenario. And for the first time, they have an alternative that doesn't reduce to a choice between WordPress and Sanity.
agntcms is open on GitHub under MIT license. It isn't a product we're selling, and it isn't a SaaS we're trying to log you into. It is an attempt to put the position I outlined across these pages into code. The product is the statement I'm making in this essay.
If the diagnosis matched your experience, there's a concrete way to participate. Issues, PRs, discussions in the repository. Every commit, every open task, every comment moves the industry closer to the moment when teams can pick the architecture that actually fits them, instead of defaulting into one that doesn't.
github.com/agntcms
P.S. — Anthropic, plz collab 🤝
Market data: Future Market Insights (2024). Pricing data: Vendr, costbench.com, G2, Webstacks (2025-2026). Cursor migration: Lee Robinson, leerob.com/agents (December 2025). Sanity response: sanity.io/blog/you-should-never-build-a-cms. Payload data: payloadcms.com, GitHub (February 2026). Claude Design: Anthropic Labs, VentureBeat, DesignRush (April 2026).
Over the last five years, I've been involved in 30+ projects in this space — building, advising, reviewing. Beyond that, I regularly audit other teams' projects already running in production. This text is written for those familiar with the domain: specific products and mechanics named, no foundational explanations. For those unfamiliar, well, we now have LLMs.
The main thesis of this text is simple. The problems with headless CMS are old, documented, and largely unchanged. What's new is the alternative. Start with an honest map of the market. Most content sites never reach for a headless CMS at all — they run on WordPress, on a site builder, or now on something like Lovable. Plenty of them never needed a CMS in the first place. The headless world is the slice above that: teams whose site outgrew a builder's ceiling and who got pushed onto Contentful, Sanity, or Storyblok because that looked like the only serious option left. Inside that slice, a minority genuinely need what headless offers, and for them it should stay. The rest inherited an architecture built for someone else's scenario — and for the first time, there's a third option between the no-code ceiling and full headless complexity. The numbers below carry the argument; I'll keep my thumb off the scale.
Where this all came from
The headless CMS concept appeared earlier than most think. Directus was created in 2004 — by founder Ben Haynes's own account, long before the term 'headless CMS' even existed. The term itself only entered circulation around 2014. But the essence was already clear: separate the content editing layer from the rendering layer.
The idea is correct. Monolithic CMS platforms like WordPress held us hostage to their architecture. Templates, plugins, themes, all fused together. Headless promised stack freedom: pick any frontend, render where you want, scale how you need.
When Contentful arrived in 2013, then Sanity and Storyblok in 2017, they landed in the right place at the right time. The agency market was migrating to Next.js, companies wanted to escape WordPress, and here was a ready solution with a clean dashboard and an API. It sold well. The headless CMS market is estimated at roughly $817M in 2024 and projected to reach $7.1B by 2035, a 22.6% CAGR according to Future Market Insights.
For its time, it worked.
What was promised, and what was actually delivered
The standard sales deck for any headless CMS between 2018 and 2022 looked roughly the same. Omnichannel, developer freedom, scalability, SEO boost, performance, and editors who would never bother developers again.
Let's go through this honestly.
Omnichannel. This is one of the central marketing claims of the entire industry. But if you look at actual deployments, the client cases of Contentful, Sanity, Storyblok, the overwhelming majority are marketing sites, landing pages, and corporate resources. One main channel, one frontend. True omnichannel, where the same content simultaneously lives on the web, in a native app, on IoT devices, and in voice interfaces, is a project, not an architectural property of the CMS. Everyone pays for it. A few actually use it.
SEO and performance. A headless CMS does not directly affect these metrics at all. The result is entirely determined by who built the implementation and how. Which framework, which rendering strategy (
SSG, SSR, ISR), how the CDN is configured, how images are handled. A traditional WordPress site with a CDN and static cache can outrun a poorly built headless project. This is obvious to all developers, but not to all clients. Vendors don't warn about it.Editors without developers. Contentful looks like a form builder with nested entries. To make sense of it, an editor needs days at minimum, and only if the project was built well. Sanity Studio can be customized beyond recognition, but who will customize it? The developer. Storyblok with its Visual Editor came closest to a real no-code experience, but even there the price is paid in specific constraints on data architecture.
The partner market and the reality of audits
Along with the headless CMS hype came an entire industry of agencies proudly calling themselves "best Sanity agency" or "certified Contentful partner." Some of them are actually competent. Most are not.
When I audit projects built by others, and I do this regularly, the picture varies. The hardest part of these conversations is explaining to a team that invested $50K to $100K that they were given a bad project. Especially when they themselves can't assess the scale of the problem, because they don't know what it should look like.
This isn't the exception. This is the pattern.
The worst part is that it's not only architecture that suffers. If an agency doesn't understand technical SEO, and most don't, a migration from WordPress to headless can destroy organic traffic you built over years. Not because headless is bad, but because redirects are done wrong, canonical tags are placed sloppily, structured data gets lost. The client won't see this at acceptance. And I'm not even talking about AEO, which at its current stage of development sits roughly where early Google bots were when they couldn't parse client-side JS.
Vendor lock-in that goes by another name
Technically, you can always migrate off a headless CMS. Export JSON, move the data. No one is holding you.
In practice, migration means rebuilding the project from scratch. Because your code was written against the Contentful SDK, your TypeScript types were generated from Contentful schemas, your editors were trained on the Contentful UI, your pipelines hooked into Contentful webhooks.
Recognition arrives at the worst moment. Concrete examples of what that moment looks like in practice.
Contentful, content types. One of the most frequently discussed ceilings on Reddit:
I've been most handicapped in the past by Contentful's limit of 48 content types. That's super tricky because content types are used a LOT in Contentful and you can quickly hit that limit. At which point you're totally screwed.
This isn't an edge case. 48 content types is a real ceiling for a non-trivial marketing site.
Contentful, locales. The free plan gives you two locales. Lite ($300/month) gives three. You need a fourth language? Welcome to Premium, where the price is custom and determined in a call with sales. According to Vendr, Contentful contracts average in the mid-five figures, and enterprise deals climb into six figures. Large multi-locale deployments go significantly higher.
Storyblok, the 2025 pricing rework. In April 2025, Storyblok rolled out a pricing restructure with a 60-day grace period. A G2 review from one client:
They altered their usage policy and plans which is now costing my clients 3x what they were paying a few months ago with no added benefit.
Sanity, per-seat math. A typical Growth plan for 50 users at $15/seat with the needed add-ons (SAML SSO $1,399/mo, Dedicated Support $799/mo, an additional dataset $999/mo) comes out to $3,947/month, or $47,364/year. And that's before Enterprise. Meanwhile, one viral article in production driving bot traffic to an unprotected Sanity endpoint can produce a surprise bill, a known case from the developer community.
When AI arrived: imitation instead of integration
When it became clear that LLMs are serious, almost every headless CMS pushed toward AI. Some even began calling themselves AI-native.
Let's look under the hood.
Sanity launched an official remote MCP server at
mcp.sanity.io. This is a real step. Unlike its competitors, Sanity made an investment. Schema-aware tooling, Agent Actions tied to GROQ patterns, context for agents, 40+ tools on top of the existing API. This is the most serious implementation in the category. But under the hood, it's still an LLM as a client calling an API designed for a human editor. Data, schemas, query language (GROQ), permissions, all were created for editorial workflow, not for agentic flow.Contentful shipped an official MCP server — open source, with a hosted beta — alongside "AI Actions," a feature with a GUI in Premium plans that lets you generate and transform content. Sanity, in its own documentation, characterizes the competition more dismissively:
Contentful offers Agent Actions through a simple GUI dashboard (you can trigger it via an API call). And… that's it.
Storyblok has an AI Suite on a credit model (25K credits on Starter, scaling to 1M on higher plans). Content generation, visual editing assistance. In practice, an LLM assistant inside an existing editor.
In all three cases, the LLM is an additive feature on top of an existing architecture. Content models, editorial workflows, the data storage schema, all remain unchanged. An AI layer that knows how to work with this was added on. This is not AI-native architecture. This is AI-enabled legacy architecture. And I'm not even mentioning that you can't bring your own agents, your own models. Once again, everything has been decided for you.
It's worth restating the thesis. An AI layer bolted onto an editor built for humans is not an architecture built for agents. A minority of teams on headless are genuinely well served by it. The rest pay for infrastructure designed around someone else's problem, and they pay more every year.
A signal worth noticing
In December 2025, Lee Robinson, for five years VP of Product at Vercel and now at Cursor, published a post with a telling title: "Coding Agents & Complexity Budgets." In it, he describes migrating cursor.com away from a headless CMS, back to Markdown and code. In three days. Spending $260 on tokens. With agents.
Concrete numbers. 322,000 lines of code deleted, 43,000 added. Build speed doubled. CDN costs dropped. And most importantly, the team got back the ability to work with the site through agents directly, instead of through a CMS abstraction on top.
His phrasing is precise:
With AI and coding agents, the cost of an abstraction has never been higher. Over abstraction was always annoying and a code smell but now there's an easy solution: spend tokens.
Sanity responded with a public post called "You should never build a CMS," and that title itself is telling. They're right that for a team of ~50 developers who all write code, markdown files in the repo work. They're also right that the complexity of content operations returns over time. Scheduling, reverts, previews, cross-page references. But their response doesn't address the main question. Why do existing CMSes integrate so poorly with agents that reasonable people prefer to migrate to markdown?
Sam Seely formulated it most concisely on Twitter:
My big takeaway from the Cursor migration off Sanity is not that CMS is dead. It's that customers can migrate off many vendors with ~$200 in token charges and a weekend of work. The pressure has never been higher for vendors to deliver real value.
Why headless CMS is still here
Because the alternatives were worse. Or used to be.
WordPress in 2025 is technical debt, security issues, and PHP-era architecture. Builder, Webflow, and similar tools are no-code with a ceiling you hit very fast on any non-trivial project. Against this backdrop, headless CMS remained a strong choice. If you got lucky with your implementation partner, you got what you were promised. Not because Contentful or Sanity are good in themselves, but because the partner did everything right.
That's an important distinction.
Payload v3, released in November 2024, was a good signal in the right direction. MIT license, self-hosted, architecturally embedded directly into a Next.js app, into the
/app folder. over 40,000 GitHub stars, growth from 1M to 5M total npm downloads in a year, weekly releases. In June 2025, Payload was acquired by Figma with a commitment to preserve the open-source core. A real step forward. But it doesn't solve two fundamental problems. Finding a partner who knows how to work with it is still hard, and a proper implementation still costs the same $30K to $50K minimum, which closes the door for most small businesses.For symmetry. Directus, one of the oldest players in the category, went the opposite direction. A few years ago it switched from GPLv3 to Business Source License (BSL) 1.1, with a carve-out for organizations with annual revenue or funding below $5M. This is a telling pattern. "Open" players are gradually closing.
So yes, headless CMS remains a working choice. But for the first time in many years, alternatives have appeared that put the very necessity of this complexity in question.
What happens next
When Anthropic launched Claude Design in April 2026, it wasn't trying to do Figma better. VentureBeat described it precisely: Claude Design is "a standalone product accessible to founders, product managers, and marketers who have never opened Figma." Expanding the user base of design to non-designers, that's the real competitive pressure, not feature parity with professional tools.
Anthropic's emphasis: "giving designers room to explore widely and everyone else a way to produce visual work." The key phrase is "everyone else." The target is not designers. The target is everyone who used to need a designer.
The market reaction speaks for itself. Figma's stock dropped ~7% on launch day, even though Anthropic officially called Claude Design a complementary product.
This is the same mechanism that should now happen to content operations.
Not because headless CMS is bad. But because LLMs change who produces content and how. Content is increasingly generated, transformed, localized, and validated with the participation of agents. An architecture where the LLM is a third-party client to an API designed for a human editor cannot be effective in this world by definition. Not because it was built poorly, but because it was designed for a different task.
What we're building in response
For the last six months, I and a small team have been building agntcms. It's an attempt to answer the same shift Claude Design captured in design.
Technical boundaries for context. Open source, MIT license. A framework, not a service. Next.js under the hood. Claude Code as the first agent runtime, with other agents to follow as their tooling matures. Not headless, not monolithic. A third form, for which a settled term doesn't yet exist.
What this means in practice. A marketer, through their own agent, adds a page, restructures a block, localizes content. Not through a developer ticket. Not through a visual editor with a ceiling. Through conversation. A founder, through their own agent, runs a content migration or adjusts SEO. The developer is not pulled in for every button change, because for most requests they don't need to be.
This is the same logic Anthropic applied with Claude Design to Figma. Design used to be a profession with a barrier to entry. Now "everyone else" can produce visual work. Content operations used to require either a developer or an editor trained to navigate a dashboard. Now that same "everyone else" can work with content through their own agent.
Not for everyone. agntcms isn't for editorial teams of 50 with five-tier approval workflows. Not for omnichannel scenarios with native apps and smart-watches. Not for teams that don't yet work with agents. Those tasks stay with headless — the minority of cases it was actually designed for.
Let me close where I started. Headless CMS stopped being a safe default the moment a site outgrows a builder. The teams who truly need its complexity are a minority, and it should stay theirs. The rest — marketing sites, landing pages, content portals, and corporate resources pushed past the no-code ceiling — overpay for someone else's scenario. And for the first time, they have an alternative that doesn't reduce to a choice between WordPress and Sanity.
agntcms is open on GitHub under MIT license. It isn't a product we're selling, and it isn't a SaaS we're trying to log you into. It is an attempt to put the position I outlined across these pages into code. The product is the statement I'm making in this essay.
If the diagnosis matched your experience, there's a concrete way to participate. Issues, PRs, discussions in the repository. Every commit, every open task, every comment moves the industry closer to the moment when teams can pick the architecture that actually fits them, instead of defaulting into one that doesn't.
github.com/agntcms
P.S. — Anthropic, plz collab 🤝
Market data: Future Market Insights (2024). Pricing data: Vendr, costbench.com, G2, Webstacks (2025-2026). Cursor migration: Lee Robinson, leerob.com/agents (December 2025). Sanity response: sanity.io/blog/you-should-never-build-a-cms. Payload data: payloadcms.com, GitHub (February 2026). Claude Design: Anthropic Labs, VentureBeat, DesignRush (April 2026).