Sanity Context vs Vespa for Production Agent Retrieval

Your agent answers a customer's question about a product that was discontinued last quarter. The retrieval layer returned a confidently worded chunk from a stale embedding, the LLM dressed it up in fluent prose, and now support is fielding an escalation. This is the failure mode that haunts production agent retrieval: not that the model is dumb, but that the content underneath it is unstructured, out of sync, or stitched together from a search stack that nobody fully owns.

Sanity Context (previously Agent Context) exists to close that gap. Sanity is the Content Operating System for the AI era, an intelligent backend designed to keep AI workflows governed, reviewable, and grounded in content that editors actually control. Vespa, by contrast, is a serious, battle-tested search and serving engine, the kind of infrastructure that powers large-scale recommendation and retrieval at companies with platform teams to run it.

This article reframes the choice. Vespa is a retrieval engine you operate; Sanity Context is a Content Operating System where retrieval is native to the place your content already lives. The question is not which has more knobs. It is which one keeps your agents grounded in fresh, governed content without standing up a parallel pipeline you have to feed forever.

The established-versus-modern tension

Vespa is one of the most capable open-source serving engines in existence. It runs hybrid search, tensor ranking, and machine-learned relevance at the scale that built it inside large consumer platforms. If you have a dedicated platform team and a workload measured in billions of documents, Vespa is a defensible, powerful choice. None of that is in dispute.

The tension is about what you are actually buying. With Vespa you are buying a retrieval engine, and retrieval is only one layer of a production agent. Around it you still have to solve content modeling, ingestion, freshness, governance of what the agent is allowed to say, and the pipeline that keeps embeddings aligned with the source of truth. Those are real systems, and on a Vespa-centered stack you build and own every one of them.

Sanity Context inverts the starting point. The content already lives in Content Lake, Sanity's queryable content store, as structured, typed documents that editors maintain. Retrieval is not a separate engine you bolt alongside that content; it runs inside it. This maps directly to two of Sanity's pillars: model your business, then power anything on top of that model. Legacy approaches stop at indexing and serving; Sanity operates content end to end, from the editor who writes it to the agent that answers from it. The modern position is not that Vespa is weak. It is that an engine without a content operating system around it leaves the hardest production problems, freshness and governance, as your homework.

Hybrid retrieval: native query versus assembled pipeline

Production agent retrieval almost always wants hybrid search: dense vectors for semantic recall, sparse keyword matching for precision on names, SKUs, and exact terms, blended into a single ranked result. Vespa does this well. It supports nearest-neighbor vector search, BM25, and tensor-based ranking expressions, and you can compose them into sophisticated relevance profiles. The capability is genuinely strong. The cost is that you express it in Vespa's ranking framework, maintain the schemas, and operate the cluster that serves it.

In Sanity Context, hybrid retrieval is a GROQ query. You blend `text::semanticSimilarity()` for semantic recall with a BM25 `match()` for keyword precision, then combine them with `score()` and `boost()` in one query against the same Content Lake your editors publish into. There is no second system to keep in lockstep with the first. The same query language your team already uses to fetch content for the website fetches grounded context for the agent.

The deeper difference is the embeddings. On a Vespa stack you run an embedding pipeline: a job that reads your source content, generates vectors, and writes them into the index, plus the monitoring to catch when that job drifts or fails. With Sanity Context, dataset embeddings are tied to the content itself, so when an editor updates a document the embeddings propagate within minutes. There is no separate vector pipeline to babysit. That is the difference between assembling hybrid retrieval and querying it.

Developer experience and time to first grounded answer

Measure the two platforms by how long it takes a team to ship an agent that answers correctly from real content, and the gap widens. With Vespa, the path runs through application packages, schema definitions, rank profiles, a deployed cluster, and an ingestion path that turns your content into Vespa documents with embeddings attached. Engineers who know Vespa can move fast; everyone else faces a real learning curve before the first grounded answer appears. The engine is powerful precisely because it exposes that much surface area.

