How to Add Knowledge Bases to an Existing Production Agent

Your agent has been live for months. It answers customer questions, drafts support replies, and pulls from a retrieval setup someone wired together a year ago. Then product ships a new release, the docs change, and the agent keeps confidently citing the old behavior. The retrieval index lags reality by days, the embeddings live in a separate pipeline nobody owns, and every content update means a re-index job that may or may not have run. The failure is not that the agent is dumb; it is that the knowledge feeding it went stale and no one noticed until a customer did.

Sanity Context (previously Agent Context) is built for exactly this moment. Sanity Context is the AI Content Operating System for grounding agents, an intelligent backend that keeps the content your agent retrieves governed, fresh, and reviewable inside the editorial loop rather than scattered across a brittle vector pipeline.

This guide treats the problem as an integration question, not a rebuild. You already have a production agent. The goal is to add Knowledge Bases as an authoritative source without ripping out what works, without a parallel embeddings job to babysit, and without losing the governance you need when an agent speaks on your behalf.

Why bolt-on retrieval drifts out of sync with your content

The most common production pattern is a content store on one side, a vector database on the other, and an ETL job in the middle that chunks, embeds, and upserts. It works on day one. It degrades quietly from day two. The degradation is structural: the moment your embeddings live in a different system than your content, you own a synchronization problem forever. Someone edits a help article, the source updates, and the vector index keeps serving the previous version until the next batch run. If that run fails silently, the gap widens.

This is the difference between a system that stops at publishing and one that operates content end to end. A legacy CMS hands off a document and considers the job done; what happens to that document inside your agent's retrieval path is somebody else's pipeline. The result is silos: the editorial team governs the website, a platform team governs the index, and the two diverge precisely when accuracy matters most, during a launch or an incident.

Reframing the problem helps. The question is not "which vector database should I add" but "how do I make retrieval a property of my content rather than a copy of it." When embeddings are tied to the content itself, an edit propagates to what the agent retrieves within minutes, with no separate job to schedule, monitor, or reconcile. That is the model Knowledge Bases assume, and it is why adding one to an existing agent removes a maintenance burden instead of adding another moving part. This section maps to the Automate everything pillar: the sync work disappears because it was never supposed to be work.

Inventory what your agent already retrieves before you add a source

Before connecting anything new, audit the agent you have. Production agents accumulate retrieval surfaces the way codebases accumulate dependencies: a docs index here, a hardcoded FAQ there, a scraped support archive that no one remembers configuring. Write down every source the agent currently queries, how fresh each one is, and who is accountable for it. You will almost always find at least one source that is stale, duplicated, or contradicting another.

The inventory matters because adding a Knowledge Base is not just plugging in more data; it is deciding which existing source it replaces or supersedes. If your agent currently scrapes a public docs site nightly and you add the same docs as a governed Knowledge Base, you want to retire the scraper, not run both and let the agent average two versions of the truth. Conflicting sources are worse than missing ones, because the agent cannot tell you which it trusted.

Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents that share the Sanity Context retrieval path. That last clause is the point: rather than maintaining a distinct retrieval mechanism per source type, you consolidate them onto one path that your agent already knows how to query. Map each item from your inventory to a Knowledge Base entry, mark the ones that become canonical, and flag the ones you will decommission once the new source is verified. The migration is additive first, subtractive second, so the agent never goes dark on a topic mid-cutover.

Connect the Knowledge Base through the MCP endpoint your agent already speaks

The integration surface is the Sanity Context MCP endpoint. Production agents that support the Model Context Protocol connect to it the same way they connect to any other tool: you register the endpoint, the agent gains the ability to query your content, and you have changed nothing about the agent's core orchestration. There is no new SDK to embed deep in your request loop and no bespoke retrieval client to maintain alongside your existing ones.

This is deliberately incremental. You can add the Sanity Context MCP endpoint as one retrieval tool among several the agent can call, run it in parallel with your current source during a verification window, and compare the answers it grounds against the answers your existing pipeline produced. Because the endpoint is shaped to the product rather than to a generic vector API, the queries it answers are content-aware: the agent retrieves structured documents, not anonymous chunks stripped of their relationships.

