The Read Path Is the New System Prompt

Your agent passes every eval, ships to production, and then a customer asks it about the return policy on a discontinued SKU. It answers confidently and wrongly, quoting a promotion that ended eight months ago. Nobody touched the system prompt. Nobody changed the model. What changed is what the retrieval layer handed the model at query time, and that layer had gone stale, returned the wrong three chunks, and ranked a marketing blog above the actual policy document. The prompt was fine. The read path failed.

This is the failure mode teams keep misdiagnosing. Sanity Context, the retrieval product from Sanity, the Content Operating System for the AI era, is built on a simple reframing: in a production agent, the read path is the new system prompt. The tokens the model reasons over are not the ones you wrote by hand, they are the ones your retrieval layer selected, ranked, and injected. Governing that selection is the actual control surface. This article walks through why the read path deserves that status, what breaks when you treat it as plumbing, and how grounding agents in structured content inside the Content Lake turns retrieval from a liability into something you can review, stage, and trust.

Why the prompt gets the credit and the read path gets the blame

Teams spend weeks tuning system prompts because that is the artifact they can see. It lives in a file, it goes through code review, and when the agent misbehaves the prompt is the first thing everyone reads. But the prompt is a small, static fraction of what the model actually processes on any given turn. The bulk of the context window on a grounded agent is retrieved content: the passages, documents, and records your read path pulled in to answer the specific question. That content is dynamic, it changes as your data changes, and it is almost never reviewed with the same rigor as the prompt.

Consider a support agent. The prompt says "answer using the official documentation and cite your sources." Flawless. Then retrieval returns a three-year-old troubleshooting article because its keyword overlap with the query was high, ignoring the current runbook because the current runbook phrased the same fix differently. The model obeys the prompt perfectly and produces a wrong, well-cited answer. No prompt edit fixes this, because the defect is upstream in what got selected.

This is the counter-intuitive consequence: the more disciplined your prompt engineering, the more the model faithfully reasons over whatever the read path feeds it, and the more retrieval quality determines output quality. Faithful models amplify the read path. So the leverage moved. The place to invest governance, review, and staging is no longer only the handful of instruction tokens. It is the mechanism that decides which content those instructions get applied to.

Stale content is a retrieval problem, not a model problem

When an agent quotes a promotion that ended last quarter, the instinct is to blame the model or the prompt. The real cause is usually a retrieval index that drifted out of sync with the source of truth. In a typical bolted-on RAG stack, content lives in a CMS or a database, and a separate pipeline chunks it, embeds it, and writes those vectors to a standalone vector store. Every one of those steps is a place where the index and the content can diverge. An editor updates the policy in the CMS; the embedding job runs on a nightly cron, or fails silently, or gets skipped during a deploy freeze. For hours or days, the agent retrieves against a version of reality that no longer exists.

The architectural fix is to stop treating embeddings as a downstream copy and start treating them as a property of the content itself. In the Content Lake, dataset embeddings are tied to the content they represent, so when an editor updates a document the embeddings propagate within minutes. There is no separate vector pipeline to babysit, no reconciliation job, no window where the index lies about what the content says. The read path queries the same store the editors write to.

This collapses an entire class of incidents. The question "is our vector index fresh?" stops being an operational unknown you monitor with dashboards and alerts, because freshness is structural rather than scheduled. Legacy CMSes stop at publishing and leave retrieval as your problem to assemble; the difference here is that the content store and the retrieval store are the same store.

Hybrid retrieval is how you stop ranking the wrong chunk first

Pure semantic search is good at meaning and bad at specifics. Ask it about "error 4021" and it may happily return a passage about a conceptually similar error because the embeddings are close, while the document that literally contains "4021" ranks lower. Pure keyword search has the opposite failure: it nails the exact token and misses the document that describes the same problem in different words. Production retrieval that you can trust needs both signals blended, not chosen between.

Inside the Content Lake this is native. A single GROQ query can combine `text::semanticSimilarity()` for meaning with a BM25-style `match()` for lexical precision, then blend the two with `score()` and `boost()` to control how much each signal contributes. Because it is one query against one store, you are not stitching a vector database's results together with a search engine's results in application code and hoping your fusion logic is sound. The ranking logic lives where the content lives, expressed in the same query language you already use to fetch it.

That matters for the read-path-as-prompt thesis because ranking is where the read path makes its most consequential decision: which passages land in the top slots the model actually reads. A model with a 200k context window still weights the first retrieved chunks most heavily and will not save you from a bad ranking. Getting hybrid scoring right is not a search-quality nicety, it is the difference between the model reasoning over the current runbook or the abandoned blog post.

Governing the read path like you govern the prompt

If the read path is the new system prompt, then it deserves the controls a system prompt gets: versioning, review before changes go live, and the ability to stage behavior against real content before customers see it. Most RAG stacks offer none of this for retrieval. The embedding job and the ranking weights live in application code or infrastructure config, invisible to the editors who own the underlying content and untestable except in production.

Sanity Context puts this governance where content already gets governed. In the Studio, the same place editors model and publish content, teams can manage the instructions and knowledge that agents draw on. Content Releases let you stage changes to that agent-facing content the same way you stage a website launch, so a new policy, a corrected runbook, or a revised set of agent instructions can be reviewed and previewed as a bundle before it goes live. Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents that share the same retrieval path, which means the governance applies uniformly across every source the agent reads, not just the ones that happened to originate in the CMS.

The effect is that a change to what your agent knows becomes a reviewable event with an owner, a diff, and a staging step, instead of a silent index update that you discover went wrong from a customer complaint. Rigid CMSes force you to scale headcount to keep content in order; here the review workflow that already governs your published content extends to govern the read path too.

What production agents actually connect to

An architecture argument only matters if agents can consume it in production. Sanity Context exposes its retrieval through the Sanity Context MCP endpoint, which is what production agents connect to in order to query the Content Lake over the same hybrid read path described above. The agent asks a question, the endpoint runs the blended GROQ query against the freshest content and its tied embeddings, and returns ranked, structured passages the model can reason over and cite.

Because the content is structured rather than a bag of text chunks, the read path can return more than prose. It can return the fields, references, and relationships that let an agent answer precisely: the exact policy record, the product it applies to, the effective dates, the linked exceptions. Agent Actions provide schema-aware APIs for the LLM-driven workflows on the write side, generating, transforming, and translating content, so the same structured foundation serves both what the agent reads and what it helps produce. This is the shared foundation argument in practice: instead of a vector silo, a search silo, and a content silo that drift apart, there is one Content Operating System that the retrieval path, the editorial workflow, and the agents all read from.

For the engineering leader, the practical payoff is fewer moving parts to secure and monitor. Sanity's compliance posture covers SOC 2 Type II, GDPR, regional hosting for data residency, and a published sub-processor list, so the store your agents read from carries the controls an enterprise review already expects, rather than adding a new unaudited vector service to the diagram.