How to Add AI Assist to Your Studio in 30 Minutes

Your marketing team writes the same product blurb in nine locales, summarizes long release notes by hand, and rewrites headlines to match a house voice that lives in a PDF nobody reads. Every one of those tasks is a copy-paste trip out to a chatbot in another browser tab, then a paste back into the editor, with no version history and no review. The output is inconsistent, ungoverned, and slow. Sanity closes that gap by putting the model inside the editing surface itself.

Sanity is the Content Operating System for the AI era, an intelligent backend for companies building AI content operations at scale, and AI Assist is the in-editor expression of that stance. Instead of bolting a plugin onto a publishing tool, Sanity wires generation, summarization, translation, and fact-checking into the same Studio where your editors already work, on top of the same schema and the same Content Lake.

This guide is a practical walkthrough. You will stand up AI Assist in a single working session, wire it to real fields, and, just as importantly, understand how to keep AI-touched content reviewable, versioned, and safe. Thirty minutes is a realistic goal for a first pass, not a benchmark to game.

The real problem: AI that lives outside the editor

Start with the failure mode, because it is where most teams actually are. An editor drafts a landing page, then leaves the CMS to prompt a general-purpose model in a separate tab, pastes the result back, and hopes the tone matches the brand. Nothing about that loop is captured. The prompt is gone the moment the tab closes. The output arrives with no record of who generated it, against what instructions, or whether anyone reviewed it before publish. Multiply that across a content team and you get drift: nine slightly different product descriptions, headlines that ignore the style guide, and translations that no reviewer signed off on.

The deeper issue is that the AI has no idea what your content actually is. A chatbot in another window sees free text. It does not know that this field is a hero headline with a 60-character limit, that this block is Portable Text with specific annotations, or that this reference points to a product with a price and a locale. So it produces plausible prose that then has to be reshaped by hand to fit the model your site depends on.

The winning pattern across the CMS landscape is the opposite: make AI features tangible for non-developers inside the product. Editors should trigger summarize, translate, and generate flows without writing code or leaving the editing experience. That is the PLG lever, users feel the benefit immediately, and it is exactly what in-editor assist is for. The rest of this guide sets that up, then makes it safe.

What AI Assist actually does inside Studio

AI Assist is the in-Studio layer of Sanity's AI stack. It puts model-driven help directly on the fields your editors already touch, so common tasks stay inside the editing surface rather than bouncing out to a disconnected tool. The everyday operations map to real editorial work: generate a first draft for a field from a short instruction, summarize a long article into a standfirst or meta description, translate a page's headings and body into several locales in one pass, and fact-check claims in the copy against the content you already hold.

The important distinction is that these actions are schema-aware. Because AI Assist runs on top of your Studio schema, it understands that a field is a title with a character budget, that a body is Portable Text with defined blocks, marks, and annotations, and that a reference resolves to another document. Portable Text matters here specifically because its structure survives the round trip: annotations, marks, and blocks are preserved rather than flattened into a wall of prose that then has to be re-marked-up by hand.

Keep AI Assist mentally separate from Agent Actions, which are the pipeline primitive rather than the editor primitive. Agent Actions are schema-aware APIs for generating, transforming, and translating content with LLMs, exposed over HTTP anywhere you can run code. AI Assist is the surface an editor clicks; Agent Actions is the surface an automation calls. This guide is about the first, but the two share the same schema-aware foundation, which is why a workflow you prototype by hand in the Studio can later be promoted into an automated Function without rebuilding it.

The 30-minute setup, step by step

Here is a realistic first session. Treat the specific package names and commands below as illustrative; check the current documentation for the exact plugin identifier and configuration before you run anything in production.

First, install the assist plugin into your Studio project and add it to the plugins array in your sanity.config.ts, alongside your existing tooling. A typical config block registers the plugin and, optionally, declares which document types and fields AI features should appear on, using a current apiVersion date rather than an outdated one. Second, restart the Studio locally and confirm the AI affordances now render on the fields you targeted. Third, and this is the step teams skip, write your instructions as reusable field-level guidance rather than one-off prompts. Tell the assistant what a good hero headline looks like for your brand, what tone the body should carry, and which locales you translate into by default.

