How to Build a Customer Support Agent That Reads Your Docs, Not the Internet
Most support agents fail the same way: they answer from the open internet instead of your actual documentation, returning plausible-sounding fixes that don't match your product.
Most support agents fail the same way: they answer from the open internet instead of your actual documentation, returning plausible-sounding fixes that don't match your product. The result is confident hallucination, wrong API versions, deprecated flags, features you never shipped. Building an agent that reads your docs (and only your docs) is less about prompt engineering and more about retrieval architecture: where the content lives, how it's queried, and how editors keep it honest. This guide walks through that build, from grounding strategy to governance, and where Sanity Context fits.
The retrieval architecture question matters more than most teams expect. Several of the patterns here use Sanity Context, specifically its Context MCP endpoint, for schema-aware GROQ queries against structured documentation that editors already govern.
Start with the failure mode: why agents answer from the internet
When a support agent hallucinates, the root cause is almost never the model, it's that the model had nothing reliable to ground against, so it fell back on its training data. That training data is the internet circa its cutoff: blog posts about old versions of your product, Stack Overflow answers for the competitor's API, and patterns it has seen a thousand times that look right but aren't yours. The fix is to make retrieval the agent's first move on every question, and to make that retrieval pull from your documentation rather than its parametric memory. In practice that means a system instruction that forbids unsourced answers, a retrieval step that runs before generation, and a content store that actually contains the answers in a queryable shape. Get any of those three wrong and the agent quietly reverts to guessing. The hard part is rarely the prompt, it's that most teams point the agent at a content store that was never designed to be queried by a machine, so retrieval returns thin or stale matches and the model improvises to fill the gap.
Get your docs into a shape an agent can actually query
A PDF dump or a pile of marketing pages is not a retrieval corpus. For an agent to read your docs reliably, the content needs to live somewhere queryable, with structure the agent can filter and rank against, product, version, audience, status. Sanity stores content in the Content Lake, a queryable content store that is the backbone of the Sanity Context retrieval path, so the same documents your editors maintain are the documents the agent reads. Knowledge Bases (launching September 2026) extend that by turning datasets, websites, PDFs, and support databases into agent-readable documents that share the Sanity Context retrieval path, so the half of your knowledge that lives in legacy support systems doesn't get stranded outside the agent's reach. The principle is the same either way: don't build a parallel copy of your content for the agent to read. Read the content you already govern, in the store you already trust, so there's exactly one source of truth and no drift between what a human sees and what the agent retrieves.
Use hybrid retrieval so the agent finds the right passage, not a vibe
Pure semantic search returns things that feel related; pure keyword search misses paraphrase. Support questions need both, a user asking about a 'rate limit error' should match the doc that calls it a 'throttling response,' but an exact error code or flag name must hit precisely. That's why production retrieval blends the two. In Sanity, you do this in a single GROQ query: `text::semanticSimilarity()` for meaning-based matching alongside a BM25 `match()` for keyword precision, blended with `score()` and `boost()` so you can weight fresh or canonical docs higher. Because this runs natively inside the Content Lake, there's no separate vector database to provision, sync, and keep consistent with the source content. The embeddings are dataset embeddings, tied to the content itself, so when an editor corrects a doc, the embedding updates within minutes rather than waiting on a nightly re-indexing job. The retrieval the agent runs is always querying the current state of your documentation, not last week's snapshot of it.
Govern the agent's instructions the way you govern the docs
An agent's behaviour is content too: the system instructions, the answer policies, the escalation rules. Treating those as config buried in application code means only engineers can change them, and changes ship with no review and no staging. The better pattern is to let the people who own the documentation also own the rules the agent follows when it reads that documentation. With Sanity, agent instructions live in Studio, where editors can version and review them, and Content Releases let teams stage agent behaviour the same way they stage a website change, preview it, approve it, then publish. So when support discovers the agent is over-promising on refunds, a content editor adjusts the policy and stages it, rather than filing an engineering ticket. Agent Actionsschema-aware APIs for generate, transform, and translate workflows, let you keep the underlying docs current with the same governed pipeline. The agent and the content it reads are managed in one place, by the people accountable for both.
Connect it to production and keep retrieval the source of truth
Once content is queryable and instructions are governed, the agent needs a stable interface to the retrieval path. Production agents connect to the Sanity Context MCP endpoint, which exposes the same Content Lake retrieval the rest of your stack uses, so a chat widget, an internal Slack bot, and a ticket-deflection flow all read the identical documents and resolve a given question the same way. The discipline that makes this work is making retrieval non-optional: the agent must cite a retrieved passage or decline, never fill silence with a guess from training data. When you wire it this way, 'reads your docs, not the internet' stops being a prompt you hope holds and becomes the architecture. The model's only path to an answer runs through your governed content, and the failure mode flips from confident hallucination to an honest 'I don't have that documented yet', which is the answer you actually want from a support agent that doesn't know.