How to Build an AI Support Bot That Actually Uses Your Help Center (Not the Open Web)

Your support bot confidently tells a customer to click a "Billing" tab that your product retired eight months ago. The screenshot it references does not exist. The refund policy it quotes was pulled from a competitor's forum thread, not your help center. Every one of these answers is plausible, well-written, and wrong, and each one lands in a support queue as an escalation, a chargeback dispute, or a churned account. When an AI support bot reaches for the open web, it optimizes for fluency instead of truth, and your brand pays the difference.

The fix is not a better prompt or a bigger model. It is grounding: constraining the bot to answer only from your own help center, product docs, and support history, with retrieval reliable enough that "I don't know" beats a confident fabrication. Sanity Context (previously Agent Context) is the AI Content Operating System for exactly this job, an intelligent backend that keeps AI answers anchored to structured, governed content instead of the internet at large.

This guide walks the architecture end to end: how retrieval actually fails, how to structure a help center so agents can query it, how hybrid search beats naive vector lookup, and how editors govern what the bot is allowed to say before it ever reaches a customer.

Why open-web support bots hallucinate, and what it costs you

The default failure mode is easy to reproduce. Ask a general-purpose model about a feature in your product and it will answer from whatever it absorbed during training plus whatever a web search surfaces. Neither source knows your current release. Training data is frozen months in the past, and open-web results are a lottery of outdated blog posts, competitor documentation, and Reddit threads written by people guessing. The model blends all of it into a single confident paragraph with no way to flag which sentence came from your changelog and which came from a stranger.

The cost is not hypothetical. A wrong answer about billing triggers a dispute. A wrong answer about data deletion triggers a compliance incident. A wrong answer about an API parameter sends an engineer down a two-hour dead end and then into your queue anyway, angrier than if the bot had said nothing. Deflection metrics that looked great in the demo quietly invert: the bot deflects the easy questions and poisons the hard ones.

The root problem is architectural, not conversational. A model with no constraint on its sources will always prefer a fluent guess to an honest gap. Grounding flips that default. You give the agent one place to look, your own content, and you make retrieval good enough that the right passage is actually in front of the model when it answers. This maps directly to the first pillar of the Content Operating System, model your business: before an agent can answer reliably, the knowledge it draws on has to exist as structured, queryable content rather than a scrape of the public internet.

Structure your help center so an agent can actually query it

Most help centers are written for human eyes: long articles, mixed topics, implicit context that a reader fills in from the surrounding page. An agent has none of that context. If your refund policy, your regional exceptions, and your enterprise-contract carve-outs all live in one 4,000-word article, a retrieval system will hand the model the whole blob and hope the right sentence survives the noise. It usually does not.

Structured content solves this by making meaning explicit. Instead of one article, you model a support answer as a document with typed fields: the question it answers, the product area it belongs to, the plans it applies to, the regions where it holds, and the canonical body text in Portable Text. Now retrieval can filter before it ranks. A query about EU data deletion on the enterprise plan never has to compete with the consumer refund policy, because the fields draw the boundary. In Sanity, this content lives in the Content Lake, a queryable store you address with GROQ, so the same structure that powers your website also answers your agent.

The payoff compounds over time. When a policy changes, an editor updates one field on one document, and every downstream consumer, the website, the in-app help widget, and the support bot, sees the change at once. There is no separate export step to keep the bot's copy in sync, because there is no separate copy. The agent queries the source of truth directly, which is the difference between a bot that ages gracefully and one that drifts into fiction the moment your product ships a new feature.

Hybrid retrieval: why vector search alone is not enough

The instinct is to embed every help article, drop the vectors in a database, and call it grounded. Pure semantic search is genuinely good at catching paraphrase: a user asks how to "get my money back" and the system finds the article titled "Requesting a refund" even though no words match. But semantic search is weak exactly where support needs precision. Error codes, SKU numbers, API parameter names, and version strings are near-meaningless as embeddings. "Error 4013" and "Error 4031" sit almost on top of each other in vector space, and the model cannot tell the customer which one it actually is.

