Sanity vs Kapa.ai: CMS-Owned Knowledge vs Hosted Bot

Your support bot can answer "how do I reset my API key" all day. Then a logged-in customer asks "am I over my quota?" and it has nothing, because the hosted bot you bought indexes your docs, not your live account state. Sanity hit exactly this wall as a Kapa.ai customer: it could not get data about logged-in users into the Kapa support agent, so it built its own agent that now knows the tier of a logged-in user and whether they are above quota. That gap is the whole argument.

This is the established-versus-modern tension at the heart of buying versus owning your AI assistant. A hosted bot like Kapa.ai is fast to stand up and genuinely good at grounding answers in technical sources. But it is a separate system you feed and re-index, and your content, your retrieval, and your agent's system prompt all live in its UI, not yours. Sanity is the Content Operating System for the AI era, the intelligent backend where retrieval, freshness, and governance are native to the content layer rather than bolted on around it.

This article reframes the choice. It is not "which bot answers docs questions better." It is whether your knowledge, your live data, and your agent's behavior should be governed like content you own or rented from a vendor you re-index.

The failure mode: a bot that knows your docs but not your customer

Hosted assistants are built around one assumption: the knowledge worth answering from is your documentation, and it sits still long enough to index. Kapa.ai is excellent at this. It crawls 30+ technical sources, documentation, code, PDFs, support tickets, and community content, then grounds answers in them and deploys as a website 'Ask AI' widget, Slack and Discord bots, a Zendesk agent, and a hosted MCP server. For a pure docs question, that is a strong out-of-the-box experience.

The failure mode shows up the moment the question is not about docs. A logged-in user asks whether they are above their plan quota, what is in their cart, or why their last invoice looks wrong. None of that lives in your documentation. It lives in your session, your account records, and your structured content. A hosted bot you feed has no clean path to that live first-party state, because it indexes published sources, not the in-the-moment context of the person asking.

Sanity ran straight into this as a customer. Per the strategy pillars, Sanity could not get data about logged-in users into the Kapa support agent, so it built one itself, and that agent now knows the tier of a logged-in user and whether they are above quota. The lesson is not that hosted bots are bad. It is that the interesting questions are about the customer, and answering them means letting your data inform the conversation: sessions, cart, account, page context, and user history. That is a content-backend problem, not a crawler problem.

Retrieval: hybrid in one query versus a pipeline you keep fresh

"We have embeddings" is not a retrieval strategy. Good retrieval is hybrid: hard predicates that have to hold, blended with keyword and semantic ranking. In Sanity this is one GROQ query. You filter on facts that must be true, then score the rest. A real shape looks like this: *[ _type == "product" && category == $category && price < $maxPrice && stockLocation == $warehouse ] | score( boost([title] match text::query($queryText), 2), text::semanticSimilarity($queryText) ) | order(_score desc) [0...10]. The predicates do the filtering that has to hold. The score pipeline blends a BM25 keyword match on the title, weighted 2x because title hits matter more, with a semantic similarity score across the document.

This matters because pure vector search drifts on intent and ignores the constraints that govern a real answer. Sanity's own production data backs the point. When you look at how agents actually call the Context MCP endpoint, the heavy majority of calls are structured GROQ queries and schema lookups. Semantic search is a small slice, and embeddings are opt-in, off by default, with most projects never turning them on. Vector search and RAG are one ingredient, not the discipline.

A hosted bot or a separate vector database can also do hybrid retrieval. The honest difference is who owns the freshness. With a separate system plus glue code, you own incremental indexing, re-embedding on change, deletion handling, and backfill for schema changes. That work does not finish. It becomes a permanent line item on your roadmap. When retrieval is wired into Content Lake, the index knows when a description updates, a price changes, an article publishes, or a record is deleted, because there is no second copy to keep in sync.

Governance: the system prompt is customer-facing behavior

Here is the part most teams get wrong, regardless of which bot they buy. The agent's application system prompt is customer-facing behavior. It decides voice, what the agent will say about pricing, when it escalates, and what it must never claim. In most teams that prompt is a string in the codebase, buried in something like src/agents/prompts.ts. Marketing cannot read it. Compliance cannot review it. Every change is a pull request, which means the people who own the behavior do not own the artifact.

In a hosted bot, the prompt lives in the vendor's UI instead, which moves the problem rather than solving it. You have traded a Git file for a textarea in someone else's product, still without the review trail and role separation that customer-facing copy demands.

