Most content work isn’t creative. It’s routine. Changing the year from 2025 to 2026 across a couple of dozen articles. Finding every broken or outdated link. Checking that each article has all its fields filled in and a description of the right length. Adding alt tags to images that were uploaded two years ago—and much, much more.
None of this takes talent, but all of it takes time, and far more than it seems. For a team running a hundred-article blog, this routine alone can eat up days every month. Not in writing better content, but simply in keeping everything in order.
We live in times of rapid AI development, where teams try to integrate it into almost everything. Sometimes that’s justified; sometimes it’s mostly marketing. Now, lots of routine work is genuinely being handled and optimized with AI. Still, you can’t just feed ChatGPT a few hundred blog posts and hope it will manage them reliably. For dependable upkeep, the model has to work directly with the documents in your underlying content database.
And this is precisely the direction the headless CMS industry is now racing in. Storyblok, for example, shipped FlowMotion - an automation layer that turns CMS events (creation, editing, translation, publishing) into managed workflows and can be triggered, among other ways, by AI agents over the MCP protocol. The goal is shared across the board: less manual “gluing” of tasks through Slack and spreadsheets, more automation and speed, so content teams spend their time on meaning, not coordination.
Sanity made a particularly strong move in this race: it built a full-fledged AI Content Agent right into its CMS, not just another AI writing widget.
I got curious whether the same could be built on Payload, the platform that gives you a lot of freedom to build things like this. It turned out it could. I built an MVP of the agent and then ran it on our blog against the same tasks as Sanity’s agent to compare their capabilities honestly. I have to say, the agent performed well right from the start: a strong result, and I’ll share more on that in the article.
TL;DR
- Payload Content Agent is an AI agent for content operations that lives right inside the Payload CMS admin. We’re rolling out its beta soon.
- It understands the structure of your CMS, works in natural language, and only creates drafts—a human always publishes.
- Tasks that take an editor half a day (link audits, bulk replacement, finding outdated references, deduping meta tags) it handles in minutes.
- In direct tests on the same workloads, the agent already performs largely on par with Sanity’s AI agent, despite Sanity having prepared its platform for this steadily over more than a year. On some tasks the results are comparable; on others, Payload Content Agent is even faster.
- The idea isn’t mine: the concept was set by the market and by Sanity in particular. My contribution is to build it on a more flexible, open foundation (Payload: schema-as-code, open-source, full control over your data).
How much does “tidying up content” actually cost?
For instance, you might need to identify which blog posts link to your “Contact Us” page and the exact URLs they use. It sounds like a five-minute task.
In practice, this is rarely the case, because blogs often accumulate multiple variations of the same link, sometimes as many as seven: https://example.com/#contacts, https://example.com/#mail-us, a bare #mail-us with no domain, a relative /#mail-us, a version with an extra slash, the domain with no anchor at all, even an external link to a third-party service. Seven variants of what should be a single link.
To find that by hand, an editor has to open every article, check the markup, note the URL, and pull it all into a table. Across a hundred articles, that’s half a day of work—and by the end, your eyes glaze over, and some get missed anyway.
This is the real cost of content work. When it isn’t creating something new, it’s the labor-intensive upkeep of what already exists. This is also where an AI agent fits best: uniform operations across the entire body of content, where the work bores a human and mistakes are easy to make. It’s a classic case for automation, and a powerful direction for content ops to grow in.
How Sanity approached it
Credit where it’s due: Sanity didn’t just bolt AI onto the side of its system. It advanced toward this model consistently and steadily, layer by layer—and that approach became my starting point. We’ve covered its capabilities (Agent Actions, Functions, Blueprints) in detail; in short, the path was this:
- MCP first. The Sanity MCP server opened its content to AI agents (Claude, Cursor), enabling content management in plain language.
- Then cloud logic. Functions (event-driven serverless) and Blueprints (infrastructure as code) let logic and content live together in the cloud.
- And only then the agent itself. Agent Actions - schema-aware generate / transform / translate operations, with one detail that matters for safety and the human-in-the-loop model: by default, they create only drafts, rather than editing what’s published.
Worth calling out separately is GROQ, Sanity’s open query language. It lets you work with content surgically: select exactly the documents and fields you need and patch them—even in bulk, with up to 10,000 documents in a single mutation. That’s what makes mass content operations clean and predictable, rather than “find what you need and hope nothing breaks.”
It’s a mature, well-considered toolset. Looking at it, one question comes to mind.
Why Payload
What inspires me isn’t a specific feature, but the concepts themselves: schema-aware operations on structured content, a bridge to the CMS over MCP, and safety through drafts. The question was simple: are those ideas tied to Sanity, or can they be built on a more flexible, open foundation?
They can. I chose Payload. Payload is an open-source, code-first CMS: the schema is described in plain TypeScript code, not configured inside someone else’s UI and hosting. You own the entire data layer - your own database, your models, full control. For building your own tools on top of a CMS - an agent, for instance- it’s an ideal foundation: there’s no closed cloud you have to fit into, just code you can extend however you need.
Payload’s AI layer is still thinner than that of mature SaaS platforms like Sanity—we’ve already written about how to make a Payload site “AI-ready”. A content agent is the next logical step in Payload CMS AI integration. That’s how the Payload Content Agent came about—right inside the CMS.
What is the Payload Content Agent?
In essence, it’s a Payload AI plugin that puts an AI agent right inside the admin—as a chat interface everyone already knows. A content manager describes the task in plain language, and the agent does the busywork.
Three things set it apart from the usual “we just bolted ChatGPT onto a CMS” story:
- It understands your schema. The agent doesn’t rely on a hardcoded list of fields. On startup, it reads your Payload config, collections, fields, and relationships, and builds its own picture of the world from there.
- It runs over MCP. Under the hood, the agent talks to the CMS through the Model Context Protocol—Anthropic’s open standard for connecting AI to data. The Payload CMS MCP endpoint exposes each collection as tools the agent can call.
- It only creates drafts. This is a deliberate, principled decision. And it isn’t “we asked the model to behave”—it’s wired into the set of tools the agent is allowed to use. The toolset is intentionally constrained: delete commands are removed entirely (filtered out for the agent, not just marked as forbidden in a prompt), and every edit goes through an operation that creates a draft while leaving the published version untouched.
The agent never publishes by itself and never deletes content, not because it “promised,” but because it simply has no way to.
Every change it makes is a draft that a human opens, reviews, and publishes. The AI does the grunt work; the decision stays with the team. For a business, that means the speed of AI without the risk of a bot breaking something in production.
What it’s built on
The agent runs on a modern—and, importantly, standard—stack. No homegrown magic that no one will be around to maintain later.
- Vercel AI SDK: the framework for AI agents. A ready, supported foundation instead of a custom engine: faster to build, easier to develop.
- **Model Context Protocol (MCP): **the open standard that lets the agent see your CMS as a set of tools. It automatically adapts to your schema, with no separate integration per project.
- **Different AI providers out of the box: **currently Anthropic (Claude) and OpenAI (GPT). You’re not tied to a single vendor: pick the model that fits the task and budget, and bring your API key into the plugin.
A word on the Vercel AI SDK specifically: out of the box, it handles a whole heap of problems you’d otherwise solve by hand: retries when the model fails, response validation, coercing output into the required shape, and tool calls. I know that pain well from the inside: I first ran into it building a video transcription pipeline on Whisper and its processing through a model—the retries, validation, and response parsing—all had to be debugged and written by hand. With the AI SDK, all of that gets much simpler: less of your code, fewer places to get it wrong.
For a business, the takeaway is simple: it’s predictable, maintainable code that fits into an existing Payload and Next.js project without rewriting the architecture or touching your database. Don’t reinvent the wheel; the agent is assembled from proven, open parts that have strong support of their own and will only keep developing.
So what can it actually do: real-life scenarios
This isn’t a hypothetical list of features. These are real Payload CMS use cases we handle on our blog—and the ones the agent turns from hours into minutes.
Link audits and bulk replacement. Find every mention of a given link across the whole blog and replace them all at once. Those “contact us” link variants? The agent gathered them in seconds and replaced them across all articles in under two minutes.
Finding broken and irrelevant links. Go through the entire set of documents, find links that lead to the wrong place, and propose replacements—in bulk, not one at a time.
Redirects from old URLs to new ones. When a flat part of a site grows into something richer, with categories and topics, you need to carefully maintain a range of routes and redirects. The agent can help prepare the redirect map.
Meta-tag cleanup. Here it’s critical that every article has a valid set of tags - no duplicates, nothing that could hurt SEO. The agent can find the invalid spots and suggest fixes.
Alt tags for images. Add meaningful alt tags where they were forgotten—for accessibility and for search.
Blanket edits across the full set of documents. The dullest and most common of all: change the year from one to another everywhere it appears as current.
Each of these scenarios is hours of an editor’s manual work reduced to a single request. And—important for SEO—the agent can also find internal-linking opportunities a person simply doesn’t hold in their head.
The Payload agent vs. Sanity’s AI agent: how does it hold up so far?
The short answer: on the same tasks, the Payload agent already performs largely on par with Sanity’s agent - even though Sanity got to its agent earlier and far more thoroughly. For an MVP, that’s an excellent result and good motivation to further develop the direction.
We ran an entire set of real content tasks through both agents on the same data—our blog—timing them and watching how efficiently they worked. The table below is only a slice of that run—a representative handful:
| Task | Sanity’s agent | Payload agent |
|---|---|---|
| Find all “contact us” links | 25 sec | 14 sec |
| Which exact URLs are in those links | 1 min 37 sec | 10 sec |
| Verify a supplied list of 17 articles exists in the blog | 18 sec, found 16 of 17 | 22 sec, confirmed all 17 |
| Bulk-replace a link with a test URL | 2 min 12 sec, updated 11 | 1 min 50 sec, updated 11 |
| Find articles with an outdated year | 2 min 47 sec | 20 sec |
| Find mutual internal links | 22 sec, found 5 | 20 sec, found 8 |
What this shows:
Speed - largely comparable. On reading and analysis tasks, both agents work in roughly the same range; on some queries, the Payload agent answered faster, while on others, the difference isn’t large. What matters here isn’t “who’s faster” but that a link audit in ~10 seconds is already a working level, not just a demo. The bigger win is elsewhere: you can ask the agent to do something in passing, rather than setting aside half a day for it. Which means a content manager can spend their time on more important things.
Choosing between them? If you’re weighing Payload CMS vs. Sanity, the real tradeoff isn’t the agent—it’s the foundation. Sanity is a mature, managed SaaS with a polished, years-in-the-making AI layer, delivered turnkey on its cloud. Payload is an open-source and code-first CMS: you host it, you own the data, and you can extend it, an AI agent included—whenever you need it. The comparison above shows that selecting the open, self-hosted route no longer means giving up a capable content agent.
Where both stumble and the real bottleneck for bulk operations
And yet there was one task neither agent managed to execute: appending the same paragraph to the end of every blog post. It sounds elementary—and that’s exactly where things went off track.
Sanity’s agent cheerfully reported the work as complete while, in reality, leaving every post unchanged. Payload’s agent finished the task, but at scale it eventually stalled. Neither outcome counts as a true success. The test may seem contrived, but it neatly illustrates where real efficiency challenges tend to hide.
And here’s what matters more than the failure itself: mass operations aren’t about a “smart model”; they’re about the throughput of the APIs and the way the work is organized. Sanity’s agent runs a good while on bulk tasks and eats numerous tokens. And while the Payload agent was being built, the real question became clear: not “does the model understand the task,” but how many operations you can run in parallel and how fast you hit the rate limits of the AI APIs themselves. The ceiling on mass content editing sits right here—in how well and scalably you build the architecture, not in the model’s smarts.
That’s a reasonable boundary for where things stand today. It isn’t overcome by a “smarter model,” but by engineering: robust task orchestration, splitting the workload across sub-agents that process their chunks in parallel, and—above all—giving each one a compact, legible set of tools. The more precise and efficient those tools are, the fewer wasted calls and burned tokens—and the higher that practical ceiling moves.
AI speed, an engineer’s discipline
When a business first considers using AI for content, the initial question is usually, “Can the model do it?”. In practice, the harder question is a different one—and it’s the one that decides whether you let an agent near real content at all. Getting AI to change content is easy. What’s hard is giving it exactly as much power as it needs to help, and not a gram more, so it speeds the team up while being physically unable to break something in production.
This is where most “AI features for content” fall apart. A model with the right to publish and delete directly isn’t a helper - it’s a risk: one misread request and the edit is live on the site, with the previous version gone. So the agent has three safeguards built in, and all three are about trust, not the model’s “cleverness”:
- A limited set of tools. Dangerous operations (e.g., deletion) aren’t “forbidden in the prompt” - they physically aren’t in the set available to the agent.
- Drafts only. Every edit is a draft on top of the document. The published version stays untouched until a human hits “publish” themselves.
- An independent reviewer. Before a draft is saved, a separate reviewer sub-agent judges whether the edit matches the task. Not “the AI generated and wrote,” but “generated, checked, saved.”
What does that give a business in practice? First, you can hand the agent to a content team instead of keeping a developer alongside to ensure every action—the boundaries are wired into the system itself, not resting on the user’s care. Second, the economics of review change: a human doesn’t redo the AI’s work from scratch; they quickly accept or reject a finished draft. You get the speed of AI without the usual tax of “the bot made a mess, now I’m cleaning up after it.” The real bottleneck in AI content isn’t the model’s intelligence—it’s trust in it. And that’s solved through engineering.
It’s the same logic we use when we use AI to migrate content between CMSs: AI takes on the volume and the routine, while an engineer’s discipline guarantees the result is safe to ship to production and lets you ship it far faster.
The takeaway
Payload proves itself, once again, as a flexible platform for bringing all kinds of ideas to life, and the content agent is just one of them. The agent takes content busywork off the team and lets a business move faster and more efficiently.
That makes “ongoing content operations” a very different kind of engagement: less staff time sunk into link audits and meta cleanup, more room for higher-value work like strategy, UX, and experimentation. Instead of billing for hours of busywork, you can design retainers around outcomes and reliability.
And because the agent is built from standard, open components inside a code-first CMS, it stays yours to shape, not locked behind someone else’s roadmap. You can adapt it for each client, extend it, and ship improvements on your schedule—which is the kind of leverage a modern Payload CMS agency needs.
Even at this stage, the agent holds its own, and where this direction goes next will be worth watching. We’ll certainly keep pushing it forward.
Frequently asked questions
Q: Does the agent publish or delete content on its own? A: No. The Payload Content Agent works in draft mode only: it prepares changes, and a human always publishes them. Deletion is disabled at the tool level, not just forbidden in a prompt. That’s deliberate—so the speed of AI never turns into a production risk.
Q: Will it work with my custom collections? A: Yes. The agent reads your Payload config at startup and discovers your collections, fields, and relationships automatically. Add a new collection, and the agent can work with it right away, with no per-project setup.
Q: How is it different from Sanity’s AI agent? A: Capability-wise, the two are already pretty close — and that’s despite Sanity building toward this on purpose, rolling out MCP first, then cloud functions, then agent actions. In our test, the results were close on some tasks and faster for the Payload agent on others. Both, incidentally, create drafts by default. The main difference isn’t in the features but in the foundation: Payload is open source and code-first, giving you full control over your data.
Q: Do I have to rewrite my Payload project to add the agent? No. It’s a plugin: it fits into an existing Payload and Next.js project without rewriting the architecture. The stack is standard: Vercel AI SDK, MCP, and TypeScript – with memory stored in PostgreSQL.