For teams whose agents are not MCP-native, the same retrieval path is reachable through the App SDK and standard query interfaces, so the connection model does not force a particular agent framework. The principle holds either way: the agent keeps its identity, its prompts, and its tools, and gains one governed source it can trust. Adding knowledge should feel like adding a capability, not commissioning a second system. When the new source proves out against the audit you did in the previous step, you cut over and retire the brittle path you were carrying.

Make retrieval hybrid, because keyword-only and vector-only both fail in production

Once the source is connected, retrieval quality decides whether the agent improves or just gets a new way to be wrong. Pure vector search misses exact matches: a customer asks about error code E-4021 and semantic similarity returns three articles about error handling in general, none of which mention E-4021. Pure keyword search misses paraphrase: the customer describes the symptom in their own words and the index, keyed on the official term, returns nothing. Production support content needs both at once.

Inside the Content Lake, hybrid retrieval is native rather than assembled from two systems. A single GROQ query blends semantic and lexical signals: text::semanticSimilarity() captures meaning, a BM25 match() captures the exact token, and you combine them with score() and boost() to weight the result list the way your domain demands. There is no separate reranking service to stand up and no second datastore to keep consistent with the first. The exact-match path and the semantic path read the same content.

That the embeddings are dataset embeddings, tied to the content and refreshed within minutes of an edit, is what keeps this honest over time. The hybrid query is only as good as the freshness of what it searches; a clever blend over a stale index still returns yesterday's answer. By coupling retrieval logic and content freshness in one place, you remove the most common cause of confident-but-wrong agent responses, which is a retrieval layer faithfully serving content that the source already corrected.

Govern what the agent knows the same way you govern the website

Adding knowledge to a production agent is a governance event, not just a data event. The instant your agent can speak from a new source, you have expanded what it can say on your company's behalf. Most teams discover this the hard way when an agent surfaces an internal draft, an unpublished pricing experiment, or a deprecated policy that was technically still in the index. The fix is not a content firewall bolted on after the fact; it is treating agent knowledge as published content with the same review gates as everything else.

In the Studio, editors govern agent instructions and the content the agent retrieves through the same workflows they already use for the site. Content Releases let you stage a change to what the agent knows, preview the agent's behavior against the staged state, and ship it as an atomic release rather than a silent index mutation. If a launch needs the agent to start answering questions about a new product at a precise moment, you stage the Knowledge Base updates in a release and publish them on the same schedule as the website. The agent and the site change together, by design.

This is where Sanity Context separates from tools that bolt AI onto a publishing system: roles and permissions, audit logs, and a reviewable history apply to the agent's knowledge, not just to web pages. On the compliance side, the platform carries SOC 2 Type II, GDPR alignment, regional hosting for data residency, and a published sub-processor list, so the governance you assert to your security reviewers extends to what your agent retrieves. Knowledge becomes something you release, review, and roll back, never something that drifts.

Verify, cut over, and keep the agent honest after launch

Integration is not finished when the connection works; it is finished when you can prove the agent got better. Build a small evaluation set from real questions your agent has fumbled, the ones tied to stale or missing knowledge, and run them against both the old retrieval path and the new Knowledge Base before you cut over. You are looking for two things: that the new source answers the questions the old one missed, and that it does not regress on questions the old one handled. Keep the comparison until the new path clearly wins, then retire the source you flagged in your inventory.

After cutover, the maintenance story is the payoff. Because dataset embeddings stay tied to content, the team that owns the help articles owns what the agent says about them, with no re-index job standing between an edit and the agent's behavior. Content Source Maps and the audit trail in the Studio let you trace any answer back to the exact document and revision that grounded it, which turns an agent incident from a guessing game into a lookup. When a customer reports a wrong answer, you find the source, fix the content, and the correction propagates within minutes.

The broader reframe is that grounding an agent is an ongoing editorial discipline, not a one-time wiring task. Sanity Context, the intelligent backend for companies building AI content operations at scale, exists to keep that discipline cheap: model your business once, automate the retrieval path so freshness is free, and power any agent that needs to speak from the truth. You scale output, not the headcount babysitting a pipeline.