Sanity treats the prompt as content. It becomes a document split into fields, role, voice, userContext, escalation, and the must-not-say list, so access maps to ownership. Brand owns voice. Product owns how the agent uses user context. Support owns escalation. Compliance owns the never-say list. None of them files a pull request. Because it is content in the Studio, you get real-time collaboration, version history, scheduled publishing, and rollback for free, and you can stage agent behavior with Content Releases the same way you stage your website, previewing before you ship. Nearform put it plainly: storing the system prompt in a Sanity document is genuinely useful, and editors tuned the agent's voice without any code changes. Vipps came wanting the whole organization to contribute, with product managers owning the prompt, not just engineers.

Operations: two systems to feed versus one backend that stays in sync

Operationally, a hosted bot is a second system in your stack with its own lifecycle. You publish content in your CMS, then you feed and re-index it into the bot. The two are never quite the same at the same moment, and the gap between them is where wrong answers live. When you delete a deprecated product, retire a policy, or correct a price, you now have two places that need to agree, and the bot's copy lags until the next crawl.

That lag is not a one-time setup cost. It is the freshness problem described earlier, paid forever. Every schema change means a backfill. Every deletion means making sure the bot forgets too. Every edit means trusting that re-indexing happened and succeeded before a customer asked.

When retrieval is native to the content backend, there is one source of truth and no second copy to reconcile. Content Lake handles index freshness automatically, and Context MCP exposes that content to any agent loop as a hosted read-only endpoint. The mental model matters here: Sanity Context is not only an MCP. It has the MCP surface, a knowledge base, and an ingest path, so messy sources like support databases, websites, and PDFs become well-ordered documents with a clear table of contents that agents answer from faster, more accurately, and at lower cost. Writes and content mutations route through Agent Actions and Functions, keeping the read path clean and governed. One backend, kept current by the act of publishing, instead of two systems you manually hold in alignment.

Enterprise needs: bring your own model, your own data, your own controls

Enterprise buyers care about three things a hosted bot constrains by design: which model answers, what data the model can see, and who can audit the behavior. On model choice, customers in the strategy pillars were blunt. JP Malone of ADT said it directly: "So yeah, we would set up our own. We would just choose our own model." Owning the agent means bringing your own LLM for cost and quality control, rather than accepting whatever the hosted product runs and prices around.

On data, the enterprise requirement is that the agent can see live first-party state, the same gap that pushed Sanity off Kapa for its own support. The agent should do real work: show custom UI, call APIs, and act on session, cart, account, and page context, not just retrieve published documents. ADT was already running a third-party chatbot, Sierra AI, and noted how interesting it was that owning your own had become easy. The pattern across these accounts is the same: capable hosted tools, bounded by the fact that the content and the prompt live in the vendor's system.

On controls, Sanity brings the governance you already use for the website to the agent: drafts, scheduling, history, permission gating, and audit trails, alongside SOC 2 Type II, GDPR, regional data residency, and a published sub-processor list. The point is not that a hosted bot lacks security. It is that an agent governed by your existing Studio workflows inherits one consistent control plane, instead of adding a separate compliance surface to review for every vendor you feed.

Cost, lock-in, and a decision framework

The cost conversation is rarely about a monthly invoice. It is about what you own at the end. Walter Colindres of Jack in the Box framed the discomfort precisely: "$200,000 dollars going out the door does not make me feel comfortable for something that we could ultimately kind of build and own and operate for way less over time." That is the lock-in question. With a hosted bot, your knowledge is indexed in their system, your prompt lives in their UI, and your retrieval behavior is shaped by their product. Leaving means rebuilding.

The decision framework is straightforward once you separate the two jobs. If your only need is a docs assistant on technical content that changes slowly, and you have no appetite to run any of it, a hosted bot like Kapa.ai is a reasonable, fast answer, and it ships strong out of the box. Choose to own the agent when the answers depend on live customer state, when the system prompt is customer-facing behavior that Brand, Product, Support, and Compliance must govern, when freshness across many edits and deletions would otherwise become a standing line item, or when model choice and data residency are non-negotiable.

Sanity is the answer to the second case because the agent is not a bolt-on. Retrieval, freshness, governance, and the prompt all live in the same backend that already runs your content. Legacy tools stop at publishing and ask you to feed a separate bot. Sanity, the intelligent backend for companies building AI content operations at scale, operates content end-to-end, so the system that authors your knowledge is the same system that answers from it.