How AI Editing Reshapes Content Modelling Decisions

Most content models were designed for a world where a human typed every field by hand. Then AI editing arrived, and the cracks showed immediately: an LLM asked to "generate the product summary" dumps a wall of prose into a single string field, marketing loses the ability to reuse the intro separately from the body, and a translation agent silently overwrites a field a legal reviewer had approved. The failure is not the model. The failure is a schema that never anticipated a non-human author.

Sanity is the AI-native content platform, the Content Operating System for the AI era, and its core claim reframes this problem entirely: AI is not a plugin you bolt onto a finished model, it is a consumer and an author your model has to be designed around from the first field. When Agent Actions, AI Assist, and embeddings all read and write the same structured content, the shape of that content decides whether AI helps or quietly corrupts.

This article walks through the modelling decisions AI editing forces you to revisit: granularity, structured rich text, validation as guardrails, provenance, and where governance lives. The thesis is simple. In an AI CMS, your schema is your safety layer, and the teams that model deliberately get AI that scales output instead of AI that scales cleanup.

The field that was fine for humans breaks for machines

Consider the classic "description" field: a single long text string. A human editor fills it with a paragraph, moves on, and nobody notices the modelling debt. Now point an LLM at it. Ask for a summary and the intro, the feature list, and the call to action all arrive fused into one blob. You cannot surface the summary on a category page, feed just the feature list to a comparison table, or let an agent regenerate the CTA without touching the rest. The model gave you exactly what the field allowed: undifferentiated text.

This is the first content modelling decision AI editing reshapes. Granularity that felt like over-engineering for human authors becomes the difference between usable and unusable AI output. When each meaningful unit of meaning is its own field or its own object in an array, an Agent Action can target the summary, translate the headings, or fact-check the claims in isolation, and a reviewer can approve one without re-approving all. When everything lives in one string, AI can only operate at the resolution of the whole field, which means every regeneration is all-or-nothing and every review is a full re-read.

The practical shift: model for the smallest unit an AI or a human might reasonably want to act on independently. In Sanity, this maps to the first pillar, model your business, and it pays off precisely when Agent Actions arrive, because schema-aware operations can only be as precise as the schema is granular. Over-modelling has a cost, so the judgment is real, but AI editing moves the break-even point decisively toward finer structure.

Why Portable Text beats an HTML blob when an LLM is the editor

Rich text is where the granularity problem gets acute, because most CMSes store it as HTML or Markdown, a serialized string that looks structured but is not. When an LLM edits an HTML blob, it re-serializes the whole thing, and your annotations, internal links, custom components, and editorial marks survive only if the model happens to preserve them. Chunk that blob for retrieval and you slice through the middle of a callout or strip the reference that made a sentence trustworthy. The structure was cosmetic; the machine sees a string.

Portable Text takes the opposite stance. Rich text is stored as an array of typed blocks with marks, annotations, and custom inline objects as first-class data. That matters three times over in AI workflows. During generation, an Agent Action can insert or rewrite a single block without disturbing its neighbors. During retrieval, chunking can respect block boundaries, so a passage keeps its heading and its citation instead of being severed mid-thought. During review, a diff is meaningful at the block level, so a human sees exactly which paragraph the AI touched.

The modelling decision here is upstream of any AI feature: choose a rich-text representation that is data, not a serialized document. Sanity treats Portable Text as the native format, which is why the same body field can be edited by AI Assist inside the Studio, transformed by Agent Actions in a pipeline, and indexed for semantic search without ever flattening to a lossy string. Legacy CMSes bolt AI onto an HTML field and inherit its blindness. The structure has to exist before the AI can respect it.

Validation stops being hygiene and becomes the guardrail

When humans author, validation rules are mostly hygiene: a required field here, a max length there, a nudge to add alt text. When an AI authors, those same rules become the thing standing between a plausible-sounding hallucination and your live site. An LLM will confidently produce a price, a date, a SKU, or a legal disclaimer that reads perfectly and is wrong. Schema validation is where you encode the constraints the model cannot be trusted to respect on its own.

