Whenever I build something for someone else, I always question how they'll edit the content and update it without me? I want to build them something I can hand off, and they can update themselves. Content Management Systems (CMS) such as WordPress have been the go-to solution for allowing non-technical folk to manage content on their blogs and websites, but now in 2026, what about agents?
Do we really need a CMS? Will people care if they have to use a chatbot to modify content versus a GUI?
As I start a new content-heavy project, I came across Lee Robinson's post from a couple months ago where he ponders replacing a CMS with flat markdown files. His goal being to reduce the technical overhead of integrating a headless CMS, and giving agents better access to content via markdown.
Lee Robinson sat down and spent 344 agent requests and around $260 to migrate the content and setup to markdown files, GitHub, Vercel, and a vibe-coded media management interface.
~ Knut Melvær, Sanity
Lee's article questions whether the technical overhead of integrating a headless CMS is worth it – suggesting for many teams it is, but it can be much simpler to build and maintain content with code and markdown in a repository.
We went back to clicking through UI menus versus asking agents to do things for us.
Loading tweet... View on X
From headless APIs to agentic workflow
I found Lee's article interesting in how it brings new thought to existing paradigms. New agentic workflows can improve a lot of clunky systems - something like how the internet replacing old ways with new tools:
Email replaced fax
Search engines replaced libraries
E-commerce replaced catalog ordering (Amazon)
The real shift – the one that will reshape document workflows – is humans adopting natural language as their primary interface for getting work done.
AI workflows replacing 'traditional software'
AI enhances and replaces existing approaches in a similar way:
Visual page builders → Component libraries + prompts. For example, Framer AI lets you start with a text prompt and generate advanced components based on descriptions, speeding up the build process and reducing the skill gap
Forms & workflows → Conversations: Instead of filling out structured forms, users interact with systems in natural language. This post by nutrient outlines the topic well, despite it looking like it's written by AI:
Knowledge bases → AI-queryable source of truth. For example, tools like Notion and Zendesk leverate AI-driven systems to interpret and answer natural-language questions, saving us browsing FAQs and docs.
Coming back to the CMS discussion though, a move towards markdown and agents in Lee's post isn't primarily about changing how end users interact with content (as in the examples above).
Headless CMS to Agents + Markdown
Instead, removing the CMS in favour of markdown focuses on the reduction in the technical complexity of operating a CMS alongside the main app – it's more about rethinking how content management works, and how projects can be tuned to be more agent-driven, including the content:
Another benefit of having your content in code is that all changes flow through git. This was nice in the past (for reverts or figuring out who changed things) but is incredibly helpful for coding agents to dig through autonomously.
In my case, this site (prototypr.io) uses a headless CMS (Strapi.io). I do find the CMS a huge extra thing to think about, but it doesn't slow me down in the long run – it's very useful for things like user management, memberships, roles, and permissions.
When your coding agent can grep your codebase but can't query your CMS, that's a real problem.
Markdown Works Better for Agent-Driven Systems
However, in other simpler projects, a CMS can be overly complex for something like an internal blog. Sanity highlight those complexity issues themselves:
Preview workflows are clunky
Auth fragmentation is annoying - CMS login, hosting provider login..
Multiple systems, and connecting frontend with backend
Markdown repository example
For my simpler sites, such as this AI knowledge base for company management (company.gi), I’ve naturally drifted toward Lee’s approach where my articles are stored directly in the repository as Markdown files:
Markdown as CMS benefits
Because my project also includes a chatbot and a structured knowledge base, having all content stored as Markdown makes things simpler:
No need to sync with or query an external CMS
Entire knowledge base can live alongside the app code
Content fed directly into LLMs without transforming
Agents can reason over, edit, and extend content autonomously
More trivial to add things like MCP or similar interface later
Furthermore, you can easily edit markdown articles in a nice UI through a markdown editor like Obsidian. To do so, set the Obsidian vault the folder containing your markdown, and you can edit in a nice UI:
By keeping the blogs as markdown, I have no API calls, and the agent can read the text without having to download anything or use a browser.
Don't build a CMS
In all, traditional CMSs imo still probably make sense for multi-author and role-heavy platforms like prototypr.io, but agent-first products do benefit from content living in your code. Overall it depends on the project.
It’s also worth noting the counterpoint Sanity make in response to Lee Robinson’s migration away from their platform. In “You Should Never Build a CMS", Melvær argues that while storing content as Markdown in Git works well at small scale, it tends to reintroduce CMS-like complexity over time: Asset management, permissions, localization, content models, previews, and scheduling don’t disappear, but resurface as new tooling.
At some point, you end up building a CMS. So in that sense, deleting the CMS doesn’t remove the problem; it more redistributes it.
Overall, I think for new projects, I'll be going the markdown route, as with Opus 4.5, when the time comes, it's easy to migrate to a CMS when needed.
Buy me a coffee
