What agents need to operate your content

Written by Knut Melvær

Agents became content operators this year. On our MCP server, agent activity grew 70 times over in eight months, we recently published a report on it. Barely two months later, at the time of writing this, it has grown to about 2.5 million tool calls from 20,000 organizations, and counting.

And this work is not the greenfield writing of AEO optimized blog posts that the LinkedIn feed will make you believe. What we saw in the report is that 91% of it is operations on content that already exists: auditing, editing, publishing, migrating, translating. (These are teams already on structured content, so read it as what agents do once they can reach content, not as a census.)

Our conversations with customers have moved the same way. Agents come up in roughly one call in four now, up from about one in twenty last fall. And nobody on those calls asks whether the CMS is dead. They ask how to keep a support chatbot from inventing prices, how to automate updates to pages bound by regulation, how to move decades of documents out of a legacy system, and how to run translations efficiently and correctly across a dozen markets.

These are operational questions, from teams whose agents are already in the content. And not-so-humble brag: we’re now winning contracts because we’re seen as one of the most AI-forward content platforms on the market. Not because we show up to meetings with lofty claims and fancy slides, but because we are able draw the line between the everyday challenges and what you can employ agents and LLMs to do for you.

Putting content into Markdown misses the point

Thus, I find it frustrating that the answers circulating in developer discourse are much thinner than that. Takes like “put content in markdown files and let agents grep.” Or… “load all the content into a vector database and let them retrieve by similarity, bob’s your uncle.” Sure, but then what?

What I don’t find in these takes are reflections on how that content travels through an organization, or what happens with time, complexity, and scale. How different parts of your content corpus need different types of governance. And so on. The many business problems that require actual engineering.

That being said, these takes often come from a shared frustration. They come from developers who got stuck in a web CMS that was built for publishing pages, but doesn’t work well with agents. We all are starting to feel how antiquated software feels when you can’t hook it up to your Claude Code, Codex, Pi, or whatever you’re using this week.

But the alternative solutions throw away most of what it takes to operate content, which is more than a place to write and read it from singular or few technically-minded operators. To solve the content problems most modern businesses have with AI you need a live backend that humans and their agents can query, change safely, review, govern, and ship from. When GitHub barely scales for agentic engineering, how can you expect it to work for something that is at the same time often much more volatile and fluid than code?

So how did we get here? How can we elevate the conversation about agentic content operations?

The web CMS was built for pages. Content outgrew that.

What's reaching its limits isn't content management as an idea. It's the one specific machine for it, the publish-to-web CMS: a rigid content database of "posts and pages" (iykyk), an inflexible forms UI bolted on top, and a one-way pipeline whose whole job is to push the result out to a website. The whole thing assumes content equals web pages, edited by humans clicking through forms, rendered to one destination.

Most headless CMSes claimed to escape this hatch, but when you opened the hood you'd still find content stored as HTML blobs, loads of "page"-bound assumptions, and so on. Which isn't strange. It makes the conversation with customers who already thought this way much simpler. But for the last decade, we have made a lot of business on helping customers out of the limitations this approach has when you need your content to do more and for content ops to be automated.

Content as a collection of web pages just didn’t help them into the future.

We are post pages now

So now that every part of that founding assumption has given out, so the machine built on it has to change. That's actually why Sanity was made in the first place. We built it to hold the content of OMA.com in a way that fit their business, which was architectural projects with loads of metadata. Content is not pages. It's product records, pricing, specs, legal language, support answers. It's the structured data an app reads, an email assembles, and another agent queries to do its job. A page is one way content gets rendered, not what it is. And humans clicking through forms is no longer the only way it gets operated on. Agents do it now, on behalf of those humans, at a scale and speed no forms UI was built for.

The future showed up on schedule. The web still has "pages" you can address with a URL, but conversational interfaces are viable now too, and what happens on a single "page" keeps getting more complex: multiple states, single-source-of-truth content pulled from several places, the same content wanting to show up in other channels.

Meanwhile the publish-to-web CMS came with API limits that make it impractical to script against, document locking, and a backend where it's hard to tell who changed what when the change never trickled through a UI. That's not an environment agents thrive in.

So on the symptom, the markdown-in-git crowd, the vector crowd, and I agree: this machine has run its course. We disagree about why, and about what it should become. The web CMS was already straining before AI, and the answer isn't to rebuild it on top of git or a vector database. It's to let it evolve into what humans and agents actually need now.

And that changes the job. If content is more than pages, and agents operate it alongside people, then the thing you're choosing has a narrow, specific job: make it easy for humans and their agents to operate on content. Not to store pages. Not to render a website. To be the place the work gets done, by whoever (and whatever) is doing it.

That takes a set of platform primitives that work together and can be shaped into systems that fit how agents and humans actually work.

Who decides where content lives?

If you're the developer reaching for markdown or vectors, notice whose problem you're solving. A clean repo with no content management UI is a great developer experience, and the frustration with systems that never gave developers one is earned. What developers actually want is a CMS-equal experience for code-shaped work. Content they can version, type, query, and script against with the same fluency as the rest of their stack, without clicking through someone else's forms or having to build new stand-alone applications alongside the CMS thinly veiled as “plugins.” What they want is legitimate. Markdown in a repo just happens to be the nearest thing lying around that delivers it. And to be fair, coding agents are pretty great at git (which is weird because few of us were. Maybe they just actually read the docs).

Content ops is deeply cross-functional

But content operations is not a pure developer function. It is an org function, and the companies that get this right treat content as a business asset, not (just) a marketing one. The product page, the help center, the localized variants, the legal language that has to be exact, the campaign that spans a dozen surfaces. These get operated by editors, localizers, marketers, compliance, the next engineer who inherits the repo, and the agents acting for all of them.

None of those people are in the room on the quiet afternoon a developer decides content is just files now. They find out the next day, when they're told to make a GitHub account to view the diffs of what the agent did and wait for the preview deployment to clear the CI/CD pipeline.

And if they don’t want this, sure, you can vibe code them a dashboard and an MCP and stuff. But now you are building the thing you tried to get rid off in the first place.

What your content platform needs

So the test is not "can an agent touch this." It can. The test is whether the thing you pick makes content easy to operate, over years and across people and their agents. It should meet these probably tip-of-the-iceberg platform requirements:

• A flexible content model that express complex business domains that agents can read and comprehend
• A way to query precisely and search semantically
• A way to express content dependencies by relating content with referential integrity
• A live place to act, where a change can be staged, shown for what it actually is for a human, previewed, and fanned out
• Have governance, permissions, rules for human and agentic operators
• Support concurrent, real-time collaboration

Hold your choice up against those.

Two shortcuts, one mistake

Markdown-and-grep and vectors-and-similarity look like opposites. But they make the same move. Both flatten content into a single primitive, a file or a vector, and swap structure for fuzzy retrieval: lexical in one case, semantic in the other. Neither can answer the questions content operations actually need to ask.

A content team asks for every product over $100, in stock, not yet translated to German, newest first. In structured content that is a query: