Why an agent instead of a CMS
A CMS is a bet that you know today what the client will want to change tomorrow. For a lot of sites, that bet loses. Here is the case for editing the file instead.
Amit Malul Lev
Software engineer
Every content management system starts with a form. Someone decides that a page has a title, a body and a hero image, and builds fields for those three things. From then on, the client can change the title, the body and the hero image, and nothing else. That is the deal. The form is the product.
For a lot of sites it is a good deal. If you publish articles, every article has the same shape, and a form that matches the shape is exactly right. The client fills it in, the site renders it, nobody can break anything. I have built these and I would build them again.
But there is another kind of site, and I think it is the more common kind for agencies and freelancers: the brochure. Six pages. Prose in the HTML. A photo here, a price there, a phone number in the footer. Nobody publishes to it. People change it, occasionally, in ways nobody predicted.
This post is about why, for that kind of site, I think an agent editing the actual file is a better tool than a form, and where that argument stops.
The bet a CMS makes
When you configure a CMS you are predicting the future. You are saying: these are the things that will change, and only these. Every field is a prediction that came true and every missing field is one that did not.
Clients are terrible at confirming predictions. The request that arrives is never "change the title". It is "can the top bit be more welcoming", or "add the new price under the old one but smaller", or "the photo on the about page, the one of me, can it go on the right". None of these are fields. All of them are edits to a file, and a developer would make each one in a minute.
So the CMS handles the requests you predicted, and the ones you did not come back to you. Which was the thing you were trying to stop.
What an agent does instead
An agent does not have fields. It has the file. When the client says the top bit should be more welcoming, the agent reads the top bit, changes the words, and shows a preview. When they want the price smaller, it adds a class or a span or whatever the site already uses for small text, because it read the stylesheet first.
There is no schema because the site is the schema. Whatever the files can express, the client can ask for. On a hand-written HTML site, which no CMS can edit without a rebuild, this is the difference between having an editor and not having one.
That flexibility is also the danger, and it is why an agent without fences would be a terrible idea. So the fences are the product, more than the agent is.
What the fences are
I will keep this short because the technology post has all of it.
The agent works on a copy of the files in a container with no Git, no credentials and no network. Whatever it produces goes through a gate that checks it against a policy file you wrote: which paths are allowed, how many files a change may touch, how many lines, no new dependencies, no scripts loaded from elsewhere. What passes becomes a pull request. The host builds a preview. A person publishes or does not.
The point of listing these is that none of them depend on the agent being good. They are checks on the output, not hopes about the process. A dumb agent behind these fences cannot damage a site. A brilliant one cannot either.
The honest costs
An agent is not deterministic. Ask a CMS to save a title and it saves the title, every time, for free. Ask an agent to shorten a headline and it will usually shorten the headline, sometimes rewrite it, occasionally change the wrong one. The client sees this on the preview and says no. It cost a few cents and thirty seconds. But it happened, and with a form it would not have.
An agent costs money per change. Not much: most edits on the site I run go through the free or cheapest tier and cost fractions of a cent. But a CMS costs nothing per save, and if the client is making two hundred edits a day, the arithmetic changes. Nobody makes two hundred edits a day to a brochure site.
An agent cannot validate. A CMS can insist that a price is a number and a date is a date. The agent will write what it is asked, and if the client asks for "about $40ish" in the price column, that is what the preview will show. Structured data wants a form.
And an agent is slower. A form saves instantly. A change through Webamend takes a minute or two, most of it waiting for the preview build. For an occasional edit that is fine. For a live-blog it would be maddening.
Where the line is
If I were building a site whose content has a repeating shape, edited by people who edit it every day, I would use a CMS, and probably a Git-based one so the repository stays the source of truth. Blogs, catalogues, documentation, listings. The form is right for these and the agent is wrong.
If I were building a site whose content is prose and layout, edited occasionally by someone who does not think in fields, I would put an agent in front of it with fences. Brochure sites, portfolios, small business sites, a therapist's practice page. The form is wrong for these because you cannot write the form.
The interesting cases are in the middle, and I do not think there is a rule. A site with a blog and a brochure around it might want both: a CMS for the posts and an agent for everything else. I have not built that yet. I expect to.
The part I keep coming back to
A CMS moves the decision about what can change to the day you configure it. An agent with a policy file moves it to a text file you can edit any time, and moves the decision about whether a change ships to the moment a person looks at a preview. I think the second arrangement matches how brochure sites actually change: rarely, unpredictably, and always with someone who wants to look first.
If that describes the sites you look after, this is what I built for it, and the pricing is per website so a handful of brochure sites does not cost like a platform. If it does not, the CMS you already know is the right call, and I mean that.