Support & Education For whoever owns the website Field notes · August 2026

The next CMS is
not a dashboard.
It is a conversation.

For about twenty years, changing a sentence on your own website has meant logging into an application that lives on your own website. The industry sold that as control, and for a while it was. What it produced, at every price point, is a licence line, an implementation retainer, an update treadmill, and a queue sitting between the person who knows what needs to change and the system that changes it.

What replaces it is not a better dashboard. You describe the change you want in plain language, an agent proposes it as a reviewable difference, a named person approves it, and the site rebuilds as ordinary files. Your team gets its own website back, several line items come off the bill, and the thing turns out to be safer that way rather than riskier, which is the part nobody expects. These are field notes on how we think it works, and where we think it breaks.

Skip down and try to break it ↓

There is a sandbox below.

A fictional guesthouse, a chat box, and a set of rules you are welcome to try to get around. The refusals are the interesting part.

What the CMS
actually cost us.

↳ the trade was reasonable. the bill kept arriving.

Every content management system in wide use is an answer to a reasonable question asked about twenty years ago: how does a marketing team change a sentence on the website without waiting for an engineer? The answer the industry settled on was to put the editing application on the website itself. With the tools of the time that was a sensible decision, and we are not going to pretend otherwise. It is worth being precise about what it cost, because most organizations are still paying it monthly.

Look at what the architecture actually requires. To let a colleague log in and edit, the public site has to serve a login. To assemble a page out of a database on every request, it has to hold credentials to that database and run code for every visitor, including the visitors who are not visitors. To let the marketing team add a booking widget without filing a request, it has to accept plugins, which is to say it has to execute code nobody at your company read. Each is a fair answer to a fair request. Together they mean the editing machinery ships to production, permanently, in the same place as the content.

What it addedA login on the front door

Your public website now has an administrative entrance reachable by everybody on the internet, not only by your team. It exists so five people can work. It is offered to everyone else at the same time, all day.

What it addedA standing update obligation

A database-driven site with a plugin ecosystem is software with dependencies, and dependencies get security updates. Somebody has to apply them, confirm the site still renders, and do it again next month. When nobody owns that job it stops quietly, and the site looks fine while it ages.

What it did not removeThe queue

Ask a marketing lead what they can change unaided. Usually the text inside a field somebody anticipated. A new section, a different arrangement, a component the template did not plan for: all of it becomes a ticket. The engineer did not disappear. They moved into a queue between your team and your own website.

↳ and the same trade, at enterprise scale:

The suite is the trade with a bigger invoice.

Adobe Experience Manager is the category’s most complete expression of this architecture, and we mean that descriptively. It is bought as licensing plus an implementation, and the implementation is normally delivered by a system integrator rather than by the people who will use it. Then it carries a maintenance and upgrade line for as long as you own it, because a platform of that size has versions, and versions have to be moved between.

The structural consequence is the one worth naming. Implementations of that kind tend to calcify. The site ends up shaped like the platform’s opinions about what a page is, because that is the shortest path through the build, and by the time anyone wants a different shape the templates, the components, the authoring workflows and the training have all been poured around the old one. Changing it means going back to the integrator. You did not buy a website. You bought a relationship with the cost of changing your website.

None of that is a scandal, and none of it is unique to one vendor. It is what happens when the machinery that edits the site is large enough to need specialists. The suite is the honest version of the trade: it names the price out loud.

↳ the inversion this whole page is about:

That cost structure taught a generation of organizations to treat website changes as scarce. If a change costs a specialist’s week you ration changes: batch them into releases, route them through a queue, convene a committee to decide which are worth the money. All of that governance was built to protect a scarce resource, and the scarce resource was production capacity.

That resource is no longer scarce. Generating code and copy has become cheap and conversational. You may have seen the phrase vibe coding for the informal end of this: describing what you want in plain language and letting a model produce the implementation, without reading much of what comes back. It works far better than it has any right to, which is exactly why it is dangerous in an organization. The generation is cheap. The judgment about whether it should exist is not.

