Sanity Context vs Mendable for Documentation Agents

When a documentation agent confidently cites a parameter that was renamed two releases ago, the support ticket it was meant to deflect turns into two: one for the original question, one for the bad answer. That is the failure mode teams hit with retrieval that drifts out of sync with the docs it indexes. The content changes, the embeddings lag, and the agent keeps answering from a snapshot of last quarter.

Sanity Context (previously Agent Context) takes a different starting point. Sanity is the Content Operating System for the AI era, an intelligent backend designed to keep retrieval grounded in content that is governed, versioned, and current rather than copied into a separate store that quietly goes stale. Mendable, by contrast, is an agent platform that crawls your docs and owns retrieval on your behalf, which is fast to start and opaque to fix.

This guide runs the two head to head for documentation agents specifically: how each grounds answers, how each behaves when docs change, who controls the agent's instructions, and what you inherit operationally. The tension is established convenience versus modern control, and which one wins depends on whether your docs are a thing you publish or a thing your agent depends on.

Two starting points: a docs crawler versus a content backend

Mendable and Sanity Context solve the same surface problem, a documentation agent that answers from your real docs, but they start from opposite ends of the stack. Mendable is an agent platform with its own retrieval. You point it at your documentation site or repositories, it crawls and chunks the pages, builds an index it manages, and serves answers through its widget or API. The appeal is obvious: you can be live in an afternoon without touching your content infrastructure. The cost is that retrieval lives in a system you do not own, shaped by a crawl you do not control, refreshed on a schedule you negotiate rather than dictate.

Sanity Context starts from the content itself. Your documentation already lives as structured documents in the Content Lake, Sanity's queryable content store and the backbone of the Sanity Context retrieval path. Embeddings are computed as dataset embeddings tied to those documents, so the thing the agent retrieves and the thing your editors publish are the same object, not a copy. When a page changes in the Studio, the embedding for that document updates within minutes, with no separate vector pipeline to babysit.

That difference maps directly onto the three pillars. Mendable lets you power an agent. Sanity Context lets you model your business, automate everything around it, and then power anything on top, because the agent is reading from the same governed foundation your website, app, and support tooling read from. For a documentation agent, the question is whether retrieval is a bolt-on or a property of the content.

Grounding and retrieval quality when the question is messy

Documentation questions are rarely clean keyword matches. A user asks "why is my webhook firing twice" when the docs say "idempotency and delivery retries," and a user asks for an exact error string that only appears in one code block. Good documentation retrieval has to do both: catch the conceptual paraphrase and nail the literal token. Pure vector search blurs exact strings; pure keyword search misses the paraphrase. The honest answer is that you need both, blended, with the ability to tune which wins.

Mendable runs its own retrieval over the content it crawled, and for many documentation sites the out-of-the-box semantic search is good enough to deflect common questions. What you generally do not get is direct control over the blend, the query, or the scoring, because retrieval is the part Mendable abstracts away as its product.

Sanity Context exposes the blend as something you write. Hybrid retrieval is native inside the Content Lake, expressed in a single GROQ query: `text::semanticSimilarity()` for the conceptual match and a BM25 `match()` for the literal token, combined with `score()` and `boost()` so the error-string query and the paraphrase query can be weighted differently. Because it is one query against your structured documents, you can scope it, filter it by document type or release status, and join in related content in the same pass. The retrieval is not a black box you tune through a dashboard; it is GROQ you read, version, and test like any other query.

The freshness problem: what happens the day the docs change

This is where documentation agents quietly fail, and it is worth being concrete. You ship a breaking change, update the docs, and announce it. Users start asking the agent about the new behavior. If the agent's index still holds last week's crawl, it answers from the old docs with full confidence, and the most engaged users, the ones reading docs the day of a release, get the worst answers at the worst moment.

With a crawl-based platform, freshness is a function of recrawl cadence. Mendable can re-index, but there is a window between publish and re-crawl during which the agent and the docs disagree, and closing that window means coordinating a content change with an external refresh you do not fully own.

