How to Build an AI Brief Writer Inside Your Studio
Content briefs are where campaigns quietly die. An editor opens a blank document, copies last quarter's brief, strips out the specifics, and pastes in a new title.
Content briefs are where campaigns quietly die. An editor opens a blank document, copies last quarter's brief, strips out the specifics, and pastes in a new title. The tone reference is stale, the SEO targets belong to a different product, and the brand guidelines linked at the bottom point to a doc that was archived months ago. By the time a writer picks it up, half the context is wrong and nobody notices until the draft comes back off-brand.
Sanity is the AI-native content platform that treats this as a data problem rather than a document problem, and that reframing is the whole point of building an AI brief writer inside the Studio. Sanity is the AI Content Operating System, an intelligent backend where AI features are wired into the schema, the editor, and the delivery layer instead of bolted on as a chatbot in a sidebar. When your brief writer reads structured content instead of a copied template, it can ground every field in real brand data, live campaign records, and the actual style guide.
This guide walks through the architecture of an in-Studio brief writer: the schema it writes into, the AI surfaces that generate and validate it, and the governance that keeps LLM output reviewable before it reaches a writer.

Why the copy-paste brief is a data-modeling failure
The reason briefs rot is not that editors are careless. It is that the brief lives as unstructured prose in a document, disconnected from the content it is supposed to produce. A campaign brief in a Google Doc has no relationship to the campaign object, the target audience segment, the product it promotes, or the brand voice it is meant to honor. Every one of those is a fact that already exists somewhere in your organization, and the document quietly duplicates a snapshot of it that immediately begins to drift.
This is the first pillar of the Content Operating System in practice: model your business. When you model a brief as a document type with typed fields, references to the campaign it belongs to, references to the target products, an enumerated tone, and structured acceptance criteria, the brief stops being a snapshot and becomes a live view onto the rest of your content graph. A reference to a product means the brief always points at the current product description, not a copy of last month's. A reference to a brand-voice document means the tone guidance updates everywhere the moment it is edited once.
This matters far more once an LLM is involved. An AI brief writer that reads a document has to parse prose and guess at intent. An AI brief writer that reads a structured schema receives typed, unambiguous inputs: this campaign, these products, this audience, this locale. The quality of AI-generated content is bounded by the quality of the context it is grounded in, and a strong content model is what turns your organization's scattered knowledge into that context. The blank document is where AI hallucinates; the schema is where it behaves. Model first, generate second.
The schema your brief writer writes into
Before any generation happens, design the brief document type as the contract between the AI and your editors. A useful brief schema is not one giant portable-text field. It is a set of discrete, typed fields the AI can populate independently and an editor can review field by field: an objective, a target audience reference, an array of key messages, SEO target keywords, a tone selected from an enumerated list, required calls to action, and structured acceptance criteria. Longer narrative sections, the background and the creative rationale, use Portable Text so that headings, annotations, and inline references survive intact.
Portable Text is the quiet hero here. Because it stores rich text as structured blocks and marks rather than an opaque HTML blob, an LLM can generate it, and later chunk, retrieve, or transform it, without losing the structure. An annotation that links a claim to a source document stays attached to that claim through every downstream step. When your brief writer cites the brand guideline it drew a tone rule from, that citation is a real reference, not a footnote a writer has to trust.
The payoff of a granular schema is granular governance. Rather than accepting or rejecting a wall of generated text, an editor approves the objective, tweaks two key messages, rejects an off-target CTA, and regenerates only the audience section. The schema turns a single risky AI output into a set of small, reviewable decisions, and that is exactly the surface Agent Actions and AI Assist are built to operate on.
Building the generator: AI Assist, Agent Actions, and the App SDK
Sanity gives you three distinct surfaces for the actual generation, and choosing the right one is most of the design work. AI Assist is the in-Studio LLM helper editors already reach for: it can draft the background section, rewrite a key message in a punchier voice, translate the whole brief's headings into eight locales, or fact-check a claim against a linked source. It lives inside the fields editors are already editing, which makes it the fastest path to a brief writer that people actually use.
Agent Actions is the deeper primitive. It is a schema-aware API for LLM-driven content workflows, generate, transform, translate, and validate, that understands your document type and writes into its typed fields directly. This is what you call when you want a single button, Draft this brief, that reads the referenced campaign and products, then populates the objective, key messages, and acceptance criteria in one governed operation. Because Agent Actions knows the schema, it respects your field types and validation rules rather than dumping freeform text and hoping it fits.
When you want a bespoke experience, an in-Studio brief-writer app with its own review flow, iteration controls, and prompt presets, the App SDK lets you build it as a first-class Studio application rather than a plugin hanging off the side. The distinction Sanity draws is that AI is a content pipeline primitive here, not a chat widget. A brief writer built on Agent Actions and the App SDK reads structured inputs and writes structured outputs, which is what makes its results reviewable, repeatable, and safe to run at campaign scale.
Grounding the writer in real brand knowledge
A brief writer that invents your tone of voice is worse than no brief writer at all, because it produces confident, plausible, wrong guidance that a writer will dutifully follow. Grounding is the difference between an AI that summarizes your actual brand and one that summarizes the internet's average brand. This is the retrieval half of the problem, and it is where content-as-context earns its keep.
Turn your brand guidelines, past high-performing campaigns, product documentation, and messaging frameworks into Knowledge Bases: sources the AI can read as governed, structured content rather than scraping loose PDFs. Pair that with the Embeddings Index API and dataset embeddings so the writer can retrieve semantically relevant material, the three closest prior briefs for this product line, the messaging pillar that matches this audience, without you maintaining a separate vector database. Because the embeddings are tied to your content, they refresh automatically when the content changes; there is no nightly re-indexing job that silently falls behind.
For deeper retrieval-grounded agent work, Sanity Context is the grounding product that lets agents query your content with citations, and the architecture pattern extends beyond briefs into any agent that needs trustworthy content. The important reframing for editorial teams is this: the CMS is not just where the brief lands, it is the source of truth the brief writer reads from. When retrieval and content share one foundation, freshness stops being a maintenance chore and becomes a property of the system.
Governance: keeping LLM output inside the editorial loop
The fastest way to lose trust in an AI brief writer is to let it publish. Enterprise editorial teams do not want autonomous content; they want leverage with a human checkpoint, and the governance layer is what separates a demo from something legal and brand teams will actually sign off on. Generated briefs should land in draft, route through review, and only advance when a human approves them.
Content Releases and Studio Workspaces give you the staging and review structure: a generated brief can be grouped into a release, reviewed alongside the campaign it serves, and scheduled rather than pushed live the instant the model finishes. Roles & Permissions decide who can run the brief writer and who can approve its output, so the intern's regeneration does not silently overwrite the reviewed version. Audit logs record what the AI generated and who accepted it, which is the paper trail compliance teams ask for the moment AI enters a content workflow.
Functions close the loop by connecting editorial events to automation: enrich-on-publish to attach related assets, validate-on-publish to check a finished brief against your acceptance criteria, or notify-on-approve to ping the assigned writer. This is the third pillar, automate everything, applied with restraint. The goal is not to remove the human but to remove the busywork around the human, so the reviewer spends their attention on judgment calls rather than copy-paste. AI generates the draft, the system routes and records it, and a person still decides.
Rolling it out without scaling the team
The organizational promise of an in-Studio brief writer is not fewer editors; it is more output from the editors you have. A traditional content operation scales linearly: more campaigns means more briefs means more people writing briefs. When the brief writer reads your content graph and drafts a governed first pass in seconds, the marginal cost of a well-grounded brief collapses, and the team's time shifts from producing briefs to reviewing and improving them.
Start narrow. Pick one high-volume brief type, product-launch briefs or localized-campaign briefs, and model it well before you generalize. Wire AI Assist into the fields first so editors feel the assist without ceding control, then graduate to an Agent Actions button once the schema and grounding are trustworthy. Instrument the review step: track how many generated fields editors accept unchanged versus rewrite, and feed that signal back into your prompts and Knowledge Bases. A brief writer that gets 40 percent of fields accepted on day one and 80 percent a quarter later is a system that is learning your organization, not a static feature.
The deeper reframing is architectural. Legacy CMSes stop at publishing and force teams to scale people to scale content; because AI is wired into Sanity's data model, editor, and delivery layer rather than plugged in on top, the same platform that stores your briefs is the one that drafts, grounds, governs, and delivers them. That is what it means to scale output instead of headcount.
Building an in-editor AI brief writer: native depth vs. bolt-on assistants
| Feature | Sanity | Contentful | Storyblok | Strapi + LangChain.js |
|---|---|---|---|---|
| Schema-aware generation into typed fields | Agent Actions generate, transform, and validate directly against your document type, respecting field types and validation rules. | Studio AI / Quick Start AI assists within fields, but generation is oriented to text output rather than a schema-aware pipeline primitive. | Storyblok AI generates and translates field text in the editor; it operates per field rather than populating a whole typed document in one governed action. | Custom: you wire LangChain.js to Strapi's REST/GraphQL API and enforce the schema yourself in application code. |
| Structured rich text for LLM safety | Portable Text stores blocks, marks, and annotations so structure and source citations survive chunking, retrieval, and regeneration. | Rich Text is a structured JSON format, workable for LLMs, though citation-as-annotation patterns are left to your implementation. | Richtext is structured JSON and usable by an LLM; preserving inline source annotations across transforms is a build-it-yourself concern. | Blocks / rich text is JSON-based; retaining annotation structure through LLM steps is entirely your application's responsibility. |
| Embeddings tied to content | Embeddings Index API and dataset embeddings refresh with the content, so semantic retrieval stays fresh with no separate vector DB to maintain. | No native content-tied embeddings; teams typically sync content to an external vector store and manage re-indexing themselves. | No native embeddings layer; semantic retrieval means exporting content to a third-party vector service and keeping it in sync. | You own the embeddings pipeline end to end via LangChain plus a vector store, including re-indexing when content changes. |
| Grounding brand knowledge for retrieval | Knowledge Bases turn guidelines, past campaigns, and docs into governed, agent-readable content; Sanity Context adds cited retrieval. | Grounding relies on external RAG services connected through the App Framework; the knowledge layer lives outside the CMS. | Grounding is achieved by integrating outside RAG or search tooling; there is no first-party governed knowledge-base surface. | Grounding is fully custom: assemble retrievers, chunkers, and sources in LangChain against Strapi content. |
| Governance of AI output | Content Releases, Roles & Permissions, and Audit logs stage, gate, and record what the AI generated and who approved it. | Workflows, roles, and scheduled publishing exist; associating an audit trail specifically to AI-generated fields is your setup to define. | Editorial workflows, roles, and release scheduling are available; AI-output-specific audit trails are configured by the team. | Draft/publish and roles come via plugins and config; a review-and-audit trail around AI output is built in application code. |
| Building a bespoke in-editor app | App SDK ships the brief writer as a first-class Studio application with its own review flow, presets, and iteration controls. | App Framework supports custom apps in the web app; AI experiences are commonly assembled from marketplace and partner pieces. | Plugins and the app ecosystem allow custom UI; a dedicated brief-writer experience is a plugin build on top. | Fully custom admin panel customization; you build and maintain the entire brief-writer UI and its wiring yourself. |