Does Payload CMS Have an AI Content Agent? We've Built One: Let's Compare It to Sanity's

Most content work isn’t creative. It is systematic and detail-driven, it’s routine. It involves updating publication dates across dozens of articles, identifying and resolving broken or outdated links, ensuring every entry meets structural and metadata requirements, and refining elements such as descriptions to align with length and SEO standards. It also includes adding alt text to legacy images retroactively, along with many other essential maintenance tasks that support content performance and consistency.

None of this takes talent, but all of it takes time, and even more than it seems. For a team running hundreds of blogs, this routine can take 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 wondered whether the same could be built on Payload—a platform specifically designed to give developers the freedom to architect custom solutions. As it turns out, it’s absolutely possible.

I’ve 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’vecovered its capabilities (Agent Actions, Functions, Blueprints) in detail; in short, the path was this:

• MCP first. The Sanity MCP serveropened 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 inspired me was not a specific feature but the underlying ideas: schema-aware operations on structured content, an MCP bridge to the CMS, and the safety of a draft-first workflow. The question was straightforward: are these ideas unique to Sanity, or can they be built on a more flexible and open foundation?

They can. I chose Payload.

Payload is an open-source, code-first CMS. Its schema is defined in TypeScript rather than configured through a vendor-controlled interface and hosting platform. You own the entire stack: the database, the content models, and the infrastructure. That makes Payload an ideal foundation for building custom tooling on top of a CMS, including AI agents. There is no closed platform to work around, only code that can be extended to fit your needs.

Payload’s AI capabilities are still less mature than those of established SaaS platforms such as Sanity. We’ve already written about how to make a Payload site “AI-ready”, and a content agent felt like the natural next step in that evolution. The result was the Payload Content Agent, built directly into the CMS.

What is the Payload Content Agent? #

Payload Content Agent is an AI plugin that brings an AI agent directly into the Payload admin interface through a chat experience editors already understand. A content manager describes a task in plain language, and the agent handles the repetitive work.

What makes it different from the usual “we embedded ChatGPT in a CMS” approach comes down to three things:

1. It understands your schema. The agent does not rely on hardcoded field definitions or custom mappings. On startup, it reads your Payload configuration, including collections, fields, and relationships, then builds its own understanding of the content model. Because of that, it can work with the structure of your CMS rather than treating it as generic text.
2. It operates through MCP. Under the hood, the agent communicates with Payload through the Model Context Protocol (MCP), Anthropic’s open standard for connecting AI systems to data and tools. The Payload MCP endpoint exposes collections and operations as tools the agent can call, giving it a structured and reliable way to interact with content.
3. It only creates drafts. This is a deliberate architectural decision, not a prompt-level instruction. The agent’s capabilities are constrained by the tools it can access. Delete operations are removed entirely, and every modification is routed through a draft-creation workflow that leaves published content untouched.

The agent cannot publish content on its own and cannot delete content. Those safeguards do not depend on the model following instructions. They are enforced by the system itself because the necessary tools simply are not available to the agent.

This combination of schema awareness, MCP-based access, and draft-only safety makes the Payload Content Agent feel less like a chatbot attached to a CMS and more like a content operations tool built specifically for structured content.

Every modification created by the agent is stored as a draft. Nothing reaches production until a human reviews and publishes it. The AI does the heavy lifting; editorial control stays firmly with the team. That delivers the efficiency of AI while preserving the safeguards businesses need.

What it’s built on #

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 theVercel AI SDKspecifically: 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 avideo transcription pipeline on Whisper and its processing through amodel—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.

Real-World Payload CMS Use Cases the Agent Automates #

This is not a feature wishlist. These are real content operations tasks we perform on our blog and client projects, and the kinds of workflows the Payload Content Agent reduces from hours of manual effort to a single request.