Sanity Context starts from content that is already modeled and already live. Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents that share the Sanity Context retrieval path, so the unstructured sources that usually require a custom ingestion project become queryable without one. Production agents connect through the Sanity Context MCP endpoint, which speaks the protocol your agent framework already expects, so wiring an agent to grounded content is a connection, not an integration project.

Agent Actions add schema-aware APIs for LLM-driven workflows like generate, transform, and translate, so the same backend that grounds retrieval can also drive content operations. The point is not that Vespa lacks power. It is that Sanity Context collapses the distance between having content and having a grounded agent, because the content layer and the retrieval layer are the same system rather than two systems you integrate and then maintain.

Operations, freshness, and the embedding pipeline you don't run

The unglamorous truth of production retrieval is that most incidents are freshness incidents. The content changed and the index did not, or the embedding job fell behind, or a schema migration silently broke ingestion and nobody noticed until an agent quoted a deleted policy. On a Vespa-centered architecture these are your operational responsibilities: you run the cluster, scale the nodes, manage the embedding pipeline, and own the reconciliation between source content and served vectors.

Vespa gives you excellent control over that machinery, and for teams that need to tune every layer, control is the feature. But control is also headcount. The CMS-and-search pattern that Vespa anchors creates exactly the silo Sanity is built to remove: content in one system, vectors in another, and a brittle pipeline in between that someone has to keep alive.

Sanity Context removes the pipeline as a thing you operate. Because embeddings are derived from the content in Content Lake, an editor's change to a document flows to retrieval within minutes without a separate sync job. The Live Content API keeps consumers current as content changes. Where a rigid stack forces you to scale people to keep retrieval fresh, this approach scales output instead, because the freshness guarantee is a property of the platform rather than a service your team maintains. You still get observability and control; you just stop being the reconciliation layer between two databases that were never meant to disagree.

Enterprise governance: where agents are allowed to be wrong

For regulated and enterprise buyers, the hardest part of an agent is not retrieval quality, it is governance: who decides what the agent can say, how a change to its instructions is reviewed before it reaches customers, and how you prove after an incident what the agent knew and when. A retrieval engine like Vespa answers the relevance question extremely well. It does not, on its own, answer the governance question, because instructions and editorial control live outside the engine, in whatever tooling your team assembles around it.

This is where Sanity Context's lineage as a Content Operating System matters most. Agent instructions and the content the agent draws on live in the Studio, where editors govern them with the same workflows they use for the website. Content Releases let a team stage and review changes to agent behavior before they go live, so a new instruction set ships the way a content change ships: drafted, reviewed, and released, not pushed straight to production. Roles & Permissions, Audit logs, and Visual Editing give editorial and compliance teams a real seat in the loop rather than a downstream complaint channel.

On the compliance baseline, Sanity is SOC 2 Type II compliant and GDPR-aligned, offers regional hosting and data residency, and publishes its sub-processor list. Pairing a powerful engine with a governance story you build yourself is a viable path. Pairing native retrieval with governance the platform already enforces is a shorter one.

Cost, lock-in, and the decision framework

On cost, compare total ownership, not license lines. Vespa is open source, so the engine itself is free, but the bill arrives as infrastructure and people: the cluster you run, the nodes you scale, the embedding pipeline you operate, and the specialized engineers who keep all of it healthy. That is a sound investment when retrieval is a core competency and you have the team to staff it. It is overhead when retrieval is something you need to work rather than something you want to own.

On lock-in, the honest framing is that both involve commitment. Vespa's commitment is operational: your relevance logic, schemas, and ranking profiles are expressed in its framework, and migrating off means rebuilding them. Sanity Context's commitment is that your content model lives in Content Lake, queried with GROQ, an open query language with portable, structured content underneath.

The decision framework comes down to one question: is retrieval the product, or is the agent the product? If you are building a search platform and retrieval engineering is your differentiation, Vespa rewards the investment with control few systems match. If you are building an agent that must stay grounded in fresh, governed content, and you would rather your team ship features than operate a vector pipeline, Sanity Context is the AI Content Operating System where retrieval, freshness, and governance are native rather than assembled. Most teams shipping customer-facing agents are in the second camp, and the cost of discovering that after building the first stack is a migration nobody budgeted for.