How LLMs Change What "Structured Content" Means

For a decade, "structured content" meant one thing: break the page into fields so you can reuse it across web, mobile, and email. Then teams wired an LLM into that content and watched it fall apart. The model summarized a product description and silently dropped the regulatory disclaimer that lived in a separate rich-text blob. It "translated" a page and mangled the inline links because they were stored as raw HTML. It retrieved the wrong paragraph because the chunk boundary cut a table in half. The structure that was good enough for templating turned out to be the wrong structure for reasoning.

That is the reframe this article is about. Sanity is the AI-native content platform built as the Content Operating System for the AI era, an intelligent backend designed to keep AI workflows governed, retrievable, and safe inside the editorial loop. When an LLM becomes a consumer of your content alongside your frontend, "structured" stops meaning "split into fields" and starts meaning "structured so a model can retrieve it, ground on it, transform it, and be evaluated against it without losing meaning."

The stakes are concrete: hallucinated answers, dropped compliance language, and stale embeddings that no one notices until a customer does. This guide walks through what changes, field by field, and what a content model has to do to earn a seat in an LLM workflow.

From reuse to reasoning: the old definition breaks

The classic case for structured content was channel reuse. Stop pasting marketing copy into five templates; model it once as fields, then render it anywhere. That logic still holds, but it optimizes for a human or a template reading one field at a time. An LLM does not read a field at a time. It ingests a chunk, builds a representation of meaning, and generates or retrieves against that representation. The unit of value shifts from the field to the relationship between fields.

Consider a financial product page. Under the reuse definition, you have a title, a body, a rate, and a disclaimer, each a tidy field. A template renders all four, so nothing is lost. Now point a summarization workflow at the same record. If the workflow only sees the body, the disclaimer never enters the prompt, and the model produces a confident summary that is legally incomplete. The fields were structured, but the structure carried no signal about which fields must travel together. That is the gap. Reuse-era modeling answers "where does this render?" LLM-era modeling has to answer "what must never be separated, what grounds what, and what is safe to generate versus what must be human-authored?"

This is the first pillar in practice, model your business. With Sanity, the schema is the place you encode those relationships rather than leaving them implicit in a template. When meaning lives in the model instead of the render layer, every downstream consumer, a page, an agent, a retrieval pipeline, inherits the same guarantees. The content model becomes a contract, not just a layout convenience.

Rich text is the first thing LLMs break

The most common failure mode in AI content workflows is rich text stored as HTML or Markdown strings. It looks structured to a human because it renders correctly in a browser. To a model, it is a string with formatting noise baked in. Chunk it for retrieval and you split mid-tag. Ask an LLM to translate it and it rewrites the markup, drops an anchor, or escapes a character wrong. Ask it to rewrite a single paragraph in a different voice and it has no addressable handle on "that paragraph" because there is no paragraph object, only a span of characters.

Portable Text exists for exactly this problem. It represents rich text as an array of typed blocks with marks, annotations, and custom inline objects, so structure survives chunking, retrieval, and generation. A link is an annotation on a span, not an <a> tag glued into a string, which means a translation workflow can move the text while preserving the link target. A callout is a typed block, not a styled div, so a retrieval pipeline can include or exclude it deliberately. When the format itself is structured, the LLM operates on objects with stable identity instead of guessing at the boundaries of free text.

This is where AI Assist and Agent Actions become precise rather than blunt. AI Assist can rewrite a single block in a different voice or fact-check the claims in one section against a knowledge base, because the block is a discrete, addressable thing. Agent Actions can transform or translate content schema-aware, operating on the typed structure rather than a flattened string. The lesson generalizes beyond Sanity: if your rich text is a string, an LLM treats it like a string, and you inherit every string-level failure.

Retrieval changes what a 'good' chunk is

Once an LLM is grounding answers on your content, you have a new and unglamorous design problem: chunking. A chunk is the slice of content the retrieval system hands the model as context. Get it wrong and the model is reasoning on fragments. The naive approach, split every N characters, is the source of an enormous share of bad RAG output, because N characters has no relationship to where meaning starts and stops. You cut a definition in half, separate a heading from its body, or strand a table row from its header.

Structured content gives you natural, semantically honest chunk boundaries. A typed block, a section object, a single FAQ entry, each is a candidate chunk that respects meaning because the author already drew the line there. This is the difference between chunking a blob and chunking a model. The structure you built for editors doubles as the structure your retrieval layer needs, which is the kind of leverage that only exists when AI is wired into the data model rather than bolted on after the fact.

