Agents raise the bar for your CMS
If everyone who edits your site writes code, you may not need a CMS at all. Content as Markdown in the repo, changed by coding agents and reviewed as pull requests, works well for a small team of developers. Once marketing or legal edit too, you need a CMS, and the real question becomes what that CMS should do about AI agents. Short version: agents get their own way in and propose changes, and a person decides what goes live.
In December 2025, Cursor wrote about removing the CMS behind its website, so its coding agents could edit content too. Sanity replied that teams shouldn't build their own CMS, and the Hacker News discussion split down the middle. The no-CMS side has a point. If everyone who edits the site works in a terminal, the repo is the simplest content platform there is, and hard to beat. Public posts as of October 2026. Corrections welcome.
Four signs your content has outgrown the repo
Someone who doesn't use git needs to change a page.
The marketing lead fixing a price on a Friday afternoon won't open a pull request. In the same debate, practitioners pointed out that an AI coding tool does nothing for an author who isn't comfortable with git and build pipelines. Every change goes back through a developer, which is the bottleneck a CMS exists to remove.
Someone has to approve it.
Legal signs off the pricing page; the brand team checks the claims. In a repo, approval means a pull-request review by whoever has merge rights. That's usually a developer, and a developer is the wrong person to approve a pricing claim. Access is granted per repository, not per page or section.
Many people edit the same pages.
Two agents and three editors working on one landing page produce merge conflicts in prose. A CMS saves per entry, checks the version on every save, and flags a field that changed after someone started editing it.
Nothing may go live without a person seeing it.
A Markdown diff isn't the page, so reviewers approve text they haven't seen in place. Direct writes are worse. On 16 October 2026, a script editing our own marketing site through the management API dropped the header field from the site settings in a batch update, then published. The live site lost its navigation, and no person saw the change before it went out.
What a CMS should offer AI agents
Eight things to ask of any platform, ours included.
API or MCP access, not a clipboard.
If an agent's only way in is a person pasting text into a chat window and back, nothing records what changed or why. Agents should read entries, the content model and the page tree directly, through an API or an MCP server.
Propose-and-review, not direct writes.
The agent submits a change. A person sees it as a diff against the current draft, applies or dismisses each edit, and saves. Publishing and deleting stay with people.
Scoped, expiring credentials.
One environment, a set expiry, reads and proposals only. A token copied into a config file outlives the project it was made for unless it has an end date.
The same content model and contract the editors use.
An agent's edit should pass the same validation as an editor's save. Unknown fields, broken blocks and list positions that don't exist should come back as errors before anyone reviews them, with a warning when an edit would delete items.
Conflicts caught before they land.
A CMS saves per entry, checks the version on every save, and flags a field that changed after someone started editing it.
An audit trail naming who applied what.
History should name the person who applied a change, and the proposal it came from. "Updated by API token" is no help when you're working out what broke the homepage.
Prompt-injection surface, named.
The assistant has no web access, so no web page can slip instructions into it. Ask what untrusted text each agent reads, and what it can do with that text.
Model choice and cost visibility.
Each person picks their own model, from the Claude and GPT families, and external agents bring their own. Ask what each agent action costs, and who can see it.
Three ways teams handle agents today
Repo only. Coding agents change Markdown and a developer approves the pull request. It works well for a small team of developers, and the page above shows where it stops.
CMS with API or MCP access added. Agents get a way in. The question is what that access allows, so hold it against the checklist.
CMS built for agents. Agents are a user type with their own scoped access, proposals and audit trail. Any good CMS can be pushed toward this way of working. Ours ships already there.
Fill in the right-hand column for your platform, then check it against the cards above.
Agents are a user type, not a plugin.
Once anyone but a developer edits the site, you need a CMS that gives agents their own access and limits. On Uniwoven, the assistant and MCP clients only propose changes, and neither can publish or delete. An editor applies each edit from a diff, and history names the editor and the proposal. An external agent connects with a propose-only token, scoped to one environment and set to expire. Multi-page proposals aren't shipped yet. Editorial approval before publish is delivered in your rollout.
See the Setup Review →What teams ask about CMSes and agents
If everyone who edits your site writes code, maybe not. Markdown in the repo, changed by coding agents and reviewed as pull requests, works well for a small team of developers. Once marketing or legal edit too, you need a CMS. Then the question is what it does about agents: they should get their own way in and propose changes, and a person should decide what goes live.
Watch an agent's proposal land as a diff
Every walkthrough opens with it: ⌘-click an element on the page, ask for a change, review the diff, apply it. We shape the sample space like your site first. There's nothing to prepare.
Book a walkthrough →