Open source. Agent-readable. Built for real websites.

Agentic Web CMS

Turn a vibe coded website into a full CMS project with one prompt. Manage structured content, Markdown output, draft/live publishing, and MCP access from the same source of truth.

Read the docs View source

Built with

What I wanted Headcode CMS to become

Headcode CMS already existed before this version. Over the last few weeks I decided to rewrite it entirely with Codex. I wrote not a single line of application code by hand.

That became the point of the project.

Headcode CMS should be a CMS for the way websites are starting to get built now: with AI tools creating layouts, changing copy, wiring services, inspecting source, and keeping the system understandable after the first version ships.

Create the website with AI tools

Let Codex, Claude Code, Cursor, OpenCode, or another agent shape the frontend, sections, and visual language.

Turn it into a real CMS

Keep the custom layout, but move editable content into Headcode sections, fields, globals, and collections.

Update content from chat

Use MCP-aware clients to inspect entries, edit drafts, upload images, reorder sections, and prepare changes.

Keep publishing intentional

Agents can draft freely, but publishing to live stays a deliberate user action.

Install and deploy through agents

Let an AI tool install Headcode, configure Convex, set env vars, and explain the remaining human decisions.

Keep a simple admin UI

Forms, section lists, image management, versions, and publish buttons remain available for people who want them.

Expose Markdown by default

Public pages can also render compact Markdown for agents.

Stay open and inspectable

The source lives in headcodecms/headcodecms, so developers and agents can inspect the system.

The rewrite was less about proving that AI can generate code and more about designing a CMS around that reality. The website, the admin, the Markdown output, the MCP tools, and the content model all need to belong to the same system.

Explore the default demo website

The default Headcode CMS install gives you the same kind of site shown at demo.headcodecms.com. It is not only a screenshot of the product. It is the starter website: public pages, editable content, Markdown output, admin UI, collections, globals, draft/live behavior, and MCP access.

You can browse the frontend like a normal visitor. You can also sign in to the demo admin with your email address. Add, update, delete, and publish operations are disabled there, but the admin UI is visible so you can inspect the editing experience safely.

HomepageShows the default marketing homepage assembled from CMS sections.Markdown homepageShows the same homepage as agent-readable Markdown.DocsShows the default documentation page with install snippets, feature explanations, and code examples.Docs as MarkdownIs the version an AI tool can read quickly.BlogDemonstrates a collection with repeatable entries and blog metadata.PricingDemonstrates a global page with structured plan data.Sitemap XMLExposes CMS-backed routes for crawlers.llms.txtGives agents a compact map of the site.Admin UILets you sign in and inspect entries, sections, images, and versions in read-only demo mode.MCP endpointIs the endpoint an authorized AI client would use for content operations.

Why I created Headcode CMS

I have built websites for more than 20 years. The tools have changed many times, but the recurring problem is strangely stable: small and medium websites need to stay editable after the first launch.

WordPress became the default because it solved a real problem. Clients could edit content. Agencies could ship. A business did not need a developer for every typo.

But the shape of the problem is changing.

Vibe coding is how many websites will start. Agents can create a first version of a site, restyle sections, write copy, and connect services faster than a traditional production process. That is exciting. It is also incomplete.

A website still has to survive after the first burst of generation. People need to update text and images. Businesses need policies, offers, docs, locations, prices, constraints, and next steps to stay accurate. Teams need drafts, publishing, and a clear ownership model. Agents need enough structure and source context to make safe changes.

That is why I created Headcode CMS.

What Headcode CMS is for

Headcode CMS is for small and medium websites with 10, 20, or 50 pages. It is for agencies, studios, product builders, consultants, local businesses, and people who want the site to remain understandable after launch.

The goal is not to replace every enterprise CMS. The goal is a practical default for websites that should be editable by both people and agents.

Clients should be able to update content through an AI chat client or a simple admin UI. Creators should be able to create and adjust themes with a coding agent. Owners should be able to inspect the source, fork it, and adapt the system to their needs.

