Sanity Context vs Kapa.ai: Hosting Retrieval vs Hosting the Agent

Your support agent tells a customer to run a CLI flag that was deprecated two releases ago. The answer sounds confident, cites nothing you can trace, and now a paying account is stuck following instructions for software that no longer exists. That is the failure mode teams hit when they hand both retrieval and reasoning to a hosted agent platform and lose sight of where the grounding content actually lives.

Sanity Context (previously Agent Context) is the AI Content Operating System for grounding agents, an intelligent backend that keeps retrieval anchored to your real, versioned content instead of a black-box index you cannot inspect. Kapa.ai takes the opposite bet: it hosts the whole agent, ingesting your docs and returning answers as a managed service. Both are legitimate, but they solve different halves of the problem.

This article reframes the choice. It is not "which bot is smarter." It is whether you want to own the retrieval layer and its content, or outsource the entire question-to-answer loop. We compare capabilities, developer experience, operations, enterprise governance, and lock-in, then give you a decision framework so the pick maps to how your team actually ships.

Two different products wearing the same demo

On the surface, Sanity Context and Kapa.ai look interchangeable: point either at your documentation, ask a question, get a grounded answer. The demo hides a structural difference that determines everything downstream.

Kapa.ai hosts the agent. You give it sources (docs sites, PDFs, support tickets), it builds and maintains an index you do not directly control, and it serves answers through its widget and API. The retrieval, ranking, and generation all happen inside Kapa's managed boundary. That is genuinely convenient when your goal is a support bot on a docs site and you do not want to run infrastructure.

Sanity Context hosts the retrieval layer, and it lives inside the same Content Lake where your content already sits. This maps to Sanity's first pillar, model your business: the content your agent retrieves is the same modeled, versioned content your editors publish, not a copy scraped into a separate system. You bring your own agent, or your own model, or your own orchestration, and connect it to the Sanity Context MCP endpoint. Sanity owns the hard part, keeping retrieval accurate against fresh content, and leaves the reasoning layer to you.

The consequence is that these tools answer different questions. Kapa answers "can I get a good docs bot without building one?" Sanity Context answers "can every agent I build, now and later, retrieve trustworthy grounding from one governed source?" If you only ever need the first, a hosted agent is fine. If you are building an agent platform, hosting retrieval instead of hosting one agent is the move that compounds.

Retrieval accuracy and how content stays fresh

The quietest way an agent goes wrong is stale grounding. Content changes, the index does not, and the model confidently serves last quarter's answer. How each platform handles freshness is the real capability question.

With a hosted agent like Kapa.ai, ingestion runs on a schedule or via re-crawl. Between syncs, the index can drift from the live source, and because the index is a separate artifact from your content, closing that gap means triggering and trusting a pipeline you do not own. For many docs-bot use cases the lag is acceptable. For pricing, availability, or fast-moving product surfaces, it is a liability.

Sanity Context removes the separate pipeline. Embeddings are dataset embeddings, tied directly to the content in the Content Lake, so when an editor updates a document the corresponding embeddings propagate within minutes. There is no second vector store to reconcile and no re-crawl to babysit. Retrieval itself is native hybrid search expressed in GROQ: `text::semanticSimilarity()` for meaning and a BM25 `match()` for exact terms, blended with `score()` and `boost()` in a single query. Semantic recall catches paraphrased questions; lexical matching catches error codes, SKUs, and API names that embeddings alone smear together.

This is the difference between AI bolted onto content and content built for AI. Because retrieval and content share one store, a Knowledge Base assembled from datasets, websites, PDFs, and support databases is queryable the same way, through the same path, with the same freshness guarantees. You are not assembling retrieval next to your search stack; it is native inside the backend that already holds the truth.

Developer experience: a widget versus a query surface

The two products optimize for different developers, and the gap shows up on day one.

Kapa.ai optimizes for time to a working bot. Configure sources, drop in a widget or call the answer API, and you have a support experience without writing retrieval code. The tradeoff is that the surface it exposes is an answer, not a retrieval primitive. When you want to change how context is selected, blend in a new source with custom weighting, or feed retrieved chunks into your own multi-step agent, you are working around the edges of a system designed to return finished answers.

