How to Build a Sanity App for AI-Driven Editorial Briefs

A content lead asks the team for an AI tool that drafts editorial briefs, and eight weeks later what ships is a ChatGPT window bolted to a sidebar. The prompt lives in a developer's code, so tuning the agent's voice means filing a pull request and waiting for a deploy. The compliance team's never-say list exists in a Google Doc nobody wired into the model. Every brief comes back as a paragraph an editor has to re-key into fields by hand. The tool technically works, and nobody uses it twice.

Sanity is the AI-native content platform built to close that gap, an intelligent backend for companies building AI content operations at scale rather than a chat box grafted onto a CMS. The distinction matters here: an editorial-brief app is not a feature you bolt on, it is an app you build on the same structured content your editors already govern. This guide walks the enterprise decisions behind that app, where the prompt should live, what the generation tool should return, how retrieval stays fresh, and who is allowed to change what, then shows how Agent Actions, the App SDK, and the Studio turn those decisions into something editors actually keep using.

Why the sidebar chatbot fails, and what an editorial-brief app has to do instead

The default AI-in-the-editor pattern is a free-text chat pane. It demos well and dies in production, because a brief is not a conversation, it is a structured artifact with an owner, a lifecycle, and downstream consumers. When the agent hands back a wall of prose, the editor becomes a transcriptionist: reading the paragraph, deciding which sentence is the angle, which is the target keyword, which is the CTA, and re-typing each into the correct field. The structure the CMS was supposed to enforce gets reconstructed by hand on every use, and the value the AI promised leaks away in the copy-paste.

An editorial-brief app has a narrower and more demanding job. It has to produce a brief object, not a brief description: a title angle, a target audience, key points, tone, mandatory disclosures, and internal links, each landing in its own typed field. It has to respect who owns which part of that output, because the brand team's voice guidance and the legal team's disclosure rules are not the writer's to override. And it has to stay reviewable, so a brief the agent drafted can be staged, edited, and approved before it drives real editorial work.

This is where the framing changes. Sanity's three pillars map cleanly onto the build: you model the brief and the rules as schema, you automate the drafting with Agent Actions and AI Assist, and you power the resulting brief across every channel and agent that consumes it. The rest of this guide follows that order, because the modeling decisions you make first are the ones that determine whether the automation is trustworthy later. Get the schema right and the AI becomes a governed contributor. Skip it and you have rebuilt the chatbot with extra steps.

Model the brief and its rules as content, not as code

The first architectural question is not which model to call. It is where the instructions that shape the brief actually live. In most implementations they live in a source file, which means the people who own those instructions, brand, product, and compliance, cannot touch them without an engineer. That is a governance failure disguised as a technical convenience.

The better pattern treats the agent's system prompt as a Sanity document. In the Studio you define an agentPrompt type with separate fields: a role field, a voice field authored as Portable Text and owned by Brand, a userContext field owned by Product, an escalation field owned by Support, and a mustNotSay array of forbidden topics owned by Compliance. As the knowledge base puts it, splitting the prompt into fields isn't cosmetic, it's access control. The fields stitch together into one final system prompt at runtime, the same way a page builder stitches sections, references, and logic into a page. None of those owners files a pull request. None waits for a deploy.

Because the prompt is content in the Studio, you inherit real-time collaboration, version history, scheduled publishing, and rollback for free. Nearform reported exactly this benefit: "Storing the system prompt in a Sanity document is genuinely useful. Editors tuned the agent's voice without any code changes." The brief template itself, its fields, its required disclosures, its default tone, is modeled the same way, so the shape of the output and the rules that constrain it are both first-class, editable content. This is the App SDK's job under the "Model your business" pillar: build custom apps and internal tools directly on top of the Content Lake, using the same schema your editors already trust.

Return structured briefs, not paragraphs: the generation tool

Once the rules are modeled, the app needs to generate. The temptation is to prompt the model for "a brief" and render whatever text comes back. This is the single most common reason these tools feel unreliable. A tool that returns prose forces the model to paraphrase, and as the Sanity engineering notes put it bluntly, paraphrasing is where facts go to die. When teams watched agents get built against the Context MCP endpoint, the ones that worked returned schema-shaped responses the model could pass straight through. The ones that struggled got a wall of text back and re-narrated it, badly.

Applied to briefs, the rule is exact: if the app is supposed to produce a title angle, three key points, and a target audience, the tool should return a brief object with those as typed fields, not a paragraph describing them. Agent Actions is the primitive that makes this native rather than improvised. It exposes schema-aware APIs for generating, transforming, translating, and validating content with LLMs, over HTTP anywhere you can run code, and because it is schema-aware, generation targets your brief document's fields directly instead of guessing at structure.