Open source matters here. If agents are going to help maintain websites, they need native access to the system they are changing. A CMS that can be inspected, modified, and explained is a better fit for this future than a closed black box.

Agents first. Mobile second. Desktop third.

The old mental model was desktop versus mobile.

The new model includes agents.

The exact percentages will be wrong. The direction is the point: agents become a real audience, not an edge case. A website still needs to look good on phones and desktops, but it also needs to be readable, explainable, and actionable through AI systems.

That does not mean humans stop mattering. It means the design priority changes. Structured content, Markdown output, MCP access, source context, and clear business information become first-class surfaces.

The next website is not only a page. It is a source of truth for people, search engines, chat clients, and agents.

The future of web CMS systems

Traditional admin UIs are becoming less central.

AI agents will increasingly use systems through chat clients, MCP tools, structured data, source code, APIs, and markdown views. Humans clicking through a large admin interface will become less common. Admin UIs may still exist, but more like focused expert tools: somewhere between a database browser and a traditional CMS interface.

Headcode CMS keeps the admin UI simple because the important future surface is not only the UI. It is the combination of structured content, source code, service boundaries, Markdown output, and agent access.

Markdown helps agents understand the site. MCP lets authorized agents change it.

Why websites need more business information

Agent access changes what websites should publish.

The old homepage tries to persuade a visitor. The next homepage also informs an agent that is helping a visitor decide.

Imagine someone asks an AI chat client: "I want to add solar energy to my house. Here is an image and my basic requirements. What are the best options, what does it cost, and where can I get it?"

The agent needs to inspect businesses, products, pricing, local availability, service constraints, policies, reviews, and trustworthy sources. Websites that expose accurate, structured information will be easier to compare, explain, and act on.

This does not mean every website needs another chatbot popup. It means the website itself should become more useful.

A good agent-readable website should expose:

pricing and packages,
product and service offerings,
constraints and availability,
location data,
comparison information,
policies,
documentation,
and clear next steps.

Agents do not need another brand manifesto. They need accurate information.

Design will matter differently

Handmade web design will still matter. But it will matter differently.

For many small and medium websites, the biggest value may shift away from custom decorative layout work and toward content quality, structure, useful integrations, agent-readable access, and clear business information.

AI-generated design that respects a brand and is good enough for the job will be enough for many projects. The bigger question becomes: what does the website know, how reliable is it, and can humans and agents keep it up to date?

The goal is not generic design. The goal is to spend more energy on what the website knows and can do.

Why still use a CMS?

Why not just let AI generate the website? Why not vibe code the site directly every time content changes?

Because generated websites still need an operating model.

Every content change should not require a source-code change.
Multiple editors still need controlled publishing.
Structured data, such as pricing tables and service packages, should stay structured.
The same content should render as HTML for humans and Markdown for agents.
Draft and live versions matter.
The system should be understandable enough for coding agents to customize safely.

Headcode CMS exists between static website generation and large CMS platforms. It is small enough to understand, structured enough to trust, and open enough to customize.

Software development and hosting will change too

The future of CMSs is tied to the future of software development.

Agents need access to source code. Open source becomes a strong default because agents can inspect, modify, and explain the system. Hosting platforms that can run software modifications written by agents will become more important.

Development may move away from long feature cycles toward a continuous stream of small, inspectable changes on main, where humans and agents collaborate.

Headcode CMS should reflect that future: source-available, forkable, easy to host, and designed for agent-assisted customization.

Built for my own projects, open for yours

Headcode CMS was created primarily for my own projects.

I wanted a CMS for small websites with 10, 20, or 50 pages. I wanted clients to update text and images through AI chat clients or a simple admin UI. I wanted themes to be created and adjusted with coding agents. I wanted the source to stay understandable and open.

But I think it can be useful for others too.

Use it, fork it, extend it, and customize it. A forked version may stay small and focused. Another fork may become a multilingual website with thousands of pages. The point is that the system should be open enough for both paths.