1. Bulk link audits and URL replacement Find every instance of a link across your website and replace it in one operation. Whether you’re updating a “Contact Us” page, migrating resources, or fixing outdated URLs, the agent can identify every variation and apply changes across hundreds of documents in minutes.
2. Broken link detection and link maintenance Scan all content for broken, outdated, or irrelevant links. The agent can surface issues at scale and suggest suitable replacements, helping maintain site quality and SEO performance.
3. Redirect mapping during site migrations When a content structure evolves from a flat hierarchy into categories, topics, or landing pages, redirects become critical. The agent can analyze existing URLs and help generate redirect maps to preserve traffic and search rankings.
4. SEO metadata and tag cleanup Review articles for duplicate, invalid, or inconsistent tags and metadata. The agent can identify issues that affect content organization, discoverability, and search engine optimization, then suggest corrections.
5. Image alt text generation Automatically add meaningful alt text to images that are missing descriptions. This improves accessibility, helps meet compliance requirements, and provides additional context for search engines.
6. Site-wide content updates Apply repetitive changes across an entire content library. Common examples include updating years, company names, legal disclaimers, product terminology, CTAs, or brand messaging everywhere they appear.
7. Internal linking opportunities Analyze your content inventory and identify relevant pages that should link to one another. The agent can uncover internal linking opportunities that are difficult for editors to spot manually, strengthening content discoverability and SEO.

Each of these tasks is tedious, repetitive, and error-prone when performed manually. With the Payload Content Agent, they become conversational requests executed against structured content. Editors spend less time on content maintenance and more time on creating and reviewing content that matters.

Payload Content Agent vs. Sanity AI Agent: How Does It Compare? #

The short answer: surprisingly well.

On the same real-world content operations tasks, the Payload Content Agent already performs at a level comparable to Sanity’s AI Agent, despite Sanity having a significant head start and a much more mature AI feature set. For an MVP, that’s an encouraging result and strong validation of the approach.

To evaluate both systems, we ran a benchmark using our own blog as the dataset. We gave each agent the same set of content management and SEO tasks, measured completion times, and reviewed the quality of the results.

The goal was not to create an artificial benchmark. We just wanted to understand how both agents perform on the kinds of tasks content teams handle every day: bulk content updates, internal linking improvements, metadata cleanup, redirect preparation, reference management, and page assembly.

The table below shows a representative sample of those tests. While it is only a subset of the full evaluation, it captures the patterns we observed across the entire task set.

What the Results Tell Us #

1. Speed: Payload and Sanity Are Already Comparable #

In day-to-day content operations, both AI agents perform in a similar range. Some tasks were completed faster by the Payload Content Agent, while others favored Sanity’s AI Agent. The difference is less important than what both tools make possible.

A link audit that once required hours of manual work can now be completed in seconds. Bulk content updates, internal linking reviews, metadata checks, and redirect analysis become quick conversations rather than projects that consume half a day.

The real productivity gain is not shaving a few seconds off execution time. It’s eliminating the operational overhead that prevents content teams from tackling these tasks in the first place. Editors spend less time on maintenance and more time creating, optimizing, and publishing content.

2. Payload CMS vs. Sanity: The Real Decision Is the Platform #

If you’re evaluating Payload CMS vs. Sanity, the key consideration is not the AI agent. It’s the underlying CMS platform.

Sanity is a mature SaaS CMS with a highly polished AI experience built over several years and delivered as part of its managed cloud platform.

Payload CMS is an open-source, code-first CMS that gives teams full ownership of their infrastructure, database, content models, and integrations. Because the platform is fully extensible, AI capabilities can be adapted to fit existing workflows rather than being limited to a vendor-defined environment.

The comparison above demonstrates an important shift: choosing an open-source CMS no longer means giving up advanced AI-assisted content operations. Teams can have both the flexibility of a self-hosted platform and a capable AI content agent that handles real-world editorial, SEO, and content management tasks at scale.

3. The Bigger Takeaway: AI-Powered Content Operations Are Becoming a CMS Feature #

The most encouraging outcome is not that one agent is faster than the other. It’s that AI-powered content management is becoming practical for everyday editorial work.

