Written on the thing it describes · August 2026
The website with no CMS
No admin panel. No editor. No content database. No user roles. This site is managed, and there is no content management system anywhere in it. What replaced it is a repository, a folder convention, and an agent that has read the whole thing.
The claim, and its limits
Not "nobody needs a CMS". This case, precisely.
WordPress, Ghost, Drupal, Contentful, Sanity, Strapi and Webflow all did their job, and they did it well for a long time. The question is not whether they were good. It is which of the problems they solved you still have.
A content management system bundles about eight things: a place to store content, a way to type it without writing code, a preview, a publish button, a permission model, a revision history, a template layer, and a schedule. That bundle was correct when the alternative was editing HTML by hand and uploading it over FTP. It is still correct for plenty of organisations.
It is not correct here, and the reason is narrow enough to state honestly. This site has one author. The writing is long, researched and infrequent rather than short and constant. The person publishing it can operate a terminal. Under those three conditions, most of the bundle is solving a problem that is not present, and the parts that remain are already solved better by a version control system.
Where this argument stops working
A newsroom of forty with legal review, a shop with ten thousand products, a marketing team where nobody can use git, anything with scheduled embargoes, anything where the person writing must never be able to break the build. In all of those the CMS is earning its keep. If somebody tells you the CMS is dead, ask them how many non-technical people publish on their site. The answer is usually zero, which is not a generalisable finding.
The mechanism
What replaced it, in full
This is the part worth stealing, so here is the whole of it rather than a description of it. An article on this site is a folder.
box/
agentic-cms/
box.json title, dek, tags, keywords, dates, accent, hidden
index.html the article, owning its own markup
style.css the article, owning its own appearance
script.js figures, if it has any
cover.svg the card image
og.png generated, for sharing/box/agentic-cms.
There is no route to write and no record to create.
A build step walks box/*/box.json, validates that the required fields are
present, copies each folder into the public directory, and injects the things every page
needs and no author should have to remember: the canonical link, the Open Graph and
Twitter tags, the article dates, the structured data, the analytics. It writes one
_index.json listing every box, which is what the homepage and the index page
read. That file is the entire database.
Everything a CMS keeps in tables is either in the folder or derivable from it. Tags and keywords sit in the manifest. Reading time is counted from the words at build. The publish date is a field. Ordering is a sort. Drafts are a boolean.
The eight things a CMS gives you, honestly scored
| What it does | CMS | Repository plus agent |
|---|---|---|
| Stores content | A database | Folders. Portable, greppable, diffable |
| Revision history | Who changed what | Every change, with the reasoning written into the commit |
| Rollback | A button anybody can press | One command, but only for somebody who knows it |
| Templates | A theme layer | Each article owns its appearance, so none of them fight |
| Structured content | Content types | A JSON manifest per folder, which is the same idea, smaller |
| Preview | Built in, always there | Must build and look. Easy to skip, and skipping it hurts |
| Scheduling | Pick a date | Not without building it |
| Non-technical access | The whole point of it | Absent. This is the real cost, and it is not small |
Three genuine losses, and only one of them is a deal breaker. If somebody other than an engineer has to publish on your site tomorrow, keep the CMS.
What is new
The part a CMS was never able to do
Everything above is a fair trade at best. This is the bit that is not a trade, and it is the only real argument for the arrangement.
A CMS knows about content. It does not know about the site. It cannot read the stylesheet, the build script, the seeded database and the twelve other articles at the same time, because it was never designed to hold them together. An agent working in the repository can, and that changes what a single instruction can mean.
One instruction, in this repository
"Every page should carry its own canonical URL and share card."
What followed: a read of every route, the discovery that the root layout was setting one canonical for the whole site so roughly two hundred pages were declaring themselves duplicates of the homepage, a fix, a per category card generator written from the live records, and a verification pass across every URL. In a CMS that is a plugin, a settings page and a migration. Here it was one instruction, because the thing receiving it could see the layout, the routes, the data and the build at once.
That is the actual shape of the change. Not "AI writes the articles". The writing is the easy part and the least interesting. What moved is that research, generation, layout, validation, correction and deployment became one loop instead of six tools with a person copying between them.
The index on this site holds two hundred and six entries with sources and dates. The articles quote it. When an entry changes, the article and the figure drawn from it change with it, because both are generated from the same file. A CMS could not do that, not because it was badly built, but because content and data lived in different systems by design.
What goes wrong
Four real failures, from building this
An account of this that skipped the failures would be marketing. These are all from making the site you are reading, and every one of them is the same lesson in a different costume.
- It cannot see. Two hundred and twenty six cards on one page each carried eighty pixels of padding they should not have had, because the card element and the page wrapper share a tag name and one CSS rule caught both. Eighteen thousand pixels of empty space. Invisible in the code, invisible on any single card, obvious the moment somebody rendered the page and looked at it.
- It will be confidently wrong about a fact. A regulatory deadline went into a draft as August 2026. It had been moved to December 2027 by an amendment. Plausible, specific, wrong, and it would have survived unless somebody checked it against the regulator's own page.
- It will contradict itself across a page. One figure said thirty eight roles, the code that generated the chart said thirty seven, because a number had been typed into prose that the program already knew. Nothing in the tooling objects to that.
- It answers the question it was asked. An article meant for people worried about their data opened by explaining that they were being inconsistent, because they already use Gmail. Accurate, and useless. It took a human reader to say that a person asking whether their data is safe is owed an answer, not a rebuttal.
The rule that falls out of this
Render it and look at it. Every one of those four was caught by a person opening the page, and none of them by the tooling. The agent removes the labour, not the judgement, and an arrangement that pretends otherwise will publish something embarrassing within a month.
Where this goes next
Permissions become agents
Marked clearly: everything up to here is running. This section is not. It is one operator and one agent today, and what follows is design intent rather than a report.
The interesting question is what happens when a second person needs to publish. In a CMS that is an account, a role and a set of capability flags, and the whole permission model exists because a database needs to know who may write to which row.
If the interface is a conversation rather than a form, that model has an obvious
translation. A second person gets their own agent, scoped to part of the repository. It
may write in box/ and not in app/. It opens a change rather
than deploying one. The review that used to be a workflow state on a post becomes a
conversation between two agents with a person deciding.
None of that is exotic. It is how software has been written for twenty years, arriving in a place that had invented a parallel and weaker version of it because content was not thought of as code. The permission model was always there. It was just in the wrong building.
The point
Knowing AI is knowing which constraint just left
People say they know AI and mean they have used some tools. That is a reasonable thing to mean and it is not the useful thing.
Every arrangement you work inside was shaped by a constraint that existed when it was designed. A content management system exists because typing HTML was hard, because a designer and a writer could not safely edit the same file, and because a database was the only sane place to keep a thousand posts. Those were real constraints. Two of the three have quietly stopped applying.
That is what the skill actually is. Not knowing which model is ahead this month. Looking at something your organisation does, asking which constraint put it in that shape, and noticing when the constraint has gone and only the shape is left. Most of what a company does is shape left over from a constraint, and the ones that go first are the ones nobody thought to question because they were never the interesting part of the job.
Some practical honesty to end on. This arrangement suits one careful author and would not survive contact with a team that cannot use git. It removes the labour and none of the judgement, which means the bottleneck moves to whether you can tell good from bad and are willing to say so. And every failure it produces is confident, plausible and formatted exactly like the truth.
The site you are reading is the argument. Not because it is remarkable, but because it exists, it is maintained, nobody logs into anything to change it, and you can check every claim in it against a repository.