Overview
Sanity is a developer's CMS, and that is its strength. A typed schema, a queryable content lake, GROQ, separate datasets for staging and production, a draft model that keeps unpublished work safely invisible. It is an excellent system for building on — and precisely because it is so structured, the day-to-day operation of it tends to need someone who understands the structure.
A Sanity CMS AI assistant closes that gap. It reads your actual schema and content graph, so it knows what a document type requires, which references are valid and where a slug lives. You ask in plain language — find every post missing a meta description, change this price across the whole catalogue, draft a case study from this brief and schedule it — and the work arrives as proper documents with every required field completed, not a wall of text for someone to tidy up later.
It is worth being clear about what makes this different from the AI features built into a CMS. In-product assistants generally help you write faster inside a single field. This operates the whole project: querying, patching, publishing, managing assets, and — when you want it — changing the schema and the front-end code that renders it, all under role-based permissions and an audit trail.
How it works
- Connect your Sanity project and choose which dataset the assistant may write to.
- It reads your schema and queries the content lake with GROQ to understand what already exists.
- You ask for the change; documents are created or patched as drafts, with required fields and references resolved.
- Before a bulk change runs you are told how many documents are affected and shown a sample.
- You review in the portal or in your own Studio, then publish — and the change is logged and reversible.
What you can ask for
- Content operations — create, patch, publish, unpublish and delete documents of any type in your schema.
- Queries in plain language — answered with GROQ against your real content lake rather than guessed at.
- Bulk edits — a phrase, price or product name changed consistently across hundreds of documents in one operation.
- Portable Text work — rich-text bodies built with the right block and mark types, not pasted HTML.
- Assets — stock photography sourced, images generated or processed, then imported into your asset library.
- Schema and front-end changes — new fields or document types, and the templates that render them.
Why teams use it
- Schema-aware — drafts arrive valid, with slugs, excerpts, references and metadata already populated.
- Beyond the Studio — one assistant for content, code, images and reporting rather than a writing aid in one field.
- Drafts and datasets — Sanity's own safety model is honoured rather than worked around.
- Audited and reversible — every patch attributed and rollback-ready, including whole bulk operations.
Staying in control
Writes are scoped by role — by dataset, document type and action — so a writer can draft their section while only an editor can publish it. A denial is a full stop: the assistant reports it plainly, saves the work as a draft and offers to request approval from a colleague who can authorise it, rather than retrying or switching dataset to get around the block.
Every document is read before it is edited and read back afterwards to confirm the patch landed as intended, which matters most in a typed schema where a malformed reference is easy to introduce and tedious to find.
Availability
Sanity is supported on every plan. Separate staging datasets and custom roles are included on Growth, Scale and Enterprise.
Frequently asked questions
How is this different from Sanity's own AI Assist?
AI Assist works inside the Studio to help an editor fill in and improve fields. This operates the whole project from outside it — querying the content lake, patching and publishing across many documents, managing assets, and changing schema and front-end code — with role-based permissions, approval routing and an audit trail across all of it. They coexist happily; they solve different problems.
Does it understand GROQ and our custom schema?
Yes — it queries with GROQ and reads your actual schema rather than assuming a generic blog model. That is why it can answer questions about what exists and produce documents that validate first time, including correctly shaped slugs, references and Portable Text bodies.
Will it publish straight to our production dataset?
Only if you ask it to and your role allows it. The default is a draft, which in Sanity stays invisible to your front end until promoted. If you have a staging dataset, work can be done there first and promoted after review.
Can it change our schema?
It can, and it treats that as higher-risk work: the impact is explained and explicit confirmation required before anything is committed, because a schema change affects every document of that type. Schema files are edited in your repository as readable diffs your developers can review or revert.
Can our editors carry on using the Studio?
Absolutely — nothing changes for them. Sanity remains the source of truth and the Studio remains the editing interface; the assistant is simply another way to get work into the same content lake, useful for the jobs that are tedious to do by hand.
What about a bulk change that goes wrong?
You see the scope before it runs — how many documents and a sample of the exact change — and the whole operation is recorded as a single action you can roll back in one click. Undoing a price change across two hundred documents is one request, not two hundred.