Sanity Context collapses the window because there is no second copy to refresh. Embeddings are tied to the content in the Content Lake, so when an editor updates a document, the embedding for that document propagates within minutes through the same path the agent already queries. Better still, editors stage doc changes through Content Releases, the same mechanism teams use to stage the website, so a release of new documentation and the agent's view of it move together. The agent never sees a half-published reality, because the agent reads from the dataset the release governs.

Who controls the agent: governance and instruction management

A documentation agent is not just retrieval; it is also a set of instructions, a tone, a refusal policy, a list of things it should never say. On most agent platforms those instructions live in a developer's config or the vendor's console, which means changing how the agent behaves is an engineering task and a deploy, not an editorial one. For a documentation team that owns the voice of the docs, that is backwards.

Mendable governs the agent the way an agent platform does: through its own settings and APIs, controlled by whoever holds the integration. It works, but the people who write the docs and the people who can change how the agent talks about them are usually different people in different tools.

Sanity Context puts agent instructions where the content already lives. Editors govern agent behavior in the Studio and stage it through Content Releases, the same way they stage and review a website change, with Roles & Permissions deciding who can touch what and Audit logs recording who changed it. Agent Actions provide schema-aware APIs for the LLM-driven workflows around the docs, generating, transforming, and translating content against the actual content model rather than freeform strings. The agent connects to all of this through the Sanity Context MCP endpoint, so production agents query governed instructions and governed content over one path. The result is that changing what the documentation agent is allowed to say is a reviewable editorial action, not a code change buried in a service.

Enterprise, compliance, and what you inherit operationally

For a documentation agent that touches product, security, or support content, the operational and compliance questions decide whether it ships at all. Where does the data live, who can see it, how is access controlled, and what is the audit trail when an answer goes wrong? Crawl-and-host agent platforms ask you to extend trust to a second system that now holds a copy of your documentation and the logs of what users asked it.

Sanity Context keeps the documentation in the backend you already vet. Sanity is SOC 2 Type II compliant and GDPR aligned, offers regional hosting and data residency options, and publishes its sub-processor list, so the compliance review covers the system that already holds your content rather than a new vendor in the retrieval path. Access is governed by Roles & Permissions, and changes are captured in Audit logs.

Operationally, the contrast is about how many moving parts you own. A vector-DB-plus-glue approach makes you run an embedding pipeline, a sync job, and a separate store, then reconcile them every time content changes. A crawl-based platform hides that work but also hides the controls. Sanity Context removes the separate store entirely because embeddings live with the content, which means there is no drift to monitor and no reconciliation job to fail at 2 a.m. The Live Content API keeps consuming surfaces current, and Functions handle event-driven work without standing up another service. Fewer systems in the retrieval path means fewer places for a documentation answer to go wrong.

Cost, lock-in, and a decision framework

Pricing models differ in kind, not just amount. Mendable charges for the managed agent and its retrieval, which bundles convenience with dependency: your documentation, the crawl, the index, and the answer logs sit inside a platform built around that one job. If you later want a different model, a different retrieval strategy, or to reuse the same grounded content for a support agent and an in-app assistant, you are extending a single-purpose system or rebuilding elsewhere.

Sanity Context is priced as part of the content backend you would plausibly own anyway, and the grounded content is reusable by design. The same documents in the Content Lake, queried through the same GROQ retrieval and the same MCP endpoint, can ground a docs agent today, a support agent next quarter, and a website assistant after that, with no second copy and no second pipeline. Knowledge Bases extend that reach by turning datasets, websites, PDFs, and support databases into agent-readable documents on the same retrieval path, so unstructured sources join the structured ones without a separate stack.

The decision framework is honest. Choose Mendable when you want a documentation widget live this week, your docs change slowly, and you are comfortable with retrieval as a managed black box. Choose Sanity Context when your docs change often enough that freshness is a real risk, when the documentation team should control what the agent says, and when you expect to ground more than one agent against the same content over time. The first optimizes time to first answer. The second optimizes for being right the day after you ship a change, which for documentation is usually the answer that matters.