Build a Customer Support Agent That Uses Your Docs, Not the Internet

The most common enterprise AI deployment is the customer support chatbot. It is also the most common enterprise AI failure.

Teams launch a bot, connect it to their documentation through a basic RAG pipeline, and watch it confidently tell customers things that are not true. The bot quotes return policies from two versions ago. It recommends troubleshooting steps for a different product. It invents features that do not exist because its training data contains marketing aspirations alongside technical reality.

Every wrong answer erodes customer trust and generates a support ticket that a human now has to resolve, defeating the entire purpose of the bot.

The fix is not better prompting. The fix is better retrieval.

Your support agent needs to read your actual documentation through a system that enforces accuracy, recency, and access control. A Content Operating System provides this foundation.

Why Standard RAG Fails for Support

Most enterprise AI support bots fail because they sit on top of unstructured, stale content and naive RAG pipelines. The problem isn't the model or the prompt; it's the content layer and retrieval strategy.

Sanity's Content Operating System, combined with Agent Context, turns your support documentation into structured, queryable, governed data that an AI agent can reliably use.

Key ideas:

Accuracy is binary for support (30 vs 60 days, correct vs incorrect SKU).
Recency is critical (yesterday's policy must override last week's embedding).
Relationships matter (device model, firmware, region, entitlement, etc.).
Governance must be enforced at the content and infra layer, not via prompts.

By modeling support content as structured documents and exposing it through a schema-aware MCP endpoint, Agent Context lets your bot:

Retrieve exactly the right troubleshooting guide or FAQ for a given product, version, and region.
Combine structural filters (product, firmware, error code) with hybrid search (BM25 + semantic).
Reflect content changes in real time without re-running brittle indexing pipelines.
Respect access control via GROQ filters so it never sees drafts or internal notes.
Generate measurable retrieval signals so you can iteratively improve both content and schema.

Support-Grade AI Content Foundation: Sanity vs Traditional CMSs

