How to Make AI Suggestions Inside Studio Feel Native

Most "AI in the CMS" features fail the same way: an editor highlights a paragraph, clicks a sparkle icon, waits three seconds, and gets back generic copy that ignores the brand voice, the surrounding content model, and the locale they're working in. They paste it, regret it, and quietly stop using the feature. The AI didn't feel native, it felt like a chatbot bolted onto the side of the editor through an iframe.

The stakes are higher than a low feature-adoption number. When AI suggestions don't understand your schema, your taxonomy, or your publishing rules, every "helpful" generation becomes a governance liability: untyped text in a typed field, hallucinated facts shipped without review, translations that break referenced content. Editors learn to distrust the tooling, and the promised productivity gain evaporates.

This guide reframes the problem. "Native" AI in the editor isn't a UX veneer, it's an architectural property. Suggestions feel native when the model is wired into your data model, your editorial surface, and your delivery layer at once. We'll walk through what that requires and use Sanity's AI-native architecture as the working example.

Why bolted-on AI suggestions feel foreign in the editor

The tell-tale sign of bolted-on AI is that it doesn't know where it is. A generic LLM panel sees a blob of text; it doesn't see that the text lives in a `body` field of type Portable Text, sitting next to a `seoTitle` string, a `relatedProducts` reference array, and a `locale` field set to `de-DE`. So it returns prose that an editor then has to manually reshape into the structures the schema expects, and any rich formatting, links, or annotations get flattened into plain text on the way in.

That context blindness compounds. Without the content model, the AI can't respect field-level constraints (max length, allowed values, required references). Without the editorial workflow, it can't tell a draft from a published document, so it happily rewrites live content with no review step. Without the delivery layer, it has no idea what's already published elsewhere, so it reintroduces facts you deliberately changed last week.

The result is a feature that demos well and dies in production. Editors don't reject AI because they dislike AI; they reject it because each suggestion creates cleanup work and a small compliance risk. A native experience inverts that: the suggestion arrives already shaped for the field it targets, already in the right voice, already aware of what it's allowed to touch. The difference is not model quality, frontier models are widely available, it's how deeply the model is fused with the content system around it. That fusion is an architecture decision, made long before an editor ever clicks a button, and it is what the rest of this guide unpacks.

Native means schema-aware, not text-aware

The first requirement for native-feeling AI is that it operates on your schema, not on raw strings. A text-aware assistant treats every field as the same kind of input, a paragraph to rewrite. A schema-aware assistant knows that this field is an array of objects, that field is a slug derived from a title, and the one next to it is a reference that must resolve to an existing document of a specific type.

This matters because editors don't write in paragraphs, they write in structured documents. A product page is a title, a hero, a feature list, a spec table, and a set of references. When AI understands that structure, a single instruction like "draft the missing feature bullets from the spec table" can populate the right field with the right type, leaving everything else untouched. When it doesn't, the editor gets a wall of text and a manual re-entry job.

In Sanity, this is what Agent Actions provide: schema-aware APIs for LLM-driven workflows, generate, transform, translate, validate, that read and write the actual content model rather than a flattened export. Because the operations are bound to your schema, a generation respects field types and document shape by construction, not by post-hoc cleanup. Portable Text reinforces this on the content side: it's a structured rich-text format where annotations, marks, and blocks survive the round trip through an LLM, so a suggestion that includes a link or an inline reference comes back as structured data, not as a string with markdown smuggled inside it. Schema-awareness is the line between AI that produces editor-ready output and AI that produces a first draft of a cleanup task.

Put the AI where the work happens, not in a side panel

The second requirement is surface integration. Even a schema-aware model feels foreign if the editor has to leave their document, open a separate tool, copy text out, prompt, and paste back. Context-switching is friction, and friction is what kills adoption. Native AI lives inside the editing surface, acting on the field the editor is already focused on.

There's a spectrum here. The shallow end is a chat window in a sidebar that can answer questions but can't act on the document. The middle is inline actions, select a block, choose "rewrite in a more formal voice" or "translate these headings into eight locales," and watch the field update in place. The deep end is purpose-built apps that live inside the editor and encode a whole workflow, like an AI brief writer that reads a content release and drafts the outlines for every page in it.