Link audits, bulk edits, SEO cleanup, metadata management, redirect planning, and internal linking analysis are all tasks that traditionally consume hours of manual effort. With schema-aware AI agents operating directly inside the CMS, those workflows can increasingly be handled through natural-language requests while keeping human review and publishing decisions firmly in place.

For content teams, that means faster execution, lower operational costs, and more time spent on content strategy rather than content maintenance.

Where both stumble and the real bottleneck for bulk operations #

Here’s a cleaner version with better flow, fewer interruptions, and no em dashes:

Yet there was one task neither agent truly completed: appending the same paragraph to the end of every blog post. It sounds simple, which is precisely why the result was so revealing.

Sanity’s agent confidently reported the task as complete while leaving every article unchanged. Payload’s agent did perform the updates, but eventually stalled when processing the full dataset. Neither outcome can be considered a success. The scenario may seem artificial, but it exposes a challenge that appears repeatedly in real-world content operations.

More importantly, the limitation was not the model itself. Large-scale content operations are rarely constrained by intelligence. They are constrained by throughput, orchestration, and system design.

Sanity’s agent can spend a long time processing bulk tasks while consuming large numbers of tokens. During the development of the Payload Content Agent, it became clear that the critical question was not whether the model understood the request. The real question was how many operations could run in parallel and how quickly the system would encounter API rate limits.

This is where the current ceiling for large-scale AI content management sits. The challenge is not solved by a more capable model. It is solved through engineering.

Effective bulk editing requires robust task orchestration, workload distribution across multiple sub-agents, and parallel execution wherever possible. Just as important is giving agents a compact, well-designed set of tools. The more precise those tools are, the fewer unnecessary API calls they make, the fewer tokens they consume, and the higher the practical throughput of the system.

In other words, the future of AI-powered content operations will be determined less by model intelligence and more by architecture. The winners will be the systems that can coordinate work efficiently, operate within rate limits, and scale reliably across thousands of pieces of content.

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 this mean for a business in practice? #

First, you can give the agent directly to the content team instead of pairing every workflow with a developer. The guardrails are built into the system itself. They do not depend on users being careful or remembering what the agent should and should not do.

Second, it changes the economics of review. A human no longer recreates the work from scratch. They review a completed draft, make adjustments if needed, and approve or reject it. The AI handles the repetitive work, while the team keeps control over what goes live.

That delivers the primary benefit organizations want from AI: speed without the hidden cost of cleaning up mistakes afterward. The real bottleneck in AI-assisted content operations is not model intelligence. It is trust. And trust is ultimately an engineering problem.

The same principle guides how we use AI to migrate content between CMSs. AI handles the volume, repetition, and pattern matching. Engineering discipline ensures the output is reliable, auditable, and safe to deploy to production. The result is not just automation, but faster delivery with significantly lower operational risk.

In other words, the most valuable AI systems are not the ones that replace human judgment. They are the ones that let teams apply that judgment only where it matters.

The takeaway #

Payload proves once again that it’s a flexible platform for bringing all kinds of ideas to life, and the content agent is just one example. By taking content maintenance and operational busywork off a team’s plate, it enables businesses to move faster and work more efficiently.

That shifts ongoing content operations into a fundamentally different kind of engagement. Instead of spending valuable staff time on link audits, metadata cleanup, and other repetitive tasks, teams can focus on higher-value work such as strategy, user experience, and experimentation. Agencies can move beyond billing for routine maintenance hours and instead build retainers around outcomes, reliability, and continuous improvement.

Because the agent is built with standard, open components inside a code-first CMS, it remains fully adaptable. You’re not constrained by another company’s roadmap. You can tailor it to each client, extend its capabilities as needed, and release improvements on your own schedule. That’s exactly the kind of leverage a modern Payload CMS agency needs.

Even at this early stage, the agent performs impressively. Where this direction leads next will be worth watching, and we’ll certainly keep pushing it forward.