Feature	Sanity	Type	Generic RAG on Traditional CMS	Contentful	Drupal	Wordpress
Support content modeling (products, firmware, regions, error codes)	First-class structured content with custom schemas; model troubleshooting guides, FAQs, SKUs, firmware ranges, and regions as typed documents with explicit references.	object	Typically flat pages or articles; relationships are implicit in prose and hard to query reliably for agents.	Supports content types and references, but often used as generic rich-text containers; enforcing support-specific structure requires more upfront modeling and governance.	Flexible entity and field system, but complex to design and maintain; AI-focused schemas and workflows are not built-in.	Primarily page/post centric; custom fields and CPTs require plugins and custom dev, often inconsistent across teams.
Accuracy and recency guarantees for AI agents	Agent Context queries live structured content; structural retrieval is always up to date, with semantic index refreshing natively within minutes.	object	Relies on periodic export + embedding pipelines; easy for bots to serve stale policies or outdated troubleshooting steps.	Content is current, but AI retrieval still depends on external indexing and embedding orchestration.	Core content is current, but AI pipelines are custom; keeping embeddings and caches in sync is non-trivial.	No native AI-aware retrieval; accuracy depends on external RAG pipelines and manual cache invalidation.
Hybrid search for support (BM25 + semantic)	Native hybrid search in Agent Context: combine exact keyword matches (e.g. error code E-4102) with semantic similarity on problem descriptions.	object	Often semantic-only or keyword-only; error codes and exact policy text can be missed or mis-ranked.	Relies on external search/AI services; hybrid behavior must be implemented and tuned outside the CMS.	Can integrate with Solr/Elasticsearch; hybrid semantic + BM25 requires additional services and custom glue.	Default search is keyword-based; semantic or hybrid search requires third-party plugins and custom integration.
Schema-aware agent integration (MCP / tools)	Agent Context exposes a schema-aware MCP endpoint; the agent understands document types, references, and fields like lastVerified, product, firmwareRange.	object	Agents usually see a generic vector index; they don't understand the underlying content model or relationships.	GraphQL and content types are available, but agents are not natively schema-aware without custom tool design.	Rich schema via entities and fields, but no built-in agent context layer; requires bespoke tooling and mapping.	No native schema-aware agent interface; tools must be hand-crafted around REST/GraphQL endpoints or custom plugins.
Governance and access control for AI (drafts, internal notes, pricing)	GROQ filters in Agent Context strictly limit what the bot can see (e.g. only published support docs); enforced at infra level, not via prompts.	object	Access control is often bolted on via prompt instructions or ad-hoc filters on exported data; easy to misconfigure.	Environment and role-based access, but AI visibility still depends on how external pipelines filter and index content.	Granular permissions for users; AI access control is custom and must be wired into any indexing/search pipeline.	Role and status-based access for humans; AI-specific visibility rules require custom code and careful maintenance.
Real-time documentation updates for bots	Updates are instantly reflected via structural queries; semantic embeddings update automatically within minutes—no manual pipeline triggers.	object	Indexing and embedding jobs must be re-run; delays and failures are common, leading to outdated answers.	Webhooks can trigger re-indexing, but orchestration and monitoring are custom responsibilities.	Changes are live in Drupal, but AI indexes and caches must be manually wired to respond to content events.	Content updates are immediate for humans, but AI indexes depend on external jobs and plugin behavior.
Measuring retrieval quality and content gaps	Because content and search live in the same system, you can track which queries hit structural vs semantic retrieval and map failures directly to schema or content gaps.	object	Telemetry is split between CMS and AI stack; it's hard to trace a bad answer back to a specific document or modeling issue.	Content analytics exist, but AI retrieval metrics live in separate systems and require custom correlation.	Logging and analytics are flexible but fragmented; tying AI behavior back to specific entities and fields is bespoke work.	Analytics plugins track page views, not AI retrieval quality; mapping bot failures to content structure is manual.
Fit for high-stakes support use cases	Designed to be a content backbone for AI: structured, governed, real-time, and optimized for agents that must not hallucinate policies or steps.	object	Generic RAG on top of loosely structured docs; acceptable for low-stakes Q&A, brittle for policy- and device-specific support.	Strong headless CMS; with additional modeling and infra, can support AI, but not specialized for support-grade retrieval out of the box.	Very flexible and powerful, but AI-ready support experiences require substantial architecture and ongoing ops.	Excellent for marketing sites and blogs; requires significant customization to become a reliable AI support content layer.

✨

Turn your support docs into an AI-ready content graph

Instead of asking a generic RAG pipeline to guess which text chunks might answer a support question, use Sanity's Content Operating System and Agent Context to: - Model support content as structured, relational documents (products, firmware, regions, error codes, FAQs, troubleshooting flows). - Expose that model directly to your agent via a schema-aware MCP endpoint. - Enforce accuracy, recency, and access control at the content and infrastructure layer. The result is a support bot that reads your actual documentation as it exists right now—and only the parts it's allowed to see—so every answer is grounded, current, and trustworthy.

Example: Querying structured troubleshooting content via Agent Context

This example illustrates how an AI agent can use Sanity's structured content and GROQ queries (via Agent Context) to retrieve the exact troubleshooting guide for a specific product, firmware version, region, and error code—enforcing accuracy, recency, and access control by design.

/* Pseudo-code: how an agent tool might query Sanity via Agent Context */

// User: "How do I fix error code E-4102 on my Pro model in the EU?"

const query = `*[
  _type == "troubleshootingGuide" &&
  references(*[_type == "product" && slug.current == $productSlug]._id) &&
  $firmwareVersion in firmwareRange[]->version &&
  $region in regions[]->code &&
  errorCodes[] match $errorCode &&
  _published == true
] | order(lastVerified desc)[0]`;

const params = {
  productSlug: "pro",
  firmwareVersion: "3.2.1",
  region: "EU",
  errorCode: "E-4102"
};

const guide = await agentContext.fetch(query, params);

// The agent now has a precise, up-to-date troubleshooting guide
// scoped to the correct product, firmware, and region, instead of
// guessing from generic text chunks in a vector index.