How to Create Guardrails So AI-Generated Content Matches Brand Voice

A shopping assistant tells a customer the discontinued product is "a fantastic choice," a support bot adopts a chirpy holiday tone in the middle of an outage, and a marketing agent quietly starts recommending a competitor's integration because nobody told it not to. These are not model failures. They are governance failures, and the fix usually lands as an emergency pull request that only one engineer can write, days after the embarrassing output already shipped. Sanity exists to close that gap. The layer that decides whether your AI matches brand voice is the application system prompt, and in most teams it lives as a string in the codebase where marketing cannot read it, compliance cannot review it, and the support manager cannot touch the escalation language.

Sanity is the Content Operating System for the AI era, an intelligent backend that treats that governing prompt as content you author, review, and gate rather than code only engineering can change. This guide reframes brand-voice guardrails as a modeling and workflow problem, not a prompt-engineering trick. You will author the prompt like content, split it into role-owned fields, gate every change with an eval bench, and stage agent behavior with the same release that ships a homepage change. The goal is guardrails that hold under production traffic, not a clever paragraph that drifts the moment the model updates.

Why brand-voice drift is a governance problem, not a prompt problem

Teams reach for prompt engineering when the agent sounds off, tweaking adjectives until a demo passes. That treats a systemic issue as a copy edit. Brand voice, escalation language, and the list of topics an agent must refuse are all encoded in one place: the application system prompt. It is a paragraph of English that decides whether your support agent recommends the right escalation, whether your shopping assistant pitches the in-stock item or the out-of-stock one, and whether your travel agent uses the brand voice on Tuesday and the holiday voice in December. That paragraph carries enormous risk, yet in most teams it is a string in the codebase.

The consequences follow directly from where the string lives. The marketing team cannot read it, so nobody who owns the brand can confirm the agent speaks in it. The compliance team cannot review it, so the never-say list is whatever an engineer remembered under deadline. The support manager cannot update the escalation language, so a policy change waits behind a deploy. When something ships wrong, the remedy is a pull request, which means the people accountable for voice and risk depend on the one team that can merge code. That is the real failure mode: not that the model is incapable, but that the guardrail is invisible and untouchable to the people responsible for it.

Reframing helps. The choice was never content, loose versus code, rigorous. It is governed, with the right people able to edit and a test gate on the way out, versus a string only engineering can touch. Guardrails that match brand voice reliably need the prompt to be authored like content and gated like code, in one system, so that the people who own voice and risk can act without becoming a bottleneck or a liability.

Model the guardrails: split the system prompt into role-owned fields

The first structural move is to stop storing the governing prompt as a monolithic string and model it instead. In Sanity, the agent's system prompt becomes a document, and you split it into fields that map to ownership. This maps to the Model your business pillar: the schema encodes who is accountable for which guardrail. Splitting the prompt into fields is not cosmetic. It is access control. Brand owns voice, Product owns how the agent uses user context, Support owns escalation, and Compliance owns the never-say list. None of them files a pull request, and none of them waits for a deploy.

Concretely, the schema might carry a voice field owned by Brand and a mustNotSay field owned by Compliance. The Studio field definitions make ownership explicit in the description, for example defineField for a Voice Guide of type array of block content described as "How the agent speaks. Owned by Brand," alongside a Forbidden Topics field of type array of string described as "Topics the agent must refuse. Owned by Compliance." At runtime, the fields stitch together into one final system prompt, the same way a page builder stitches sections, references, and logic into a page. Editors work in structured inputs; the application composes the paragraph.

Treat this as a modeling pattern you build rather than a shipped template, and adapt the field set to your organization. The payoff is precision. A brand refresh is an edit to the voice field, not a hunt through code. A new regulatory restriction is a line added to the never-say list by the person who owns compliance. Because each guardrail has a field and an owner, drift has an address. When an output goes wrong, you know which field, which team, and which change to review, rather than diffing a wall of prompt text nobody has read since launch.

Author it like content: real-time editing, history, and rollback

Once the prompt is a document, the entire content workflow you already trust applies to it. Because it lives as content in the Studio, you get real-time collaboration, version history, scheduled publishing, and rollback for free. That is not a convenience feature; it is what makes guardrails durable. When two people can co-edit the voice guide, when every change carries an author and a timestamp, and when a bad edit can be reverted in seconds, brand voice stops depending on tribal memory and becomes a maintained artifact.

This is the layer where non-engineers finally participate. Nearform reported that storing the system prompt in a Sanity document let editors tune the agent's voice without any code changes. Vipps came to Sanity wanting the whole organization to contribute to prompt writing, with product managers, not just engineers, owning it. That is the tell: once an agent is real, the prompt stops being code and starts being a thing many teams have a stake in. Author in the Studio, not in YAML, and the people who own the brand can adjust how the agent speaks the same afternoon they notice it is off, with a record of what changed and why.

