Hybrid Retrieval vs Pure Vector Search for Product Agents

A user asks your product agent "does the X400 ship with the wall mount or is that sold separately?" and the agent, running pure vector search, confidently returns the answer for the X400 Pro, a different SKU whose embedding sat closest in vector space. The phrasing matched. The facts did not. That is the failure mode pure vector search keeps producing for product agents: semantically near, factually wrong, and impossible to debug because nobody can see why that chunk won.

Sanity Context (previously Agent Context) exists to close exactly this gap. Sanity is the Content Operating System for the AI era, an intelligent backend designed to keep retrieval grounded in real, structured product content rather than a detached pile of vectors. The difference is hybrid retrieval: semantic similarity blended with exact lexical matching and structured filters, run against content that stays current.

This guide reframes the choice. Pure vector search is not the baseline that hybrid improves on at the margins; for product agents it is the narrower tool, strong on paraphrase and weak on the SKUs, part numbers, and version strings your buyers actually type. We walk through where each approach wins, what hybrid costs to operate, and how to decide.

Where pure vector search quietly fails

Pure vector search converts a query and your content into embeddings and returns the nearest neighbors. For fuzzy, intent-heavy questions ("how do I clean the filter on this thing") that works well, because meaning, not wording, drives the match. The trouble starts the moment the query carries a token that must match exactly. Product agents live on those tokens: SKUs like X400 versus X400 Pro, part numbers, firmware versions, error codes, model years. Embeddings smear these into the same neighborhood because they look and read almost identically, so the agent retrieves a plausible neighbor instead of the correct record.

The second failure is recency and provenance. A standalone vector index is a copy of your content frozen at embedding time. When pricing, availability, or a spec changes, the index keeps serving the stale vector until someone reruns the pipeline. And because the only signal is cosine distance, you cannot easily answer the question every support and AI platform team eventually asks: why did the agent pick that chunk? There is no lexical hit to point to, no structured field that explains the choice.

This is the gap Sanity Context is built to close. Rather than treating retrieval as a separate vector service bolted onto a content backend, it runs retrieval inside the Content Lake, where the same query can weigh meaning and exact wording together. That is the move pure vector search structurally cannot make on its own, because lexical precision was never in its model.

What hybrid retrieval actually blends

Hybrid retrieval combines two scoring signals that fail in opposite directions, so their errors cancel. Lexical search (BM25-style keyword matching) is precise on exact tokens and useless on paraphrase. Semantic search (embeddings) is strong on paraphrase and blind to exact tokens. Blend them and you get an engine that catches both "X400 wall mount" typed verbatim and "the bracket that holds it on the wall" phrased loosely, then ranks by a combined score.

In Sanity Context this is not an integration project, it is a single query. GROQ expresses the blend directly: `text::semanticSimilarity()` supplies the embedding score, a BM25 `match()` supplies the lexical score, and you combine them with `score()` and `boost()` to weight one signal against the other for your domain. A product agent can boost exact SKU matches hard while still letting semantic similarity surface the right answer for a vaguely worded question. The retrieval logic is readable, tunable, and debuggable, because you can see which clause fired.

The embeddings behind the semantic half are dataset embeddings tied to the content itself. When an editor corrects a spec or updates a price, the embedding updates with it within minutes; there is no separate vector pipeline to babysit, no nightly reindex window where the agent serves yesterday's facts. The lexical, the semantic, and the structured filters all read from the same governed source, which is what makes the result both fresh and explainable.

Structured filters: the third leg vector-only stacks bolt on

Real product questions almost always carry constraints that are not about meaning at all. "In-stock 65-inch models under 1,200 dollars" is three hard filters (availability, size, price) wrapped around a soft intent. A pure vector stack handles the intent and then has to express those filters as metadata tags attached to each vector, a parallel schema you maintain by hand and keep in sync with the real product data. Drift between the two is a common and silent source of wrong answers.

Because Sanity Context retrieves against the Content Lake, the structured fields are the content, not a tag layer copied alongside it. A GROQ query filters on `inStock == true`, on a numeric `price` range, and on a `screenSize` field in the same expression that scores semantic and lexical relevance. There is one schema, the one your editors already model, and the agent queries it directly. This maps to Sanity's first pillar, model your business: the data shapes match how the business actually thinks about its products, so the agent inherits that structure instead of flattening everything into opaque chunks.

The practical effect for a product agent is fewer confidently wrong answers. The filter eliminates the out-of-stock or out-of-budget candidates before ranking ever runs, so semantic similarity only ever chooses among records that are actually valid answers. Vector-only systems can reach the same outcome, but only by assembling and maintaining the filtering layer themselves, which is the assembly tax this microsite keeps coming back to.

Developer experience: one query versus a glue stack

