The short answer: it depends on size
In our initial calls, the same question now comes up regularly: «If AI writes and publishes my content, why do I still need a content management system?» It is a fair question. A language model can rewrite a page today, translate it into German and deliver the code for it in one go.
My answer has two parts. Small websites don't necessarily need a CMS. An LLM client serves them very well. Large websites want to keep their CMS: for compliance and for sovereignty. Between the two runs a line you can draw yourself with a handful of criteria.
In this article we first define the terms. Then I walk you through both worlds and their limits, explain the role of MCP and give you a table to place your own website. Finally, I tell you what we recommend to which audience.
First: three terms, briefly defined
Three terms carry this article. Here is the short version:
- CMS: A content management system is the software in which content is stored, edited, approved and delivered to the website. Well-known examples are WordPress, TYPO3 or headless systems such as Sanity.
- LLM client: The application in which you work with a large language model, for example Claude, ChatGPT or a coding assistant in your editor. Through connectors, the client can not only answer but also act.
- MCP: The Model Context Protocol is an open standard that lets such clients access other systems. An MCP server describes which tools a system offers, such as «create document» or «publish draft».
The key distinction is between operation and responsibility. A CMS has always done both: it makes content editable without programming skills, and it records who approved what and when.
The LLM client takes over the operation. It writes, translates and publishes. It does not take over responsibility. That decides whether you need a CMS: the more responsibility you have to organise, the more the system behind it matters.
Small websites: the LLM client is the better editorial system
Take the typical case: a craft business, a law firm or a consultancy with eight to fifteen pages. One person maintains the content, and changes happen four to six times a year. For exactly these websites, a CMS was always a heavy backpack: logins, plugin updates, security holes and an interface you forget between two edits.
What the process looks like
The content lives as text files in the website's code repository, in other words in Git. Your LLM client is connected to that repository. The process has four steps:
- Request: You describe the change in plain language, for example «New opening hours from January, and add green roofs as a service».
- Implementation: The client edits the affected files and submits the change as a proposal, which Git calls a pull request.
- Preview: The hosting platform automatically builds a preview version of the website. You click through and check it.
- Approval: One click merges the change. Git records what changed, and every version can be restored.
The result: no CMS licence, no admin login that can be attacked, no plugin maintenance. Git provides the version history at no extra cost. Translations and simple accessibility checks, such as missing alt text, are handled by the client in the same pass if you ask for them.
What you need to set up once
For this to work, you need a one-off setup. It is smaller than setting up a CMS, but it is manual work:
- Content files: Texts live in their own files, for example in Markdown, separate from the layout code. The client then changes content without touching the design.
- Limited permissions: The client may only create proposals and never write directly to the live version. You configure this protection once in the repository.
- Automated checks: When the preview is built, tests run for broken links, missing alt text and layout errors. If a test fails, you see it before approval.
- House rules for the client: A short text file in the repository describes tone, form of address and terminology. The client reads it with every request.
For a small website we budget one to two working days for this. After that, you maintain the website in the same application you already use for AI work.
Where the limits are
To be completely honest: this model has limits too. First, it stands or falls with the setup above. Without a separation of text and layout, the client can easily change the page grid while swapping a phone number.
Second, the preview remains mandatory. If you merge changes unseen, sooner or later you will publish an invented sentence. Third, the model ends as soon as several people with different permissions maintain content. A repository knows write access to code, but no permissions for individual content and no editorial approval stages.
The bottom line for small websites: the best CMS is none at all, as long as a human checks the preview.
Large websites: compliance and sovereignty need a home
Now to the other end: a mid-sized company with 300 pages in three languages, product data from the ERP, a legal department and twelve people from marketing, sales and HR who maintain content. Here the calculation flips. Not because AI writes worse, but because the organisation around it has rules.
Approvals and audit trails
In large organisations no text goes live without approval. Product management checks product claims, sales checks prices, legal checks legal texts. A CMS maps these stages and records who approved what. A chat history does not.
Since 2 August 2026 there is another reason: Article 50(4) of the EU AI Act requires disclosure when AI-generated text informs the public on matters of public interest. The obligation does not apply if a human has reviewed the text and someone holds editorial responsibility.
For most product pages, the rule is unlikely to apply. For press releases, expert articles or public statements, it can. If you ever need to prove the human review, you need a system that records it. That is exactly what a CMS with a defined approval process does. Read more in our article on the EU AI Act for software buyers.
Roles and permissions
HR may edit job ads but not prices. The agency may create drafts but not publish anything. Such permissions belong to the content, not to access to the code. A repository that twelve people plus their AI agents can write to is a security risk, not an editorial system.
Content from other systems
Large websites rarely show text alone. Product data comes from the ERP or PIM, job ads from the applicant tracking system, contacts from the CRM. This data flows daily and automatically, not on request in a chat.
A CMS is the hub where these streams meet and are combined with editorial text. We show what that looks like in connecting Sanity to ERP and PIM. An LLM client that edits files in a repository does not replace this hub.
Sovereignty over your own content
The third reason is often underestimated. Sovereignty means three things here: you decide where your content lives. You decide who can access it. And you can switch AI vendors without moving your content.
A CMS with structured content is the layer that exists independently of the language model. Today Claude writes into it, tomorrow a European model, the day after your own. If you take data sovereignty seriously, you even run the CMS yourself, for example Payload on your own servers in the EU. The point: the model is replaceable, your content must not be.
MCP connects both worlds
The good news for large websites: you don't have to choose between CMS and AI. MCP makes sure the agent works inside the CMS instead of around it. The major vendors now offer their own connections:
- Sanity: The hosted MCP server has been generally available since 11 December 2025. It covers documents, content models and releases.
- Contentful: The vendor offers an official MCP server, either hosted or to run on your own machine.
- Storyblok: An official MCP server makes the management API usable for agents.
- WordPress: Since version 6.9, the Abilities API is part of core. The MCP Adapter makes these abilities available to AI clients.
What matters is which permissions the agent works with. For remote servers, the MCP specification describes authorisation via OAuth 2.1. Once it is in place, the agent acts with the permissions of the person using it. If an editor may only create drafts, their agent may only create drafts too.
What to settle before you connect an agent
An MCP server is connected quickly. The questions behind it take a little longer. We settle four of them in every project before an agent writes into the CMS:
- Draft or publish: May the agent only create drafts, or also publish? Our recommendation is almost always: drafts only.
- Content model as guardrail: The more precisely the schema defines its fields, the less the agent can get wrong. A price field that only accepts numbers prevents invented prices in running text.
- Audit log: Every change made by an agent must be recognisable as such in the version history. That way you can trace later where a sentence came from.
- Data flow: Which content goes to which AI vendor, and on what legal basis? Internal drafts and personal data should not go into every model unchecked.
This is also how we work on our own website: an agent creates drafts through the Sanity API, a human proofreads and approves. The CMS remains the authoritative source, and AI becomes the fastest editor on the team.
Where is the line for your website?
To help you decide, I have collected the criteria that tip the balance in our projects. Read the table row by row: the more hits in the right-hand column, the more clearly you need a CMS.
| Criterion | LLM client is enough | CMS makes sense |
|---|---|---|
| People maintaining content | 1–2 | 3 or more, with different permissions |
| Changes | a few per quarter | weekly or more often |
| Approval | owner checks personally | multi-stage, with departments |
| Languages | 1–2 | 3 or more |
| Content from other systems | none | ERP, PIM, CRM, job board |
| Documentation duties | none | press, expert articles, regulated industry |
| Data sovereignty | repository is enough | hosting location and access defined by contract |
A rule of thumb from our practice: with up to two hits on the right, an LLM client and Git serve you well. From three hits on, a CMS pays off, ideally one with cleanly modelled content and an MCP connection.
Costs follow the same line. A brochure website costs from €9,000 with us. An SME website with a headless CMS, multiple languages and integrations costs from €24,000. You will find the details on our B2B website page.
And the middle ground? A headless CMS such as Sanity is worthwhile even for smaller teams if the website is clearly going to grow. Moving from a repository to a CMS later is possible, but it means rework. If you have two hits today and expect five in a year, start with a CMS right away.
Our recommendation by audience
The table above helps you assess your own situation. Here is our own position on top: what do we advise each type of company if it asks us today? These recommendations are based on the projects we have built and maintained in recent years.
| Audience | Typical situation | Our recommendation |
|---|---|---|
| Freelancers and sole traders | 5–10 pages, you maintain them yourself | No CMS: website in a repository, maintained via LLM client |
| Trades and local service providers | few changes, mostly services, opening hours, jobs | No CMS, but fixed templates for recurring content |
| Start-ups and SaaS vendors | in-house developers, frequent changes | Repository plus LLM client, CMS only once marketing should edit without developers |
| B2B mid-sized companies | several departments, 2–3 languages, data from ERP and PIM | Headless CMS with MCP connection, agents with draft permissions only |
| Regulated industries | documentation duties, legal review | CMS with multi-stage approval and audit log, AI vendor processing data in the EU |
| Corporations and multi-brand companies | many teams, markets and brands | CMS as the central content source, self-hosted or EU-hosted, agents per role |
What this means for you as a decision-maker
- Managing directors of small companies: You save the money for a CMS licence and plugin maintenance. Invest part of it in a clean setup with previews and automated checks. That decides whether AI-based maintenance holds up day to day.
- Heads of marketing in mid-sized companies: Ask your CMS vendor about its MCP connection and how it enforces permissions. A CMS without a proper interface for agents will become a bottleneck within two years.
- IT and compliance: Treat AI agents like new employees: their own account, limited permissions, a traceable log. An agent with admin rights is an incident waiting to happen.
What we explicitly advise against
We see two setups regularly, and we advise against both:
- AI extensions that publish directly: A plugin that publishes text without a draft stage combines the downsides of both worlds. You pay for the CMS and give up its approval process.
- A large enterprise CMS for a small website: A system built for six-figure budgets on ten pages ties up money and attention. Here, the LLM client is the more honest solution.
Our position comes down to one sentence: the question is no longer «CMS or no CMS», but «who carries the responsibility, and where is it recorded?»
Next steps
The CMS is not dying. It only loses its mandatory role for small websites. For large websites it becomes more important: as the home for approvals, permissions and data sovereignty, with AI agents docking on via MCP.
If you want to know which side of the line your website is on, let's go through it together. In 30 minutes you will know whether you need a CMS and which one fits your team. Book a no-obligation video call here.