Structure the app's tools into the three categories every production agent needs. Read tools query existing content, past briefs, style guides, product facts, scoped to the user's session token. Write tools create or update the brief document, also on the user's token so permissions hold. Composite tools wrap a workflow, for example "draft brief from campaign," where one call maps to several backend steps. Keep the set small and focused; ten focused tools beat fifty overlapping ones. The payoff is compounding: because the output is a real document, it flows into everything else the platform does, from Visual Editing to translation, without a re-keying step in between.

Ground the brief in your own content with hybrid retrieval

A brief invented from the model's training data is a liability. A useful brief is grounded: it cites the products you actually sell, references the articles you have already published, and reflects the positioning your team agreed on last quarter. That grounding is a retrieval problem, and retrieval is where most bolt-on AI tools quietly cut corners, either by stuffing everything into the context window or by standing up a separate vector database that drifts out of sync the moment content changes.

Keyword search alone misses intent; a writer asking for "our take on entry-level trail shoes" will not match a document that only ever says "beginner running footwear." Pure vector search catches the intent but loses the hard filters, returning a semantically similar draft that happens to be archived or out of the target category. Hybrid retrieval blends both. In GROQ it reads as one query: structural predicates do the filtering that has to hold, then a score() pipeline blends a BM25 keyword match, weighted through boost([title] match text::query($queryText), 2), with text::semanticSimilarity($queryText) across the document, ordered by _score. One expression, one round trip, no glue code.

The deeper advantage is freshness. Because retrieval is wired into the Content Lake, the search index stays current as content changes: re-embedding on edit and deletion handling are the platform's job, not yours. When it is a separate vector DB plus glue code, as the engineering notes observe, freshness becomes a permanent line item on your roadmap. This is the difference between a CMS that bolts on AI and one built for it. The embeddings are tied to the content, so the brief the agent drafts today reflects the article you published an hour ago, not a snapshot from the last batch job.

Govern what the AI touches with Studio review and Content Releases

A brief that an agent drafted is a draft, not a decision. The enterprise question is not whether AI can generate the brief, it is whether a human can review, edit, and approve it before it drives paid work, and whether you can prove after the fact who changed what. This is governance, and it is the part that gets skipped when AI is a sidebar chat with no relationship to the content lifecycle.

Because the brief and the agent's prompt are both documents in the Studio, they inherit the same controls as the rest of your content. You stage agent behavior with Content Releases the same way you stage your website: drafts, scheduling, history, permission gating, and audit trails. A change to the compliance team's mustNotSay list, or to the brand voice guide, moves through drafts and review before it goes live, so a Friday-afternoon edit to the never-say list cannot silently reshape every brief over the weekend. Roles and Permissions decide who can edit which fields; Audit logs record who did.

The gate that makes this safe is evals. A prompt change runs the eval bench in CI before it can ship, scored against representative briefs written by hand, so "we improved the voice guidance" is a measured claim, not a hope. On the platform's compliance posture, name what is real: SOC 2 Type II, GDPR, regional hosting and data residency, and a published sub-processor list, the facts a security review will actually ask for. Treating the agent's behavior as governed content, versioned, reviewable, and reversible, is what lets legal and security sign off on an AI tool instead of blocking it. The discipline, not the first model you pick, is what survives to the second version of the app.

Ship it in two weeks: a build plan that survives contact with your teams

The failure mode at the other end of the spectrum from the useless chatbot is the over-scoped platform that never ships. Sanity's own guidance for building production agents is to start small and get in front of your security, content, and legal teams fast, roughly two weeks of focused engineering before that review, not two quarters.

Week one is scaffolding. Pick one pattern, the smallest useful one, say, drafting a brief from an existing campaign brief. Define three to five read-only tools and no write tools yet, so the first version can only propose, never mutate. Write the system prompt and, critically, put it where a non-engineer can edit it, which on this platform means the agentPrompt document in the Studio. Stand up trace logging so you can see what the agent actually did on every call. Week two is the safety net: build an eval suite of about twenty representative briefs you wrote by hand, score the agent against them, and only then add the write tool that lets it create real brief documents.

The harness is deliberately open. The App SDK renders the tool in the Studio where editors work, and the agent loop can bring its own LLM for cost and quality control and drop into an existing front-end stack, Next.js, the Vercel AI SDK, anything that speaks MCP. That is the honest relationship with the orchestration layer: the AI SDK and LangChain.js are the harness the app plugs into, not competitors to it. The first agent you ship will not be the agent you keep, and that is fine. The point of the two-week loop is that the modeling, the structured tools, the governed prompt, and the eval bench are the parts that carry forward. They are what let this be the AI Content Operating System for the editorial team rather than another demo nobody opens twice.