Crucially, authoring like content does not mean loosening control. Permission gating decides who can touch which field, and audit trails record every change, so Compliance can prove who edited the never-say list and when. The distinction from a codebase string is that the governance is legible: a versioned document any authorized reviewer can open, rather than a value buried in a deploy. Update once, and web, co-work, apps, and customer agents stay in sync from the same source, so a voice change propagates everywhere the agent runs instead of drifting per surface.

Gate it like code: the eval bench that ships or blocks a change

Authoring the prompt like content is only half the pattern. The other half is the gate. Letting Brand and Compliance edit a live agent's behavior would be reckless without a test on the way out, so the rule is: author it like content, and gate it like code, in the same system. The mechanism is an eval bench. It is a frozen set of representative conversations, twenty to start, each scored against a rubric you wrote. You run the suite on every model change, every prompt change, and every tool change, and the bar to ship anything to production is the eval bench staying green.

This is what makes prompt-as-content safe. A brand or support voice edit ships only if the bench holds. Practically, a prompt change runs the eval bench in CI before it can ship, the same way a code change runs tests. Someone in Brand can rewrite the voice guide, and if that rewrite causes the agent to soften an escalation it should have made firmly, the bench catches the regression before a customer does. The eval bench turns editorial freedom into a controlled loop: edit freely, but the change is only real once it clears the rubric. This section serves the Automate everything pillar, because the guardrail enforces itself in the pipeline rather than relying on a human to remember to check.

Start small and let the bench grow with the failures you find. Every embarrassing production output becomes a new frozen conversation with a rubric line, so the same mistake cannot ship twice. Over time the twenty conversations become the institutional memory of everything your agent must and must not do, and the green bench becomes the single, honest answer to the question every stakeholder actually asks: is it safe to ship this voice change?

Measure drift in production: conversation classification

Guardrails that pass an eval bench can still degrade under real traffic, because production surfaces intents your twenty frozen conversations never anticipated. You need a signal from live transcripts, and the practical tool is conversation classification. Score transcripts with a model running over them asynchronously, asking a few blunt questions: was this conversation a success, what was the user trying to do, did the agent reach a tool it should not have, and did retrieval return useful results or did the agent hallucinate. It is not perfect. It is a hundred times better than no scoring.

Applied to brand voice, classification turns an intangible worry into a measurable signal. Instead of waiting for a screenshot of an off-brand reply to circulate, you can flag transcripts where the agent broke voice, ignored escalation, or drifted toward a forbidden topic, and you can watch that rate over time. When a rate ticks up after a model provider updates its weights, you have evidence, not a hunch, and you can trace it to a prompt field or a retrieval change. The signal feeds back into the eval bench: a recurring classified failure becomes a new frozen conversation, closing the loop between what you catch in the wild and what you gate on the way out.

This matters because model behavior is a moving target. The paragraph you tuned in March can produce different outputs in June without anyone touching it, purely because the underlying model changed. A team that only tests at ship time will not notice until a customer does. Continuous classification, paired with the eval bench and the versioned prompt document, gives you the three parts of durable guardrails: a governed artifact, a gate on changes, and a monitor on live behavior. Together they make brand-voice adherence something you operate, not something you hope for.

Ship guardrails with your release: schema-aware generation and staging

Guardrails are only as good as their reach into every place content gets generated. When your agent or your editors generate content with an LLM, the brand constraints you modeled in the schema should travel with the generation call rather than being reapplied by hand. Agent Actions are schema-aware APIs for generating, transforming, and translating content with LLMs, exposed via HTTP anywhere you can run code, so the structure and constraints defined in your model shape the output at the point of generation. Because the AI-touched content is Sanity content, the governance you already use applies to it: drafts, scheduling, history, permission gating, and audit trails.

The staging story is what closes the loop between a prompt change and a safe rollout. You can stage agent behavior with Content Releases the same way you stage a website, previewing before you ship. The release that ships a homepage change ships the prompt change. That single sentence carries the whole argument: your agent's voice is not a separate deploy pipeline with its own rules, it is versioned, previewed, and released alongside the rest of your content, by the same people, through the same gate. A voice update, a new forbidden topic, and a seasonal tone shift all move through preview, review, and scheduled publish.

This is where Sanity's institutional framing earns its keep. Sanity is the intelligent backend for companies building AI content operations at scale, and the difference from a legacy stack is that AI is built into the model, the editor, and the delivery layer rather than bolted on. Compliance controls hold across it: SOC 2 Type II, GDPR, regional hosting and data residency, and a published sub-processor list. Rigid CMSes force you to scale people to keep AI on-brand; a governed prompt document, an eval gate, and Content Releases let you scale output instead, keeping voice consistent as the number of agents and surfaces grows.