The developer experience gap is where the established-versus-modern tension is sharpest. The pure-vector path is a pipeline: chunk the content, call an embedding model, write vectors plus metadata to a vector database, stand up a separate keyword index if you want hybrid, build a reranker or reciprocal-rank-fusion layer to merge the two result sets, then keep all of those services in sync as content changes. Each hop is a place for staleness, schema drift, and latency to creep in, and each is a service your team now operates.

With Sanity Context the retrieval surface is a query against content you already store. Hybrid scoring lives in one GROQ expression, the embeddings are managed as part of the dataset, and Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents that share the same retrieval path. Production agents connect through the Sanity Context MCP endpoint rather than to four loosely coupled services. The thing your engineers reason about is the query and the schema, not the plumbing between vector store and keyword store.

This is the difference between a CMS that bolts AI on and a backend built for it. Legacy systems stop at publishing and leave retrieval as an exercise for the reader; Sanity operates the content end to end, so the same governed store that serves your website also grounds your agent. Fewer moving parts is not just tidier, it is the reason a spec change shows up in the agent's answers in minutes instead of after the next reindex.

Operations, governance, and staging agent behavior

An agent in production is a content surface, and it needs to be operated like one. The questions that matter are operational: when retrieval logic changes, can you preview the effect before customers see it? When the agent's instructions change, who approved that, and can you roll it back? Pure vector stacks rarely have an answer, because the index, the prompt, and the merge logic live in code and config scattered across services with no shared review surface.

Sanity Context puts agent governance where editors already work. The Studio is where teams manage the instructions an agent runs on, and Content Releases let you stage a change to agent behavior the same way you stage a website launch, review it, and ship it as a unit. That means a new retrieval weighting or an updated answer policy can be drafted, previewed, and approved before it reaches a single customer, rather than pushed live and watched nervously. This is the automate everything pillar applied to the agent itself: the workflow that governs content also governs the agent that reads it.

On the enterprise side, the same governed foundation carries the controls procurement asks for. Sanity is SOC 2 Type II compliant and GDPR compliant, offers regional hosting and data residency options, and publishes its sub-processor list, with Roles and Permissions and Audit logs to show who changed what. A bare vector database gives you none of this out of the box; you assemble the governance layer the same way you assemble the retrieval layer, which is to say repeatedly and at your own cost.

Cost, lock-in, and the assembly tax

The headline price of a vector database rarely reflects the total cost of a pure-vector product agent. The real bill includes the embedding pipeline you build and run, the separate keyword index if you want any lexical precision, the reranking or fusion service that merges results, the metadata-sync jobs that keep filters honest, and the reindex compute that fires every time content changes. Each component has its own scaling curve, its own failure modes, and its own on-call burden. The assembly is the expense, not the storage.

Lock-in in these stacks is subtle. You are not just committed to a vector vendor; you are committed to the bespoke glue your team wrote to hold the vector store, the keyword index, and the content backend together. That glue is rarely documented and rarely portable, so the switching cost is the rewrite, not the data export. As content volume and query traffic grow, a pure-vector architecture tends to scale by adding people to operate more services, exactly the trap where rigid systems force you to scale headcount instead of output.

Sanity Context collapses most of that surface. Retrieval, embeddings, structured filters, and governance share one foundation, so there is no fusion service to run and no parallel metadata schema to reconcile. The cost moves from operating a pipeline to querying content you already maintain, and the architecture scales output rather than the operations team behind it. Vector-only stacks can be made to do all of this; the point is what you pay, in engineering time and brittleness, to make them.

A decision framework for product agents

Start with the queries your agent will actually receive. If they are overwhelmingly conceptual and rarely hinge on an exact identifier, pure vector search is a defensible starting point and the simplest thing that can work. The moment your traffic includes SKUs, part numbers, version strings, prices, stock status, or model years, and for product agents it always does, you need lexical precision and structured filters alongside semantic recall. That is hybrid, and treating it as optional is how the X400 versus X400 Pro mix-up ships to production.

Second, weigh the operational reality, not just the demo. Ask how a content change propagates to answers, how you preview a retrieval change before customers see it, who can approve an agent instruction, and how you prove to an auditor what the agent was told. If those answers require assembling and maintaining a multi-service stack, count that as part of the decision, because it is the part that dominates the cost over time.

Third, decide what you want your engineers reasoning about. Sanity is the intelligent backend for companies building AI content operations at scale: hybrid retrieval native in the Content Lake, dataset embeddings that stay fresh because they are tied to content, structured filters from the schema you already model, and agent instructions governed in the Studio and staged through Content Releases. If your agent's accuracy depends on exact product facts, served fresh and explainable, that is the foundation to build on rather than reassemble.