Agents need a schema, too

Content modeling is the work of deciding what kinds of content a site has, which fields each one carries, and how they connect, then documenting it all so both human authors and systems like your CMS can organize around this information.

In basic CMS tools like WordPress, you start with a model already in place — content is organized into posts and pages, each of which has fields like title, excerpt, and body, plus relationships to other entities like categories, tags, or authors.

While you can use plugins or PHP code to add custom content types or fields to WordPress, most WP sites rely on those original two models, plus HTML code or shortcodes in the body content of a post, to loosely represent many different kinds of content.

Behind the scenes in WordPress's database, a body is just a text field; even modern WordPress with its Block Editor saves your page or post as a blend of HTML and JSON text that gets unpacked and translated whenever your users request a page. Either way, nothing in that field says what it should contain or how it should be formatted. And even when you do attach custom fields or types, there's little in the way of guardrails to tell AI agents — or, for that matter, human editors — what needs to go where, or to ensure that a new content entry meets all requirements for publication.

This kind of looseness can be useful in some cases. Making a content model too specific or too rigid can make it harder to work with, whereas letting things stay loose gives editors a lot more freedom to decide how content should show up as they're working, rather than stopping to think about how the content model or design system should change to accommodate the chart or table that needs to go out today.

Loose or minimal content models start to become problems when a CMS starts to be used by editors who don't have all the context or human judgment to know what kinds of changes are good or not. That applies when you bring new people onto a content team, but even more so to AI agents, who aren't human and only have as much context as you give them. A good, clear content model takes more consideration than just cramming everything into body, but is also your first line of defense against slop.

So, in an agent-friendly CMS, the content model now has a second job — it defines what information lives on your website, and also how both human and AI editors should work and what's expected of them.

Content modeling in Sanity

In Sanity and other headless CMSes, you build your own content model from the ground up, with Sanity's content model (or schema) living as TypeScript code that both describes your content and tells the Sanity Studio how to present it to you as admin screens and forms. Because your full content model is documented alongside the rest of your code, Claude Code, Codex, and other agents can see both your whole schema and how it connects to the frontend code that turns it into a website.

This differs from headless CMSes like Contentful, where the model usually lives on the server and is edited in a visual tool. Contentful supports code-based migrations, but the server stays the source of truth, so agents fetch the schema over the API or MCP when they need it. Apart from adding another moving part to an already complicated setup, this risks an agent not having as much broad understanding of your content.

In addition to a fully code-based schema, Sanity has a fantastic MCP server and powerful command-line interface — agents can not only understand your content model, but can work with your CMS content as easily as local source code files.

Because agents are so able to work with content hosted in Sanity, content modeling can be based around what will deliver the best workflows and performance. On this site, for example, SEO metadata and the cover image are their own fields, so an agent can draft a post and I can finish those parts in the Studio. That freedom has a flip side: the content model is now the rulebook agents write against, so it should be designed with them in mind.

Four things we do on Sanity builds

When a client plans to let agents write into their CMS, we set up their content model so agents can work freely, with enough context and guardrails to assure their human users that the results will be high quality and won't break anything.

Upload schemas to Sanity's Content Lake. Historically, while the Studio has had robust validation features to ensure content matched the model, the Content Lake backend itself has been schema-less — agents or API clients can simply save whatever to the cloud, potentially breaking both the Studio and frontend. Sanity now allows developers to push their schemas to the cloud, requiring content edits made by agents to match the schema including any validation rules. Your code is still the source of truth, now with an extra line of defense against junk creeping in to your dataset.

Tighter field types and validation. Instead of open text fields, we favor references (i.e. links to other content items), fixed option lists, and minimum/maximum length limits for strings, all with validation rules and clear error message so both human and AI authors know what's wrong and how to fix it.

For example, Rill's pricing page is made of structured data: plans, features, and prices are all set up as distinct fields, with some elements modeled as references to other content items in their Sanity dataset to ensure consistency and allow for reuse.

Sanity MCP's new documents_validate tool (currently in beta) lets an agent check a draft against those rules before it saves, providing faster feedback similar to the inline hints a human author would see in the Studio.

Add a review step before publishing. Agents can help you set up content drafts, but people should always give the content a last look and hit the publish button themselves.

For example, I'm writing this post in a Claude doc, and when it's done I'll ask Claude to copy the finished text into Sanity. Before publishing, I'll open the draft in my Sanity Studio to add SEO metadata, upload a cover image, and do a final copy pass before publishing it myself.

For an upcoming new version of this website, I have agents working on copy and design in tandem, using Sanity's Content Releases feature to separate unreleased pages and strings from what's live in production. When it's time to go live, I'll double check everything in the Studio, then can publish the whole release in one go as soon as the code update is live.

Sanity also runs its own content operations this way — in episode 3 of its "Sanity on Sanity" series , the sales team uses AI to draft updates to competitive battle cards, and those drafts get flagged for a person to review for accuracy and quality before they go out.

Add usage alerts on the client's Sanity project. Sanity plan limits are quite generous, but agents can sometimes make more requests and upload a lot more files than a human editor would. Sanity added spending alerts for organization overage in October, sent by email and visible in the account dashboard, and we encourage turning those on as a precaution in case an overly chatty agent consumes more API calls, storage, or other resources than expected.

To date, the only time we've ever had to react to a Sanity project going over limits was on Stripe City — it turned out 2.3 million API calls in a 5 day period was more than would fit into Sanity's free tier — and most normal content operations (even with agents in the loop) will stay well within bounds. But, because AI systems run semi-autonomously, it's a best practice to have good monitoring and alerts in place for peace of mind just in case something wacky happens, like an agent getting confused and trying to keep your site current by updating a date field once per second.

Sanity is building for agent authors

This month, Sanity made it a lot easier for AI agents to write directly into a CMS, adding support for image and file uploads through the MCP server, whether the file starts as a public URL, a local file, or something in a ChatGPT conversation. Agents could previously sort of work around this using Sanity's CLI — with instructions provided by an MCP call — but direct MCP support is cleaner, faster, and better fit for most use cases.

Also, at their Everything [NYC] developer event in September, the Sanity team released Knowledge Bases and Workflows in closed beta. Knowledge Bases compile content from your datasets into an agent-ready index, so agents can get necessary context faster without stacking multiple GROQ queries or API calls. Workflows provide a state machine-powered governance layer for both human and AI authors, helping to enforce rules like our "agents draft, humans publish" guideline in code. We follow these releases as they ship and bring them into client builds once they're ready.

Before you let agents into your CMS

Most of the talk about agentic CMS setups is about what agents can do. The more useful question is what they're allowed to do. In Sanity, most of that answer lives in your content model: the schema says what goes where, validation says what's acceptable, and a review step says who gets the last word. Agents only know what your content model tells them, so make sure it says enough.

If you're planning to let agents write into your Sanity project, start with a content model review . We'll go through your schema field by field, flag the places an agent is likely to fill with something plausible but wrong, and help you set up validation, a review step, and usage alerts before the first agent draft lands.