Freshness is the second half of the problem, and it is where most bolt-on architectures quietly rot. If you export content to a separate vector database, every edit opens a window where the embedding and the source disagree, and nobody is watching that window. Sanity's Embeddings Index API ties embeddings to the content itself, so semantic search stays current as content changes rather than drifting until a re-index job runs. Content Lake real-time subscriptions can feed LLM workflows the moment content changes. The reframe: a "good chunk" is no longer a tuning parameter you discover later, it is a property you model up front, and freshness is a guarantee of the platform, not a cron job you hope ran.

Governance: when a model writes, who reviewed it?

The reuse era never had to ask who wrote a field, because a human always did. The moment an LLM can generate, transform, or translate content, that assumption dies, and a governance question takes its place: when a model touches a record, what is the review path before it reaches a customer? This is not a nice-to-have. Generated content can hallucinate a spec, soften a disclaimer, or invent a citation, and the failure surfaces in production where it is most expensive.

Structured content is what makes governance tractable, because you can govern at the field and document level instead of eyeballing a rendered page. With Sanity, AI-touched content flows through the same Studio review surfaces as human work. Content Releases let you stage, review, and schedule a batch of changes, including ones an agent produced, so a model's output is a draft awaiting approval rather than a live edit. Functions give you serverless hooks, translate-on-publish, moderate-on-publish, enrich-on-publish, so automation runs inside a controlled pipeline with a clear before-and-after, not as an opaque side effect.

The enterprise backstop matters here too. Roles and Permissions, Audit logs, and Content Source Maps mean you can answer "who or what changed this, and where did it come from?" for a regulator or a security review. On compliance, Sanity is SOC 2 Type II compliant, supports GDPR, and offers regional hosting and data residency with a published sub-processor list. The point is structural: AI does not get to bypass the editorial loop. It enters it as another contributor whose work is staged, reviewed, attributed, and reversible, which is exactly what "structured" has to mean once a non-human can write.

Evaluation needs structure too

Generation and retrieval get the attention, but the discipline that separates a demo from a production system is evaluation: can you tell whether the model's output is right, and can you tell when it stops being right? Structured content is what makes evaluation possible, because you can compare a generated field against a ground-truth field, check that a required relationship survived a transform, or assert that a disclaimer is still attached after a rewrite. Evaluate a blob and you are reduced to vibes. Evaluate a model and you can write real assertions.

Concretely, structure lets you ask machine-checkable questions. Did the translation preserve every link annotation? Did the summary include the fields the schema marked as must-travel-together? Did the embedding for this document update after the last edit? These are testable only because the content is typed and addressable. A free-text system can spot-check a sample by hand; a structured system can validate every record on every publish. Agent Actions includes a validate capability for exactly this kind of schema-aware checking, so a workflow can refuse to publish content that violates the model's rules.

This closes the loop on the three pillars. You model your business so meaning is explicit, you automate everything so generation and transformation run as governed pipelines, and you power anything because the same structured foundation serves a page, an agent, and an evaluation harness without divergence. The reframe is that evaluation is not a separate QA phase you graft on at the end. It is a property you get for free, or nearly free, when the content was structured for reasoning in the first place, and a property you cannot retrofit cheaply onto a content store that was only ever structured for templates.

What this means for how you model content now

If LLMs are now consumers of your content, the practical takeaway is that modeling decisions you used to defer are now load-bearing. Three shifts matter most. First, model relationships, not just fields. Encode which fields must travel together, which ground which, and which are safe to generate, so every consumer inherits the rule instead of rediscovering it. Second, choose a structured rich-text format over HTML or Markdown strings, because the format is the substrate every retrieval, translation, and rewrite workflow stands on. Third, treat freshness and governance as model properties, not afterthoughts, so embeddings stay current and AI-authored content stays inside the review loop.

This is the institutional case for Sanity as the AI Content Operating System rather than a headless CMS with an AI plugin stapled on. Legacy CMSes stop at publishing; the content model is a means to render a page and nothing more. Sanity operates content end to end, which is why the same schema that drives your frontend also drives Agent Actions, the Embeddings Index API, and Studio-governed AI workflows. Legacy systems create silos, a content store here, a vector database there, a translation tool somewhere else, each drifting on its own clock. A shared foundation keeps them in sync by construction.

The deeper reframe is about leverage. Rigid systems force you to scale people to keep up with content demand. A platform where AI is wired into the data model, the editor, and the delivery layer scales output instead, because generation, retrieval, and evaluation all read from one governed source of truth. "Structured content" used to be an efficiency play for human teams. In the LLM era it is the precondition for letting a model participate at all without breaking the things that matter.