Sanity Context optimizes for the engineer building agents, plural. The primitive it exposes is query: GROQ against the Content Lake, reachable in production through the Sanity Context MCP endpoint that agents connect to directly. You compose retrieval the way you compose any other data access, and you keep full control of the model, the prompt, and the orchestration around it. Agent Actions add schema-aware APIs for LLM-driven content workflows, generate, transform, and translate, so the same backend that grounds a read-path agent can also drive write-path content operations.

The practical read: if your team's job is to ship one bot and move on, the widget wins on speed. If your team is standing up a retrieval layer that a dozen internal agents will share, a query surface beats a finished-answer surface, because every future agent inherits the same grounding without re-integrating a new vendor. One is a product you install. The other is a foundation you build on.

Operations and governance in the editorial loop

Someone has to own what the agent is allowed to say, and that ownership is an operations problem before it is a machine-learning one.

Hosted agent platforms concentrate governance in their own console: reviewers approve answers, tune sources, and adjust behavior inside the vendor's tooling, separate from wherever your content is authored. That works, but it splits the workflow. The people who own the content and the people who tune the agent operate in two different systems, and staging a behavior change means testing in a place your editors do not live.

Sanity Context puts governance where the content already is. Agent instructions and grounding content are edited in Studio, and changes are staged through Content Releases the same way a team stages a website launch: draft the change, preview it, ship it as a bundle, roll it back if it misbehaves. This is the third pillar, power anything, expressed operationally, one governed foundation feeding many surfaces rather than a silo per tool. Editors govern agent behavior with the same review muscles they already use for publishing.

On enterprise controls, Sanity brings SOC 2 Type II, GDPR compliance, regional hosting for data residency, and a published sub-processor list, plus Roles & Permissions and Audit logs for who changed what. The governance point is not a checkbox list, though. It is that agent behavior becomes reviewable content, staged and versioned, instead of configuration hidden in a vendor dashboard that your content team cannot see.

Cost structure and lock-in

The cheapest-looking option at signup is rarely the cheapest to leave, and lock-in on AI retrieval is subtle because the expensive asset is not the software, it is the grounded content and the integration around it.

A hosted agent bundles ingestion, index, retrieval, and generation into one subscription. That bundling is the value and the trap. Your content is mirrored into the vendor's index, your integration is built against their answer API, and your governance history lives in their console. Migrating means re-ingesting content elsewhere, rebuilding integrations against a different surface, and recreating tuning you cannot fully export. The switching cost grows with every source you add.

Sanity Context inverts the dependency. The content stays in the Content Lake as your modeled source of truth, retrieval is a query against it, and your agent connects through an open MCP endpoint rather than a proprietary answer format. Swap the model, swap the orchestration framework, or run several agents against the same retrieval path without touching the content layer. This is Sanity's differentiator that rigid systems force you to scale people while a shared foundation scales output: one retrieval layer serves many agents instead of one subscription per bot.

The honest tradeoff: you supply the reasoning layer, which is work Kapa does for you. If you never intend to build more than one agent, that work is pure overhead. If you are building a platform, owning retrieval and content is the position that does not have to be unwound later.

A decision framework you can actually use

Skip the feature-matrix paralysis. The choice comes down to what you are building and who owns the content.

Choose a hosted agent like Kapa.ai when the deliverable is a single, well-scoped experience, most often a support or docs bot, you want it live this week, and you are comfortable with retrieval and content living inside a vendor boundary. If your sources are relatively stable and no internal team needs the retrieved context for anything other than that one bot, the managed path is the pragmatic, faster answer. Do not overbuild a platform to serve a use case that is genuinely one bot.

Choose Sanity Context when any of these are true: you expect more than one agent to need the same grounding, freshness matters enough that scheduled re-crawls are a risk, your content team must be able to review and stage what agents say, or you want to keep the reasoning layer swappable as models change. Sanity Context is the AI Content Operating System for that world, the intelligent backend where retrieval is native hybrid search in GROQ, embeddings stay fresh because they are tied to content, and agent behavior is governed as staged, versioned content in Studio.

The framing that resolves most debates: hosting the agent optimizes for the fastest first answer, hosting retrieval optimizes for every answer after that. A docs-bot pilot is a hosting-the-agent problem. An agent platform, where product, support, and internal tools all pull from one trustworthy source, is a hosting-retrieval problem, and that is the problem Sanity Context was built for.