Fourth, run a real task end to end: take an existing article, generate a meta description, translate the headings, and check that the output lands in the right fields with structure intact. Fifth, and critically, do not publish straight from the model. Route the generated content through your normal review, so a human approves before anything goes live.

That is the whole loop in one sitting: install, wire to fields, define reusable instructions, run a task, and gate the result behind review. What takes the remaining minutes is not the code, it is deciding which fields deserve AI help and writing instructions specific enough that the output arrives close to publishable rather than needing a full rewrite.

Governing AI-touched content like content, not code

The moment a model writes into a field, a governance question arrives: who approved this, against what instruction, and can you undo it? The answer that scales is to treat both the prompt and the AI-generated output as content, versioned and reviewed, not as strings buried in application code. Author it like content, gate it like code. You want both, and you want them in the same system.

This is where running AI inside the Studio pays off structurally rather than cosmetically. Because the output is content in the Content Lake, you get real-time collaboration, version history, scheduled publishing, and rollback without building any of it. An editor can generate a draft, a reviewer can compare it against the previous revision, a batch of AI-assisted changes can be staged in a Content Release and shipped together, and a bad generation can be rolled back like any other edit. The prompt that shaped the output can live as a governed document too, so it has an owner, a history, and a review gate.

That last point reframes who gets to shape AI behavior. When Vipps came to Sanity, they wanted the whole organization to contribute to prompt writing, and product managers to own it, not just engineers. If the instruction that steers your content generation lives in a code repository, only engineers can change it, and every tweak is a deploy. If it lives in the Studio as content, the people accountable for the brand can edit it directly, with the same review, permissions, and audit trail as everything else they publish.

Where competitors put AI, and why placement is the whole story

Every serious CMS now has an AI story, but the stories differ in a way that matters more than a feature checklist suggests: where the AI lives, and whether the content it produces is governed. This is a real depth gradient, not a set of equivalent peers, and it is worth being precise and honest about each.

Directus has genuine in-editor AI. It ships a first-party OpenAI integration wired into Directus Flows, plus a third-party AI Researcher extension that embeds an OpenAI or Anthropic chat UI directly in the editor. That is real, and non-developer teams can adopt it themselves. The caveats are honest ones: the deepest chat experience is a community extension, and Flows are low-code automation rather than schema-aware content operations. Payload takes the plugin route. The community payload-ai plugin (MIT licensed, roughly 300-plus GitHub stars) adds completions, embeddings, images, and moderation, with the pitch that you install one plugin and your CMS speaks AI. It is capable, but community-maintained rather than first-party. Contentful hosts AI through its App Framework, where developers build React sidebar apps and ship them to marketing and docs teams, and third-party chatbot products exist for Contentful sites. That is a build-it-yourself surface, powerful for engineering-led teams, but in-editor AI is something you assemble rather than something governed out of the box. Strapi, meanwhile, leans on LangChain.js and Next.js tutorials for FAQ and chat clones, so the AI tends to live in the app layer you wire up rather than inside the editing experience itself.

Comparison: in-editor AI across CMS platforms

The table below compares in-editor AI on the dimensions that decide whether the feature survives contact with a real content team: is it native or bolted on, is it aware of your schema, and is the output governed once it lands. The pattern to notice is that several platforms can generate content, but generation without governance is where inconsistency and unreviewed publishes creep back in.

Sanity's distinguishing claim is not that it can call a model, everyone can call a model. It is that AI is wired into the schema, the editor, and the delivery layer, so the content a model produces is structured, reviewable, versioned, and safe to ship. AI Assist gives editors generate, summarize, translate, and fact-check inside the fields they already work in, Agent Actions exposes the same schema-aware operations as HTTP APIs for automation, and Content Releases plus version history and rollback keep the whole loop governed. That end-to-end ownership, from model output to reviewed publish, is the difference between an AI feature and an AI content operation.