So the scarce thing flips. It is not production capacity any more. It is governance. Cheap generation without rails is how a brand comes apart in public, one plausible-looking page at a time, and nobody notices until a customer does. The answer is not the old suite, which priced the problem away by making everything slow. It is not raw vibe coding either. It is the third thing: a conversation with rails around it, which is the rest of this page.

A socket, and what
moves through it.

↳ the acronym is the least interesting part of this

Something changed in the last two years that is easy to miss under the noise. It is not that the models got better at writing, although they did. It is that a standard appeared for connecting them to systems, and standards are what turn a demonstration into infrastructure.

The standard is MCP, the Model Context Protocol. Strip the name and it is a plug shape. Before a shared protocol existed, connecting an assistant to a code repository, a content database and a deploy pipeline meant three bespoke adapters, written by hand, maintained by hand, and thrown away whenever any of the three changed. A protocol turns that into a socket: each system describes once what it can do and what it will not do, and any agent that speaks the protocol can use it. That is the whole idea. It is plumbing. Plumbing is what makes a thing ordinary rather than exciting, and ordinary is the condition you want before you put your website behind it.

↳ four things it gets plugged into, glossed:

The repository. The versioned store of every file that makes the site, usually git. Every change to it is a numbered, attributed, reversible event rather than an overwrite.

The content database. Your structured content: rooms, prices, articles, people. Structured means the fields are named and typed rather than buried in markup, which is what lets anything other than the website read them later.

The design system. Tokens are the named values a brand is actually made of: this many colours, this type scale, this spacing ladder. Components are the assembled pieces already reviewed for accessibility and tested at every screen width.

The deploy pipeline. The script that takes content plus templates, runs the checks, produces finished files, and puts them on a CDN, the distributed network of servers that hands your pages to visitors. The output is files. Nothing on the public side is thinking.

Step oneSomebody describes it

In their own words, in the sentence they would have used in the ticket. No field names, no knowledge of which template holds the string, no login to an application they use twice a month and relearn every time.

Step twoThe agent proposes

It resolves the request against the real structure: which field, which page, which token, which rule applies. Then it stops. It does not save. It opens a proposal, a difference between what is live and what is being asked for, written so a person who does not read code can read it.

Step threeA person approves, then it builds

Approval is the only thing that moves a change forward. Once given, the validators run and the site is rebuilt as plain files. If it was wrong the revert is one action, because the history was never optional.

The change is not a save. It is a proposal.

↳ what the public actually receives:

The site gets smaller, not bigger.

This is the part that surprises people who expect an AI project to add moving parts. The deployed site is static output: HTML, CSS, images and fonts, sitting on a CDN. There is no admin panel in production, no plugin loader, no database connection open to the internet, no server assembling a page in real time while a stranger waits.

All of the machinery that made the change lives outside production, in systems your team signs into and your visitors cannot reach. The public surface got simpler while the workflow got more capable, which is an unusual direction for software to move and is where most of the arguments later on this page come from.

↳ and the part templated pages get for free:

One record, every page that renders it.

Most of a real site is not written, it is rendered: a room, a case study, a product, a person, each a structured record poured through a template. That is where the content database earns its place in this architecture. The agent does not edit page seventeen. It proposes a change to the record, the proposal clears the same checks and the same approval as everything else, and every page that renders the record is rebuilt together in the same deploy. A rate, a name, a legal line changes once and lands everywhere at once, or it does not land at all.

Consistency stops being a proofreading job and becomes a property of the pipeline, because drift needs a hand-edited page to live in and the template is the only path from the record to the site. We run this at small scale ourselves: the case studies on this website are generated pages built from one structured source, and changing them means changing the record, not the page.

The rails are
the product.

↳ wiring up the agent is the easy half, and it gets easier

Here is where we part company with most of what is written about this. The interesting part of an agentic content system is not the agent. Connecting a capable model to a repository is a weekend of work today and it will be an afternoon soon. The interesting part, the part that decides whether an actual organization can live with the thing, is the set of constraints around it: what an agent may touch, what it may choose from, what has to be true before a change is allowed to exist, and who signs.

