Concepts & Strategy7 min readยท

How to Expose a Single Source of Truth for Agents Across the Web

Your support agent answers a pricing question flawlessly on the website, then contradicts itself an hour later inside Slack, and gives a third answer through the partner API. Same question, three surfaces, three truths.

Your support agent answers a pricing question flawlessly on the website, then contradicts itself an hour later inside Slack, and gives a third answer through the partner API. Same question, three surfaces, three truths. The content did not change; the copies of it did. Each channel pulled from its own snapshot, its own vector index, its own scraped cache, and every one drifted at its own pace. That is the failure mode teams hit the moment agents move past a single chatbot: not hallucination from a bad model, but fragmentation from too many stale mirrors of the same facts.

Sanity Context (previously Agent Context) is built on the AI Content Operating System, the intelligent backend that lets one governed body of content answer every agent, on every surface, from the same source. This article treats "single source of truth for agents across the web" as an architecture problem rather than a prompt problem. We will walk through why copies drift, what a canonical retrieval path actually requires, and how to expose that path to any agent through the Sanity Context MCP endpoint without standing up a separate pipeline per channel.

Illustration for How to Expose a Single Source of Truth for Agents Across the Web
Illustration for How to Expose a Single Source of Truth for Agents Across the Web

Why every agent surface quietly forks your truth

The single-source-of-truth problem does not announce itself. It shows up as a support ticket where the chatbot quoted a promotion that ended last week, or an internal agent citing a policy two revisions out of date. Trace it back and the root cause is almost always the same: the content was copied to serve retrieval, and the copy outlived the original.

Consider the typical build. Product docs live in a CMS. To make them searchable by an agent, a team exports them, chunks them, embeds the chunks, and loads the vectors into a separate database. Now there are two systems of record for the same paragraph, and only one of them gets edited when the fact changes. The vector store keeps serving the old embedding until someone remembers to re-run the pipeline. Multiply that by a second surface (a Slack bot with its own index), a third (a partner-facing API with a nightly scrape), and a fourth (a marketing site widget), and you no longer have a source of truth. You have four caches that agree by luck.

The stakes scale with autonomy. A human reading a stale doc notices the date and shrugs. An agent has no such instinct; it treats whatever retrieval returns as ground truth and acts on it, confidently, at the speed of an API call. When retrieval and the edited content are the same object rather than a copy and its snapshot, the whole class of drift bugs disappears. This is the reframe: you do not fix agent contradictions by tuning prompts, you fix them by making sure every agent reads from one place that is always current.

Model your business so the truth has a shape

A single source of truth is only useful if the truth is structured. A pile of scraped HTML or exported markdown is a single source of confusion; agents retrieve a slab of text and guess at what parts are the answer. The first pillar of the Content Operating System, model your business, is where reliable agent grounding actually begins.

When content is modeled as typed documents with named fields, an agent does not have to infer that the price is a price or that the effective date is a date. A pricing document has a plan reference, an amount, a currency, and a validity window as first-class fields, not as sentences buried in prose. Retrieval can then be precise: fetch the current plan, not the paragraph that happens to mention it. Relationships are explicit too, so an agent answering about a feature can traverse to the plan it belongs to without a fuzzy keyword match hoping the two ended up in the same chunk.

This is the difference between a content backend that adapts to how your business is organized and a generic store that forces your business into rows or free text. Legacy CMSes and vector databases both make you work their way: flatten everything to documents-and-chunks, then hope the chunk boundaries land somewhere sensible. Modeling first means the same structure that powers your website also powers what agents can see, so there is nothing to reshape or re-flatten when a new surface comes online. The shape of your truth is authored once and shared everywhere.

One canonical retrieval path, not one copy per channel

Exposing a single source of truth across the web is a retrieval architecture decision. The question is not where content is stored, it is where every agent goes to read it. If each surface has its own index, you have as many sources of truth as you have surfaces, no matter how disciplined your authoring is.

The alternative is a canonical retrieval path: one query interface over one live store that every agent, on every channel, calls. In Sanity Context, that store is the Content Lake, and the query language is GROQ. Because retrieval runs directly against the Content Lake, the chatbot, the Slack agent, and the partner API are not reading three snapshots; they are reading the same documents through the same queries. There is no per-channel export to fall out of sync, because there is no per-channel copy at all.

Hybrid retrieval lives inside this path rather than beside it. A single GROQ query can blend text::semanticSimilarity() for meaning with a BM25 match() for exact terms, combined with score() and boost() to weight results, so semantic recall and keyword precision are one operation, not two systems you stitch together downstream. Crucially, the embeddings are dataset embeddings tied to the content itself. When an editor corrects a price or retires a policy, the embedding updates within minutes; there is no separate vector pipeline to babysit and no window where the semantic layer disagrees with the edited text. One path in, one truth out, current for every agent that queries it.

Turn scattered sources into one agent-readable corpus

The truth an agent needs rarely lives in one system on day one. Some of it is in structured content, some in a pile of PDFs, some on a public website, some in a support ticket database. A real single source of truth for agents has to unify those without turning back into a mess of copies, each drifting on its own.

Knowledge Bases are how Sanity Context folds those origins into the same retrieval path. Datasets, websites, PDFs, and support databases become agent-readable documents that share the Content Lake query interface, so a partner-facing agent asking about an integration and an internal agent asking about a refund policy resolve against the same governed corpus rather than against whatever each team scraped. The point is not merely ingestion; plenty of tools ingest. The point is that ingestion lands in the same store the rest of your content lives in, queried the same way, kept fresh the same way.

