Sanity's Agent Context: What a CMS Owes an AI Agent

Photo by Bluestonex on Unsplash

Picture the failure everyone has already had. A content team points an agent at a product-page dataset and asks it to "update the pricing copy for the EU region." The agent reads a few documents, pattern-matches on a field called price, and confidently rewrites a string that turns out to be a reference to a shared block used on 340 pages. Nothing errors. The build succeeds. The mistake ships.

That scenario — not the demo where an agent drafts a blog post — is the actual problem Sanity is pointing at with Agent Context, a feature the structured content platform announced to make its CMS work better with AI agents. According to Google News, which surfaced the coverage via marketscale.com, Sanity positioned the addition as a way to make its content consumable and actionable by autonomous systems. Our read: the interesting part is not "agents can now read your CMS" — they already could — but that the industry is finally admitting retrieval was never the bottleneck.

One caveat up front, and it matters for how much weight you give anything below. As of September 13, 2026, the specific launch date, pricing tier, and any adoption figures for Agent Context could not be independently verified from the available reporting — research tooling failed to return the primary announcement. So this piece treats the feature as a signal about an architectural pattern, not as a product review. Numbers that don't exist won't be invented here.

The Pattern: Context Is Not Retrieval

Strip the branding off and Agent Context sits in a category that has been forming across data platforms since roughly 2024 — the same wave that produced the Model Context Protocol (MCP) and the flood of "MCP server for X" announcements that followed. The market context is unambiguous: content and data platforms are racing to expose structured context and tooling so LLMs can read, reason over, and act on what they store.

Here's what the surface reporting misses. A headless CMS like Sanity was already agent-friendly by accident. It has a query language, it returns JSON, it has a schema. An agent with an HTTP tool and an API token could hit a Sanity dataset on day one of the GPT-4 era. Nothing stopped it.

What stopped it from being useful was everything a schema doesn't encode:

• Intent. A field named slug is a string. Whether changing it breaks 200 inbound links is not in the type definition.
• Blast radius. Portable Text blocks and document references mean one edit can fan out across a site. A schema describes shape, not reach.
• Editorial convention. "Headlines are sentence case, never title case, and never end in a period" lives in a Notion doc, a Slack thread, or somebody's head. Never in the CMS.
• Authority. Which documents are canonical versus drafts versus stale experiments the team forgot to delete.

Agent Context, as a category of feature, is the platform saying: we will carry that layer for you, in the system of record, next to the content. That's a meaningfully different claim from "we added an API."

And it's the correct instinct. The failure mode in agentic content work has almost never been "the model couldn't find the document." It's been the model finding the document and having no idea what it was allowed to do with it.

Implementation: What This Looks Like When a Backend Dev Squints at It

Concretely, the architecture splits into two very different surfaces, and conflating them is where teams get hurt.

Read path. The agent needs a shaped slice of the dataset, not the dataset. This is where context window blowups start — a naive "fetch all documents of type article" against a real production dataset will happily return several megabytes of Portable Text, blow past the window, and either error out or, worse, silently truncate so the agent reasons over half the picture. The sane pattern is a projection: query for exactly the fields the task needs, resolve references one level deep at most, and strip rich-text bodies down to plain text before they hit the prompt.

Write path. Completely different risk profile, and this is where Agent Context as a concept either earns its keep or doesn't. A read that goes wrong wastes tokens. A write that goes wrong ships to production. The pattern that holds up: agents propose patches, not documents. A mutation against a draft, with the document ID and revision hash pinned, reviewed by a human, then published. Never a direct write to a published document.

A useful mental model — sort every tool call by blast radius, not by how risky the model "seems." Reading a draft is zero blast radius. Writing a draft is near-zero. Publishing is irreversible in practice, because the CDN has already served it and someone has already screenshotted it. This is the same discipline that AI Agent Security analysis applied to tool permissions after the Anthropic misuse reporting: the boundary that matters is the one between reversible and irreversible actions, not the one between "safe" and "unsafe" models.

Where does the platform-native version beat rolling your own? Do the arithmetic on maintenance, not on features. A self-built context layer is three things you now own: a schema-to-prompt serializer, a set of guardrail rules, and a sync job that keeps both in step as the content model evolves. Content models change — a new field here, a deprecated type there — call it a handful of schema changes a month on an active project. Every one of those is a potential silent drift between what the agent believes the schema is and what it actually is. The platform-native version collapses that maintenance surface to zero because the context is the schema. That's the real argument, and it has nothing to do with AI.