An agent with unrestricted access to your website is not a content management system. It is a very fast way to break one. Four rails, and they are ordinary engineering rather than anything clever.

Scoped ownership

Every agent runs as a role, and a role owns regions, not the site. The marketing team’s agent can change hero copy, promotional banners, the ordering of offers and the accent token on the pages it owns. It cannot touch navigation, the footer, pricing that belongs to another system, or a page that belongs to another team. This is the same idea as file permissions, applied to parts of a page instead of whole servers.

The behaviour on the boundary is the part people get wrong. A request outside the scope should produce a refusal that names the rule and points at the role that does own it, not a silent failure and not an apology. That is the only way a scope becomes intuitive.

scope: marketing owns four regions

Design-system rails

The agent chooses from the brand; it does not invent inside it. Colours come from a named set of tokens. Type comes from a scale with a fixed number of steps and no free size field. Spacing comes from a ladder. Components come from a library already reviewed for accessibility and already tested at every width. Ask for a colour that is not in the set and the correct answer is to offer the nearest ones that are.

This is where the design system stops being a document nobody opens and becomes an enforced constraint, which is what it was always meant to be. An agent that can invent a colour can take a brand apart one reasonable request at a time, and every individual request will have looked fine.

tokens only, no free values

Validators that run like CI

Continuous integration, usually shortened to CI, is the habit of running an automatic check against every proposed change before a person looks at it. Content rules are as testable as code. Banned claims. Tone rules. Link checks. Structural checks. Length caps where a length matters.

A validator has no opinions. It has a list, written by the people who own the brand and the legal exposure, and every rule in it is a mistake somebody already made, written down once.

every proposal, before a human reads it

The approval gate

A pull request is a proposed change held outside the live site and presented as a difference, a plain before-and-after of exactly what would change, for a named person to approve or decline. Every change the agent makes arrives that way. Nothing is applied because it was requested. It is applied because somebody approved it.

Underneath, git keeps the history, so every change already carries an author, a timestamp and a reason, and the revert is a single action rather than a restore from a backup somebody hopes ran. You do not buy the audit trail; it is a side effect of working this way.

a named person, every time

You do not buy the audit trail. It is what is left over when every change has to be proposed.

↳ the proof we can actually show you:

This page had to pass one.

We can be concrete about validators, because one is standing behind the page you are reading. This site carries an editorial validator: a script every page has to survive before it ships. It checks the shape of the markup and the balance of the tags. It confirms that every internal link resolves to a file that exists, that every in-page anchor points at an element that exists, and that no identifier appears twice. It enforces an image sizing contract we adopted after stretching our own logo, twice, in public.

It also holds a list of tripwire phrases: superlatives we caught ourselves reaching for, absolutes we do not believe, framings that were true once and quietly stopped being true, and a set of canonical sentences that must appear byte for byte on the pages that promise them, so that a well-meaning rewrite in one place cannot silently break a commitment we made in another.

It is about three hundred lines of Python, and it has caught us more often than we would enjoy writing down. This page went through it too, and the first run was not clean. That is the argument for rails at the smallest possible scale: the check is cheap, it is boring, and it does not get tired at the end of the week.

Notice what none of the four rails require. Not a frontier model, not a platform, not a licence. Scope is permissions. Tokens are a design decision written so a machine can read it. Validators are a list. The gate is a review step your engineers already run for code and have never been offered for content. The conversation looks like the future; the rails decide whether you can use it on a Tuesday.

Try it. Then try
to break it.

↳ the guesthouse is invented. the guardrails are not.

Below is a working demonstration of all four rails. Faro Azul is a fictional guesthouse in Rincón. Its page is not real, its rooms are not for rent, and its rates are invented. Ask for a change in the box, watch what comes back, and pay more attention to the refusals than to the successes. The refusals are the product.

Four things are worth trying deliberately. Switch roles. Marketing owns the copy; reservations owns the nightly rates and nothing else, so ask each of them for the other one’s job and read how the refusal names the rule and points at the role that can. Ask for a claim. Superlatives and absolutes hit a banned-word list before a proposal can exist, and every proposal that does exist shows the checks it passed. Ask for several changes at once and they arrive as one proposal with one approval, which either clears every check or does not exist. Then press Preview before approving, and watch the page render the proposed state without committing it.