This is where the shared-foundation differentiator earns its keep. Legacy setups create silos: the docs team has its index, support has its bot, marketing has its widget, and reconciling them is a standing project nobody owns. When every source resolves through one path, adding a surface is a new consumer of existing truth, not a new copy of it. You are not scaling a team of people to keep four caches aligned; you are scaling output from one foundation, which is exactly the posture agents at web scale demand.

Govern what agents can say before they say it

A single source of truth is a governance problem as much as an architecture one. If any agent can read any content and act on it, then a draft that was never meant to ship, or an instruction someone changed on a whim, becomes production behavior instantly. Automating everything, the second pillar, only pays off when the automation is reviewable.

In Sanity Context, agent instructions and the content agents read are governed in Studio the same way editorial content is governed. Content Releases let a team stage a change to what agents can say, review it, and ship it as a unit, so updating an agent's behavior looks like publishing the website: staged, reviewed, and reversible, not a config edited live in production with fingers crossed. Roles and permissions decide who can change agent-visible content and instructions, and Audit logs record who changed what and when, which is the difference between an agent you can explain to a regulator and one you cannot.

The governance surface matters because agents remove the human pause. A person about to publish a wrong number often catches it; an agent reading that same number ships it to every channel at once. Putting the review loop where editors already work, rather than in a separate ops tool, means the people who own the truth also own what agents do with it. Compliance sits underneath all of it: SOC 2 Type II, GDPR, regional hosting for data residency, and a published sub-processor list, so a governed single source of truth is also a defensible one.

Expose the source to any agent through one endpoint

None of the architecture matters if wiring an agent to it is a bespoke integration each time. The final requirement for a single source of truth across the web is a single, standard way for agents to reach it, regardless of which framework or model a team happens to be using this quarter.

Production agents connect to Sanity Context through the Sanity Context MCP endpoint. Because the Model Context Protocol is a shared standard, the chatbot on your marketing site, an internal Slack assistant, and a partner's own agent all speak to the same endpoint and get the same governed, current answers, without each one carrying a private copy of your content or a hand-rolled retrieval client. Adding the third surface is configuration, not a new pipeline.

Where agents also need to write or transform content, Agent Actions provide schema-aware APIs for generate, transform, and translate operations, so an agent that drafts a localized answer does so against the same typed model the rest of the system trusts, and that draft flows back through the same Content Releases review before it reaches anyone. This is Sanity as the intelligent backend for companies building AI content operations at scale: model the truth once, govern it in one place, and expose it through one endpoint so every agent on every surface reads from the same page. The contradictions across channels stop not because you tuned three bots, but because there was only ever one source for them to read.

Single-source-of-truth retrieval: native path vs assembled stack

FeatureSanityPineconeContentfulpgvector / Neon
Where the truth livesContent and retrieval are one object in the Content Lake; agents query live documents, not exported copies.Vector store holds embeddings copied from a separate system of record; the source content lives elsewhere.Structured content lives in the CMS, but agent retrieval needs an external search or vector layer alongside it.Vectors sit in Postgres next to app data; source docs are still copied and chunked into it upstream.
Hybrid retrievalNative: text::semanticSimilarity() and match() blended with score() and boost() in one GROQ query.Semantic search is native; keyword and metadata filtering combine, but exact-term BM25 is assembled outside.No native vector search; hybrid retrieval is built by wiring an external engine via the App Framework.Vector similarity plus SQL full-text is possible, but blending and ranking is hand-written per query.
Keeping embeddings freshDataset embeddings are tied to content, so an edit propagates within minutes with no separate vector pipeline.You own the re-embedding job; edits drift until the pipeline reruns and re-upserts the changed vectors.External index must be re-synced on publish via webhooks and custom jobs the team maintains.Re-embedding on content change is application code you write, schedule, and monitor yourself.
Unifying PDFs, sites, and ticketsKnowledge Bases turn datasets, websites, PDFs, and support databases into documents on the same retrieval path.Ingests any vectors you produce, but parsing and chunking each source type is your pipeline to build.Handles structured entries well; external and unstructured sources need custom ingestion into a separate index.Stores whatever you insert; extracting and normalizing each source format is entirely application-side work.
Governing what agents can sayAgent instructions and content staged, reviewed, and shipped via Studio and Content Releases with Audit logs.No editorial governance layer; access is API keys and namespaces, review lives in whatever app you build.Strong editorial workflow for content; agent instructions and retrieval config are governed outside the CMS.Governance is database roles and your own app; no content-editor review path for agent-visible changes.
Connecting an agentAgents connect through the Sanity Context MCP endpoint; a new surface is configuration, not a new pipeline.Client SDKs per language; each agent framework integrates the vector store through your own glue code.Delivery APIs plus your search integration; each agent surface wires its own retrieval client.Standard Postgres drivers; every agent framework talks SQL through connection code you maintain.
Compliance postureSOC 2 Type II, GDPR, regional hosting for data residency, and a published sub-processor list.Enterprise compliance certifications available on paid tiers; verify current attestations for your region.Enterprise-grade compliance program; confirm the specific certifications your use case requires.Inherits Neon and your own cloud posture; compliance is largely what you configure and attest yourself.