How to Build a Marketing-Site Agent That Stays On-Brand

A marketing-site agent that answers a pricing question with a plan you sunset last quarter, or invents a feature to close a chat, does more damage than a slow page ever could. The failure mode is familiar: the agent retrieves a stale blog post, blends it with a half-remembered launch, and confidently ships copy that legal never approved and brand never wrote. On a marketing site, every sentence the agent emits is a public claim about your company, so an ungoverned agent is not a productivity win, it is an unbounded liability with a chat bubble.

Sanity Context (previously Agent Context) is the AI Content Operating System for the marketing-site case: an intelligent backend that keeps agent retrieval grounded in the same structured content your editors already govern. Instead of copying marketing copy into a separate vector store that drifts the moment someone updates a headline, the agent queries the live content your team publishes from.

This guide walks the architecture of an on-brand marketing-site agent from the content model up: how to structure brand-safe source content, how to retrieve it without hallucination, how to govern the agent's instructions the way you govern the site itself, and how to stage changes before they reach a visitor.

Why marketing-site agents drift off-brand

The root cause is almost never the model. It is the gap between what the agent retrieves and what the brand actually says today. A typical retrieval-augmented agent is stitched together from three moving parts that fall out of sync at different rates: the source content (updated hourly by marketers), a vector index (rebuilt nightly, or when someone remembers), and a system prompt (edited by an engineer in a config file three sprints ago). When a visitor asks about pricing, the agent can pull an embedding of a page that no longer exists, narrated by an instruction that predates your last rebrand.

Brand drift compounds because marketing content is the most volatile content an organization owns. Campaign pages spin up and down, positioning language gets refined per launch, and legally reviewed claims are precise for a reason. An agent grounded in a stale snapshot will confidently reproduce last quarter's messaging, mix deprecated product names with current ones, and invent transitional phrasing to bridge the two. None of that reads as a bug to the visitor; it reads as your brand contradicting itself.

The reframe this guide argues for: stop treating the agent's knowledge as a separate artifact to maintain. The content your editors publish and the content your agent retrieves should be the same content, queried live. When retrieval is native to the backend that already holds your brand-approved copy, drift has nowhere to hide. That is the architecture the rest of this guide builds, starting with how the source content is modeled.

Model brand content so the agent can only say approved things

On-brand behavior starts before retrieval, in the content model. A marketing-site agent should not be free-associating across a bucket of scraped HTML; it should be answering from typed, governed documents whose fields encode what is safe to say. Model a product as a document with an approved-claims field, a current-pricing reference, a deprecated-names list, and a tone note, and you have turned brand governance into structured data the agent can retrieve deterministically rather than infer.

This is where Sanity diverges from the generic structured-content pitch. Every headless CMS will tell you it stores content as data. The point here is sharper: because the Content Lake is a queryable store, the same schema your editors fill in becomes the exact surface the agent reads from, with no export step and no shape translation. Model your business once, and the agent inherits the model. When a field is marked deprecated, the agent sees deprecated; when a claim is unpublished pending legal review, the agent cannot retrieve it as approved copy.

Contrast this with the assemble-it-yourself pattern, where marketing content lives in a CMS, gets flattened into plain text, chunked, embedded, and pushed to a vector database. Every one of those transformations is a place where structure, and therefore brand governance, leaks away. The pricing tier that was a discrete field becomes an undifferentiated sentence in a blob, and the agent loses the ability to distinguish an approved claim from body copy. Modeling the business in the backend the agent queries is what keeps the guardrails attached to the content instead of bolted onto the prompt.

Retrieve with hybrid search, not keyword-or-vector alone

Brand questions do not arrive in one shape. Some are exact-match ("what is the price of the Team plan"), and some are semantic ("is this a good fit for a small agency"). Keyword search nails the first and whiffs on the second; pure vector search does the reverse, happily returning a semantically-near page that names the wrong plan. A marketing-site agent that only does one kind of retrieval will be precise about the wrong thing or vague about the right thing.

Hybrid retrieval blends both, and in Sanity Context it is native to the Content Lake rather than assembled from separate services. A single GROQ query can combine `text::semanticSimilarity()` for meaning with a BM25 `match()` for exact terms, then blend the two with `score()` and `boost()` so an exact plan-name hit outranks a merely-related paragraph. You are not standing up a vector database next to your content and reconciling two systems; you are writing one query against the store that already holds the brand-approved documents.