Be exact about what is running, because the architecture is the argument. The conversation goes to a frontier model through this site’s own serverless layer, over a managed gateway, which is why no provider key exists anywhere in this website’s code. The model’s only job is to map your words onto one of a short list of permitted intents. It does not write the copy that renders, it does not produce markup, and its own words are never shown to you. The rails that accept, refuse, cap and gate the result are ordinary code. If the model cannot be reached, the demo continues on a scripted keyword matcher, and the panel says which of the two you have. The matcher takes one change at a time: reading a campaign out of a sentence is the live model earning its place, and we would rather show you the seam than paper over it.

faroazul.example · live

Faro Azul · Rincón, Puerto Rico

Sleep where the road ends.

Six rooms, one lighthouse, and the last paved corner of the island.

Check dates

Surf week

Seven nights, boards in the shed, and somebody who knows which break is working before you get in the car.

from $95 a nightRead more →

Long stay

A month in the corner room, with a desk that faces the water and power that stays on.

from $78 a nightRead more →

The long table

Thursday dinner on the terrace, cooked by whoever is staying and claims they know how.

from $45 a seatRead more →

We came for three nights and rebooked from the porch on the second morning.
a guest, July 2026

Signed in as Checking the model…

What the marketing role owns

Can change: The hero headline, capped at 48 characters
Can change: The hero subline, capped at 130
Can change: The button label, capped at 20
Can change: The guest quote, capped at 140
Can change: The promo banner: its text, and on or off
Can change: The order of the three offers
Can change: The accent token: ocean, coral, moss or sand
Cannot change: Nightly rates, which reservations owns
Cannot change: Layout, navigation, footer
Cannot change: Typography, spacing, components, code

You are signed in as the marketing role for Faro Azul. Tell me what you want changed and I will propose it. Nothing renders until you approve it, and you can preview first.

This demonstration needs JavaScript. What you can see beside it is the page exactly as it ships: plain files, no admin panel, nothing to log into.

Change log

Nothing approved yet. Approved changes land here, each one revertible on its own.

We do not store what you type; it does pass through this site’s own serverless layer to reach a frontier model over a managed AI gateway, which is why no provider key lives in this website’s code. Reloading resets everything. The model returns an intent and nothing else: never copy, never markup, and never a word you read here. Every reply, refusal and diff on this panel is written from a template on our side. The role scope, the token list, the character caps, the claims validator and the approval gate are all ordinary code in your browser, and the client rails overrule the model rather than trusting it. If the model is unreachable the demo continues on a scripted keyword matcher, which handles one change at a time and says so.

Faro Azul is invented, and any resemblance to a real guesthouse in Rincón is a coincidence we would enjoy. Two roles and eight editable regions is still small: a production system has more of both, and the same shape.

Safer, not
riskier.

↳ fewer classes to carry. not zero.

The first objection is usually about security, and it is a fair one. Letting an agent write to the system that produces your website sounds like more risk than letting a person type into a form. The honest answer turns on a structural fact: a static, git-backed site does not have some of the things that get attacked.

Class removedNo administrative login

There is no editing application on the public site, so there is no administrative login on it either. An attack aimed at that door has nothing to aim at: the attempts do not get more sophisticated, they get irrelevant. Your team signs into systems that are not the website.

Class removedNo plugin surface

Static output has no third-party plugin loader, so there is no monthly cycle of advisories against the public site. The dependencies that remain live in the build system, on your schedule, where a bad one shows up as a failed build rather than a page your visitors already loaded.

Class removedNo injectable admin form

Nothing on the deployed page writes to a database, because the deployed page has no database behind it. Where you need a form, it posts to one narrow service with one job, which is a much smaller thing to reason about than an application that renders your whole site.

↳ and the part we are not going to soften:

This does not make a website safe, and fewer classes of vulnerability is not the same claim as less risk. What changes is the shape of what you have to get right, and you should look at the new shape before you like it.