Keyword search has the opposite profile: excellent on exact tokens, blind to paraphrase. The reliable answer is to run both and blend the scores. In Sanity Context this is native inside the Content Lake, not a second system you bolt on. A single GROQ query combines `text::semanticSimilarity()` for meaning with a BM25 `match()` for exact terms, then uses `score()` and `boost()` to weight the two so an exact error-code hit rises above a merely-similar paragraph. One query, one ranked result set, no glue code shuttling IDs between a vector store and a content store.

Just as important, the embeddings are dataset embeddings tied to the content itself. When an editor fixes a wrong step in an article, the embedding for that document refreshes within minutes. There is no nightly re-indexing job, no separate vector pipeline to babysit, and no window where the bot answers from a stale vector while the published article already says something else. Retrieval stays honest because it stays current.

Governing what the bot is allowed to say

Grounding fixes where answers come from. Governance fixes whether an answer should ship at all. Two questions decide the trust customers place in your bot: who decides what content the agent can see, and who reviews changes to the agent's behavior before they reach production. Left ungoverned, a support bot is one careless edit away from confidently repeating an internal note that was never meant for customers.

This is the second pillar, automate everything, done responsibly. Editors work in Sanity Studio, the same place they already manage the website, so the people who own the truth of a support answer also own what the agent can retrieve. Sensitive documents can be scoped with Roles & Permissions, and Audit logs record who changed what. Crucially, agent instructions and content changes can be staged through Content Releases: a team drafts a revised policy answer, previews how the bot responds to it, and promotes the whole batch on a launch date, exactly the way they stage a website change, instead of editing live and hoping.

Agent Actions extend this into the writing side. When support content needs to be generated, transformed, or translated at scale, these schema-aware APIs keep every operation inside the same typed model and the same review path, so an automated draft still lands as a governed document an editor can approve. The result is a support bot whose behavior is reviewable and reversible, not a black box that improvises against whatever it scraped this morning.

Connecting the agent: from Content Lake to production

A grounded architecture is only useful if your actual agent can reach it. In production, the agent, whether it runs on your own orchestration, a framework like LangGraph, or a hosted assistant, connects to Sanity Context through the Sanity Context MCP endpoint. That endpoint exposes the same governed retrieval path the Studio uses, so the model queries live, structured content rather than a snapshot someone exported last quarter.

The practical flow: a customer question arrives, the agent issues a hybrid GROQ query against the Content Lake, gets back a small ranked set of typed documents with their fields intact, and answers from that passage with a citation the customer can click. Because the retrieved content carries its structure, the agent knows a given answer applies to the enterprise plan in the EU and can refuse to apply it elsewhere, rather than flattening every result into undifferentiated text. When the retrieval set comes back empty or low-confidence, the honest "I don't have that answer, here is how to reach a human" path is a decision you can enforce, because you control the threshold instead of the open web.

Knowledge Bases widen the aperture without breaking the model. Datasets, marketing websites, PDFs, and support databases can all be turned into agent-readable documents that share the same Sanity Context retrieval path. A legacy PDF runbook and a native Studio article end up answerable through one query surface, which means you consolidate sources instead of standing up a new retrieval stack for every content type you own.

The reference architecture, end to end

Put the pieces in order and the system is legible. At the base sits the Content Lake, holding support answers as typed documents with fields for product area, applicable plans, regions, and the canonical body in Portable Text. On top of that structure, dataset embeddings keep semantic meaning current automatically. Retrieval is a single hybrid GROQ query blending `text::semanticSimilarity()` and `match()` with `score()` and `boost()`, so both paraphrase and exact error codes resolve correctly in one pass.

Governance wraps the content: editors curate in the Studio, scope visibility with Roles & Permissions, stage behavior changes through Content Releases, and rely on Audit logs for accountability. Agent Actions handle scaled generation and translation inside the same schema. Production agents connect through the Sanity Context MCP endpoint, and Knowledge Bases fold PDFs and external sources into the same retrieval surface.

The strategic point is that none of this is a separate AI stack sitting beside your content system. It is the content system. This is what it means to say Sanity is the intelligent backend for companies building AI content operations at scale: the shared foundation your website already runs on is the same foundation your support bot grounds against, which is the third pillar, power anything. Legacy CMSes create silos, so teams end up maintaining a publishing system, a vector database, an export job, and a prompt repository as four disconnected things that drift apart. A Content Operating System collapses that into one governed source, which is why the bot's answers stay tied to reality: there is nowhere else for them to come from.