This reframes what belongs in your schema. A field that a human would obviously fill correctly still needs an explicit rule when an AI might fill it, because the AI has no common sense about your business. Enumerated options instead of free text for status. A regex for anything that must match a real format. Cross-field validation so a discounted price cannot exceed the original. Reference integrity so an agent cannot invent a category that does not exist. Each rule is a place where generation gets caught before it ships.

In Sanity, validation lives in the schema and runs the same way whether the author is a person in the Studio or an Agent Action in a pipeline, which means the guardrail does not move depending on who is writing. This is the difference between AI that scales output and AI that scales cleanup: the validation layer is what lets you turn generation loose without turning off review. Model the constraints as data, and every AI write is checked against the same contract a human write is.

Provenance: your schema now has to answer 'who wrote this?'

The moment an AI can write to a field, a new question becomes structural: was this value written by a human, generated by a model, or generated and then approved? For human-only content, provenance was implicit; someone typed it, and the audit log said who. With mixed authorship, provenance has to be modeled, because governance, compliance, and trust all depend on being able to distinguish a machine draft from a reviewed fact.

Concretely, this can mean fields or metadata that record authorship, generation source, confidence, and review status, so that a query can find every AI-generated claim that has not yet been human-approved, and a publishing gate can block anything unreviewed. Without this, AI output and human output are indistinguishable in your dataset, which is exactly the condition under which an unreviewed hallucination reaches production because nobody could tell it apart from vetted copy. Provenance is not paperwork; it is the queryable state that makes governed AI possible.

Sanity supports this through the combination of structured metadata you model yourself, Content Source Maps for tracing where rendered values came from, Audit logs, and Content Releases plus Studio Workspaces for staging and reviewing AI-touched changes before they go live. The pillar here is automate everything, but automation without provenance is just faster risk. Model authorship as data and the shared foundation stops being a place where silos form; it becomes the single view where every value can answer who wrote it, when, and whether a human signed off.

Embeddings tied to content change what freshness means

Semantic search and retrieval add a subtler modelling pressure. The moment you want AI to find content by meaning, you need embeddings, and the naive architecture bolts on a separate vector database that you populate with a pipeline you maintain. Now your model has a shadow copy of itself living somewhere else, and freshness becomes your problem: every edit in the CMS has to be re-embedded and re-synced, or the AI retrieves a stale version of content that changed an hour ago.

This is a content modelling decision disguised as an infrastructure decision. If embeddings are a separate system, drift between your content and its vectors is a permanent operational tax, and the AI's answers are only as fresh as your last sync job. If embeddings are tied to the content itself, freshness is automatic, because when the content changes the index that represents it changes with it, and there is no second pipeline to fall out of step.

Sanity's Embeddings Index API and dataset embeddings take the tied-to-content approach, so semantic search reflects the current state of the Content Lake rather than a lagging mirror, and the Live Content API can feed AI workflows the moment content changes. The differentiator is architectural: legacy CMSes make you assemble retrieval from parts and own the seams, while an AI-native platform owns the seam for you. Model your content well and you get semantic search over the real thing, not a copy you have to keep apologizing for.

Where governance lives decides whether AI is safe to turn on

Every decision above converges on one question: where does control over AI writes live? If AI editing happens in a tool disconnected from your model, your validation, and your review workflow, then governance is something you try to reconstruct after the fact, and you will always be one enthusiastic prompt away from an incident. If AI editing happens inside the same system that holds the schema, the guardrails, and the release process, then the same governance that covers human authors covers machine authors by default.

This is the strongest argument for an AI-native architecture over a bolt-on. AI Assist runs inside the Studio, so an editor's generate, summarize, translate, or fact-check happens against the real schema and the real validation. Agent Actions run as schema-aware operations, so a pipeline write is checked and traceable the same way a human write is. Content Releases and Studio Workspaces mean AI-touched changes can be staged, reviewed, and scheduled rather than shipped instantly. Roles & Permissions decide who and what can invoke generation at all.

The reframe for the whole article lands here. AI editing does not just add a feature to your CMS; it makes your content model the surface where safety, reuse, and freshness are either designed in or bolted on and hoped for. Sanity as the Content Operating System for the AI era exists to make that surface deliberate: model your business, automate everything, power anything, with the schema doing the load-bearing work so AI scales your output instead of your risk.