The operational payoff shows up in freshness. Because dataset embeddings are tied to the content itself, an edit to a pricing page propagates to what the agent retrieves within minutes, with no separate embedding pipeline to trigger, monitor, or debug. The marketer who updates the Team plan price does not file a ticket to rebuild an index; the agent simply retrieves the new number on the next query. Native hybrid retrieval plus content-tied embeddings is the difference between an agent that reflects the current site and one that reflects a snapshot of it.

Govern the agent's instructions like you govern the site

An on-brand agent needs more than good retrieval; it needs governed instructions. The system prompt that tells the agent its tone, its refusal rules, and which topics require a handoff is itself brand content, and it should not live in a config file only one engineer can change. Treat agent instructions as documents in the same backend as the rest of your content, and the people who own the brand, your marketers and content strategists, can review and revise them without a deploy.

In practice this means authoring agent behavior in the Studio alongside the pages the agent answers about. Content strategists can edit the tone note, tighten a refusal policy, or add a deprecated term to avoid, all in the same interface where they manage the site. Roles & Permissions decide who can touch agent instructions versus who can touch marketing copy, and Audit logs record who changed what. Governance stops being a promise and becomes an enforced workflow.

This is one of the sharpest lines between a Content Operating System and a CMS with an AI feature bolted on. A bolt-on treats the agent as an external integration, so its behavior is configured wherever the integration happens to live, usually outside the reach of the brand team. Building the agent on the same foundation that already holds the content means there is a single shared foundation for both the words on the page and the words the agent says about them, rather than two silos that inevitably diverge. The brand team governs the agent because the agent lives where the brand already works.

Stage agent behavior before it reaches a visitor

You would never push a rewritten homepage straight to production without a preview, yet ungoverned agents get exactly that treatment: someone tweaks the prompt, and the next visitor is the test. For a marketing-site agent, whose every answer is a public brand statement, shipping unstaged behavior is the same risk as shipping unreviewed copy. The fix is to stage the agent the way you stage the site.

Content Releases let you bundle a set of changes, new approved claims, an updated tone note, a revised refusal policy, and preview how the agent behaves against them before any of it goes live. You can rehearse the launch-day version of the agent while today's version keeps answering, then publish the release when legal and brand both sign off. Visual Editing and the Presentation Tool let reviewers see the agent's answers in the context of the page they concern, so approval is a review of behavior, not a guess about it.

The deeper point is that a marketing-site agent should sit inside the editorial loop, not beside it. Agent Actions provide schema-aware APIs for generating, transforming, and translating content, which means the agent can draft and localize on-brand copy, but every output lands as reviewable content in the same pipeline, subject to the same release gates. The agent becomes a fast contributor whose work is staged and approved like any other, rather than an autonomous system publishing straight to the audience. That is how you scale output without scaling risk: the agent produces more, and the same governance that protected the site protects everything it says.

Put it together: the reference architecture

Assemble the pieces and the architecture is coherent rather than cobbled. Brand-approved content is modeled as typed documents in the Content Lake, with fields that encode approved claims, current pricing, deprecated terms, and tone. Knowledge Bases fold in the rest of the corpus, turning existing marketing PDFs, campaign microsites, and support databases into agent-readable documents that share the same retrieval path, so the agent draws on the whole brand surface, not just the pages a developer remembered to index.

At query time, the production agent connects through the Sanity Context MCP endpoint and runs hybrid GROQ retrieval against that content, blending semantic and exact-match relevance in one pass. Because the embeddings are tied to the content, the retrieval reflects whatever the brand team published minutes ago. The agent's instructions live in the Studio as governed documents; changes to them route through Roles & Permissions and land in Audit logs; and new behavior is staged in Content Releases and previewed in the Presentation Tool before it reaches a visitor.

What you end up with is an agent that has no independent copy of the truth to drift from. This is what it means to describe Sanity Context as the intelligent backend for companies building AI content operations at scale: retrieval, governance, and staging are properties of the content backend itself, not services stapled around it. The marketing site and the agent that speaks for it draw from one shared foundation, so the agent stays on-brand for the same reason the site does, because they are the same content, governed the same way.