One Source, Two Audiences: Serving a Public Knowledge Base and an Internal Wiki

A support engineer publishes a fix in the internal wiki, marks it "do not share, mentions the customer by name," and three weeks later a public support agent surfaces that exact paragraph to a stranger. Nobody meant to leak it. The content simply lived in a store that had no idea one audience was allowed to see it and the other was not. That is the recurring failure of running a public knowledge base and an internal wiki as two separate content silos, or worse, one shared pile with access rules bolted on after the fact.

The stakes are real: leaked internal notes, stale public docs that contradict the private source, and agents that hallucinate because the "single source of truth" was actually two out-of-sync copies. This article reframes the problem. You do not need two content systems, and you do not need to duplicate content to keep audiences apart. You need one modeled source where audience is a property of the content itself, and where retrieval, not copy-paste, decides who sees what. That is where Sanity Context (previously Agent Context) changes the shape of the problem.

Why do public and internal knowledge bases drift out of sync?

Public and internal knowledge bases drift out of sync because most teams maintain them as two physically separate stores, and separate stores demand a human to keep them aligned. The internal wiki gets the real fix first, often as a quick note in a support thread or an engineering runbook. The public article gets written days later by a different person, phrased differently, missing the caveat that only the internal note captured. From that moment the two versions disagree, and every subsequent edit widens the gap.

The agent era makes drift expensive rather than merely annoying. When a public support agent and an internal copilot retrieve from different indexes, they give different answers to the same question. A customer is told a feature is unsupported while an internal agent tells the account team it shipped last sprint. Neither agent is wrong about its own source; the sources are wrong about each other. This is the structural cost of duplication: every copy is a new place for the truth to rot.

The fix is not better synchronization tooling to reconcile two stores. It is refusing to have two stores. Model the knowledge once, tag each piece with the audiences allowed to see it, and let retrieval filter at query time. In Sanity's Content Lake, a single document can carry an audience field, an internal-only rich-text block, and a public summary side by side, so the public and internal views are projections of one source rather than two drifting copies. Update the fix once and both audiences reflect it, because there was only ever one thing to update. Drift stops being a process problem and becomes a modeling decision you made once.

How do you model one document that serves two audiences?

You model one document for two audiences by making audience a field on the content, not a folder the content lives in. A single knowledge document holds a public body, an internal-only body, a visibility field (for example public, internal, or restricted), and metadata like owning team and last-verified date. The public knowledge base reads a projection that returns only public-visible documents and only their public fields. The internal wiki reads a projection that returns everything the viewer is cleared for. Same document, two shapes.

This is exactly the kind of problem structured content modeling exists to solve, and it is the first pillar of the Content Operating System: model your business. Legacy wikis force your knowledge into their fixed page-and-folder shape, so the only way to separate audiences is to separate files. When the model adapts to you instead, audience, sensitivity, and freshness become queryable properties. A GROQ query can return `*[_type == "article" && visibility == "public" && defined(publicBody)]`, and the same content set can be filtered to `visibility in ["internal", "restricted"]` for the wiki, with no second copy anywhere.

The payoff compounds with structure. Because the internal note and public summary are fields on one document, an editor updating the fix sees both in the same editing surface and keeps them consistent by construction. Roles & Permissions in the Studio govern who can even read the internal field, so a contractor editing public docs never sees the restricted block. You are not managing two knowledge bases that happen to overlap. You are managing one knowledge graph that answers to two questions: what can this audience see, and is it current.

How does retrieval keep the internal answer from leaking into public agents?

Retrieval keeps internal answers out of public agents by filtering on audience before the content ever reaches the model, not by trusting the model to keep a secret. This is the critical shift for agent-grounded knowledge bases: an LLM given a passage will use it. If your retrieval step hands a public-facing agent an internal-only paragraph, no amount of system-prompt caution reliably stops it from surfacing. The guardrail has to live in the query, upstream of the model.

Inside the Content Lake, that guardrail is a filter in the same GROQ query that does the search. Hybrid retrieval blends `text::semanticSimilarity()` for meaning with a BM25 `match()` for exact terms, combined through `score()` and `boost()`, and the audience predicate sits right beside them: the public agent's query is scoped to `visibility == "public"` before similarity is ever computed. An internal-only document is not ranked lower for public queries; it is not a candidate at all. Because dataset embeddings are tied to the content, a document that flips from internal to public updates its embedding within minutes, so the moment something is cleared for release it becomes retrievable, and the moment it is pulled it stops.

This is where a native retrieval path beats a bolt-on vector database. When embeddings live in a separate store from the content and permissions, audience filtering becomes a second system you have to keep in lockstep with the first, and the leak lives in the seam between them. With Sanity Context, production agents connect through the Sanity Context MCP endpoint and query one store where content, embeddings, and audience rules are the same object. The public agent and the internal agent run the same retrieval path with a different filter, so there is no seam for a secret to fall through.

What is the intelligent backend for a dual-audience knowledge base?

The intelligent backend for a dual-audience knowledge base is the layer that stores the knowledge once, understands who each audience is, and serves both agents and human readers from the same governed source. Sanity Context is that backend: the Content Operating System for the AI era, an intelligent backend for companies building AI content operations at scale. Rather than a wiki that publishes pages and a vector database that indexes them separately, it operates the content end to end, from the editor's draft through embedding, retrieval, and the agent's answer.

Concretely, that means several capabilities work as one system. Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents that share the retrieval path, so a legacy internal wiki exported as PDFs and a structured public help center both become queryable through the same interface. Agent Actions provide schema-aware APIs to generate, transform, and translate content, so a verified internal fix can be transformed into a public-safe summary without a human retyping it and dropping the caveat. The public version is derived from the internal source, which is why they cannot silently disagree.

Governance is not an afterthought bolted onto this. Editors stage agent behavior in Studio Workspaces and Content Releases the same way they stage a website launch, so a batch of newly public articles goes live to the public agent atomically instead of trickling out inconsistently. Audit logs record who changed a visibility flag and when. Compliance rests on SOC 2 Type II, GDPR, regional data residency, and a published sub-processor list, which matters when the internal side of your knowledge base contains customer data that must never cross into the public projection.

How do you keep the public projection current when the internal source changes?

You keep the public projection current by deriving it from the internal source rather than authoring it independently, so an update to the source is the update to both views. The failure mode to avoid is the one every duplicated system has: someone edits the internal runbook, forgets the public article exists, and the public knowledge base now describes a workaround that no longer applies. If the public version is a projection of the same document, there is nothing separate to forget.

The mechanism is event-driven, not batch. When an editor publishes a change in the Studio, a document webhook fires, which gives you a change event to act on within seconds rather than waiting for a nightly reconciliation job. Because dataset embeddings are tied to the content, the retrieval index re-embeds the changed passage automatically, so both the public and internal agents start answering from the new text almost immediately. There is no separate ingestion pipeline to babysit and no window where the wiki is right and the public base is a day behind.

Content Releases add the control layer on top of that immediacy. Not every internal update should reach the public the instant it is saved; a fix may need legal review or a coordinated announcement. A release lets editors stage the public projection of several changes and publish them together at a chosen moment, then roll back as a unit if something is wrong. Content Source Maps and Visual Editing let a reviewer click a rendered public article and jump straight to the field driving it, so verifying that the public summary matches the cleared internal fix is a click, not a search. Currency stops depending on human diligence and starts depending on the model you already built.