Sanity covers this spectrum deliberately. AI Assist is the in-Studio layer of LLM helpers editors actually reach for, generate a draft, summarise a long block, translate field by field, fact-check a claim against a knowledge base, all without leaving the document. The App SDK is the deep end: it lets teams build their own in-Studio LLM apps tuned to their editorial process, so the AI isn't a generic assistant but a colleague that knows this team's content. The point is consistent: the closer the AI sits to the field being edited, the less it feels like a tool and the more it feels like a capability of the editor itself. A suggestion you can accept with one keystroke, without ever breaking flow, is the one editors keep using.

Ground suggestions in your own content, not the model's memory

A suggestion can be perfectly formatted and still be wrong. If the model draws on its training data instead of your content, it will confidently state last year's pricing, an old product name, or a feature you deprecated. Editors catch some of these; the dangerous ones slip through because they're plausible. Native AI grounds its output in your actual, current content, what's sometimes called retrieval-augmented generation, but applied inside the CMS rather than at the agent layer.

The mechanism is semantic retrieval over your own corpus. When an editor asks for a related-products blurb, the assistant should pull the real product documents, not invent specs. When it fact-checks a claim, it should check against your governed sources, not the open web. This requires the content to be queryable by meaning, and it requires those embeddings to stay fresh as content changes, otherwise you're grounding in a stale snapshot.

Sanity's Embeddings Index API and dataset embeddings make content semantically searchable, with embeddings tied to the content itself so freshness is automatic, there's no separate vector pipeline to keep in sync. Knowledge Bases turn sources like PDFs, websites, and support databases into governed, agent-readable content the assistant can draw on. And because the Content Lake exposes real-time subscriptions, retrieval reflects the moment content changes rather than the last batch index. For deeper agent-side retrieval architecture, Sanity Context handles the grounding layer for full agents, but inside the editor, the same principle holds: a suggestion is only native if it's anchored to your truth, not the model's recollection.

Keep AI inside the same governance rails as everything else

The fastest way to make AI feel foreign, and risky, is to let it bypass the controls every other change goes through. If a human edit requires a draft, a review, and a scheduled publish, but an AI suggestion can write straight to live content, you've created a governance hole and an editorial double standard. Native AI is governed AI: its output is a draft like any other, subject to the same review and release process.

This is partly trust and partly compliance. Editors trust AI more when they know nothing it produces ships without a human in the loop. Legal and brand teams accept AI faster when they can see exactly what it changed, when, and who approved it. The audit trail isn't a nice-to-have; in regulated content it's the difference between adoption and a moratorium.

In Sanity, AI-touched content flows through the same Studio workflow as everything else: a generation lands as a draft, an editor reviews it, and Content Releases let teams stage, review, and schedule the change alongside related edits. Functions add the automation layer at the boundaries, translate-on-publish, moderate-on-publish, enrich-on-publish, so AI participates in the pipeline at well-defined, observable hooks rather than as an untracked side effect. The combination means AI suggestions are powerful but never unaccountable. An editor can let the model do real work precisely because the system guarantees that work is still reviewable, reversible, and on the record. That guarantee is what turns a flashy demo into something a content team will actually run their business on.

Designing the suggestion loop so editors stay in control

Architecture gets you native-capable AI; interaction design gets you native-feeling AI. The suggestion loop, how a proposal is offered, reviewed, accepted, or rejected, determines whether editors feel augmented or overridden. The goal is for the human to remain the decision-maker while the machine does the typing.

Good loops share a few properties. Suggestions are scoped: they target a specific field or block, so the editor can reason about exactly what will change. They're previewable: the editor sees the proposed result before it commits, ideally as a diff against the current value. They're reversible: accepting is one action and undoing is another, with no data lost in between. And they're explainable: when AI fact-checks a claim or pulls in a related document, it shows the source so the editor can verify rather than trust blindly. A loop that violates these, that rewrites silently, or replaces a whole document when the editor wanted one sentence, feels like fighting the tool.

This is where schema-awareness, surface integration, grounding, and governance converge into one experience. AI Assist offers field-scoped actions an editor invokes deliberately; Agent Actions execute them against the schema so the change is well-typed; grounding gives the suggestion verifiable provenance; and the Studio draft-and-release flow makes acceptance a reviewable step rather than an irreversible commit. Built this way, the AI never surprises the editor, it proposes, the editor disposes, and every proposal is shaped, sourced, and safe. That is what "native" actually means in practice: not a smarter chatbot, but suggestions that behave like a natural extension of the editing surface, because the whole system was designed for them rather than around them.