The approval gate and the validator become load-bearing. If approvals turn into a formality somebody thumbs through on a phone between meetings, the gate is decorative and you have automated the production of unreviewed changes. If the validator does not encode the rules that actually matter to you, it will pass things it should have caught, confidently, at speed. Those two are now the parts we would review first, and they are the parts that need an owner with a name.

The rest is ordinary and still applies. The accounts that own the repository and the deploy pipeline become high-value, so multi-factor authentication is not optional and neither is checking who still has access after somebody leaves. An agent has credentials of its own; scope them the way you would a contractor’s. And treat anything a model reads from outside your systems as untrusted input, because instructions can be hidden in content, which is one more reason nothing reaches production without a person approving the difference. The wider version of this argument is on the security page →

What this changes
for teams.

↳ this is the actual argument. the security part is a bonus.

Everything above is architecture. This is the part that shows up in how a week goes, and it is why we think the trade is ending. Three changes, in the order they are felt.

↳ one: the distance collapses

From “we should change this” to live and audited.

Count the steps in the current version. Somebody notices the promotion ends on Sunday and the page still says Friday. They write a ticket. It is triaged, prioritised, assigned, scheduled into a release window, built, reviewed, staged, checked, and deployed. Most of that is not work. It is the overhead of moving a request between people who each have their own queue.

In the version this page describes, the person who noticed says what is wrong, reads a proposed difference, and approves it. Two steps, one of them a judgment call by the person best placed to make it. The change is live, attributed, checked against the rules and revertible, and nobody opened a ticket. That is not a speed improvement in the usual sense. It is the removal of a coordination cost that existed because production capacity used to be scarce.

↳ two: the same control, without the standing bill

The line items that stop existing.

Go back to the enterprise version of the trade. You pay for licensing, an implementation delivered by a system integrator, a maintenance and upgrade line for as long as you own it, seats for occasional logins, and the integrator again whenever the shape of the site needs to change. Those are structural costs of the architecture, not of your ambition.

Take the machinery out of production and most of those line items have nothing to attach to. There is a repository, a build, a host, and a model bill that scales with what your team actually asks for. We will not put a number on the difference: it depends entirely on what you run now, and anyone quoting one across the board is guessing. The claim is about which lines are on the invoice, not how big they are.

What does not go away is the design work, and we would be suspicious of anyone who told you it did. Somebody still has to decide what the brand is, what each role owns, and which rules matter enough to enforce. That cost moves from recurring to mostly up front, a better shape for it.

↳ three: flexible to whatever comes next

The content model outlives the renderer.

This decides how the next five years go and is the least visible on day one. If your content lives as structured fields rather than inside a page, the website is a renderer, not a home. The mobile app is a second renderer, the email a third. A partner’s feed, a kiosk in a lobby, an assistant answering questions about your rooms: all renderers, all reading the same governed content through the same pipeline, all subject to the same validators.

So when the next channel arrives, and one always does, you add a renderer. You do not re-platform. Compare that with a suite whose upgrade cycle runs in years while the medium it serves changes in months. A platform that moves slower than its own medium goes stale by construction, and no roadmap fixes that, because the problem is the ratio rather than the effort.

The governance travels with the content, which is the part people miss. The rule that says you do not make a particular claim is not a rule about your website. It applies wherever that sentence is rendered.

↳ where we come into it, which is narrower than it sounds:

The model is not ours. The protocol is not ours. The pipeline is mostly ordinary and you may already have most of it. What we do is the rails: deciding what each role owns, turning a brand into tokens an agent can be held to, writing the validator that encodes the rules you actually care about rather than the ones that sound good, and designing an approval step people will genuinely use instead of routing around.

That is a design job with an engineering shape, it is most of the work, and it is the only part that is specific to you. If your current site is a login, a plugin list and a queue, none of it has to change this quarter. It is just worth knowing that the trade you made twenty years ago is no longer the only one on the table.

The next CMS is not a dashboard. It is a conversation.

What the CMSactually cost us.