Photo by Team Nocoloco on Unsplash

Who Wins Under Which Condition

Here's the comparison no single announcement post will give you, because each vendor only argues its own side. Three ways to give an agent access to a content platform:

Raw API plus a hand-written system prompt. Fastest to stand up — an afternoon. You paste a summary of your content model into the prompt and hope. Wins when: you have one content type, a small team, and the agent is doing read-only summarization. Breaks when: the schema changes and nobody updates the prompt. Drift is invisible until an agent writes to a field that no longer exists.

A generic MCP server in front of the CMS. Standardized transport, works across multiple agent clients, portable if you switch models. Wins when: you're already running several MCP integrations and want one auth and audit story. Breaks when: the server exposes generic query and mutate tools with no domain semantics — you've standardized the plumbing and changed nothing about the agent's judgment. MCP is a transport, not a trust boundary.

Platform-native context (the Agent Context approach). The vendor maintains the mapping between content model and agent-legible context. Wins when: your content model is genuinely complex — deep reference graphs, many locales, heavy Portable Text — and it changes often. Breaks when: you need agent access across several systems at once, because now your context layer is CMS-shaped and your CRM, analytics, and commerce data aren't in it.

The skeptic's pushback, stated fairly: this is vendor lock-in wearing an AI costume. Structured content was the entire pitch for headless CMS a decade before agents existed — schemas, typed fields, API-first delivery. Adding a layer that says "and now it's for agents" could be a marketing reframe of capability that shipped years ago.

That objection is half right. The schema part genuinely isn't new. But the objection misses the write path. Nothing in the original headless pitch addressed what happens when a non-deterministic caller with no institutional memory issues a mutation. Read access was solved in 2016. Supervised, reversible, convention-aware write access was not. If Agent Context only formalizes the read side, the skeptic wins. If it addresses proposal-and-review on the write side, it's a real addition.

Where It Breaks in Production

Four failure modes to design against before anything touches a production dataset.

Tool-call loops on reference resolution. Content graphs have cycles. An article references an author, the author references featured articles, one of which is the original article. An agent doing depth-first reference resolution with no visit set will happily walk that circle until the context window fills. Cap traversal depth explicitly. Do not trust the model to notice.

Stale context between read and write. The agent reads a document, spends ninety seconds reasoning, then writes. In that window a human editor also saved. Without an optimistic-concurrency check — pin the revision, reject the mutation if it moved — the agent silently clobbers the human. This is the single most likely production incident in agentic CMS work, and it is not an AI problem at all. It's a 1990s database problem wearing new clothes.

Confident wrong publishes. Models are fluent. Fluent wrong copy passes a skim review in a way that a broken build never would. Keep publish behind a human gate. Not because the model is bad, but because the error class is quiet.

Evaluation drift. If you can't answer "did the agent's edits get better or worse this month," you're flying blind. Eval-driven development applies here as much as anywhere: a fixed set of representative content tasks, a rubric, and a run on every prompt or model change. Teams that skip this discover regressions through their editors' complaints, which is the slowest and most expensive detection channel available.

Bottom Line

On balance, our analysis is that platform-native agent context is a genuine architectural improvement and an overstated product story at the same time. The improvement is real: moving editorial convention and blast-radius information out of Slack threads and into the system of record is the single highest-leverage thing a content platform can do for agentic workflows, and it pays off whether or not the agent hype holds. The overstatement is that none of this makes an agent trustworthy on the write path — it only makes it better informed, which is not the same thing.

Who should move now: teams with a complex, frequently-changing Sanity content model and a real backlog of mechanical content work — localization sweeps, metadata backfills, schema migrations. Who should wait: anyone whose content model fits on one screen, and anyone hoping to skip the human review step. The review step is the product. Remove it and you've built a very expensive way to generate plausible mistakes.

The more likely outcome over the next year is that "agent context" stops being a feature name and becomes table stakes — every serious content and data platform ships some version of it, and the differentiation moves to who handles the write path with the most restraint.

Frequently Asked Questions

Disclaimer: This article is editorial commentary for informational and educational purposes only. It does not constitute financial, legal, or implementation advice, and it does not reflect independent hands-on product testing by this publication. Product capabilities, pricing, and availability change; verify details with the vendor directly before making purchasing or architectural decisions. Research based on publicly available sources current as of September 13, 2026.