Agent Memory vs a Shared Knowledge Base: Best Practices

Your support agent answers a returns question perfectly at 9 a.m. By noon the policy has changed, and the agent is still quoting the old window because it "remembered" the answer from an earlier session. This is the failure mode that turns agent memory from a feature into a liability: memory captures what an agent learned in a moment, and moments go stale. When the source of truth moves, per-session memory does not move with it, and the agent confidently contradicts the very content your editors just published.

Sanity Context (previously Agent Context) is the AI Content Operating System, an intelligent backend that keeps agent answers grounded in current, governed content rather than in whatever a conversation happened to cache. That distinction is the whole argument of this guide. Agent memory and a shared knowledge base are not competitors; they solve different problems, and treating one as a substitute for the other is where production agents drift.

This article reframes the debate. We separate short-lived conversational memory from the durable, queryable knowledge base every agent should read from, then walk through the best practices for wiring the two together so that memory personalizes without ever becoming your system of record.

Two different jobs: session memory versus a shared knowledge base

The first mistake teams make is asking one mechanism to do two jobs. Agent memory is the scratchpad of a conversation. It holds what the user just said, the tool outputs from three turns ago, and the running summary that keeps a long thread coherent. It is fast, local, and disposable by design. A shared knowledge base is the opposite: durable, versioned, and read by every agent, every session, every user. It is the answer to "what is true right now," not "what did we say a minute ago."

Collapsing these two produces the stale-policy bug in the introduction. If the returns window lives in memory, it is only as fresh as the session that cached it. If it lives in a shared knowledge base and the agent retrieves it per turn, an editor changing the policy changes every answer at once. Memory should personalize and maintain continuity; the knowledge base should ground facts.

This maps cleanly onto Sanity's model your business pillar. In Sanity Context, the durable layer is the Content Lake, Sanity's queryable content store and the backbone of the retrieval path. Product facts, support policies, and documentation are modeled as structured documents there, not smeared into conversation state. Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents that share the same retrieval path, so the shared layer is one governed store rather than a pile of vector snapshots. Memory can still remember that this user prefers metric units or already verified their account; it just never gets to decide what your return policy is. The division of labor is the design: memory for the user, knowledge base for the truth.

Freshness: why cached memory drifts and grounded retrieval does not

The property that separates a good architecture from a fragile one is freshness. A fact stored in memory is a photograph; a fact retrieved from a shared knowledge base is a live feed. The moment your business changes a price, a policy, or a spec, every answer that reads from memory is now potentially wrong, and nothing in the memory layer knows it. You end up building cache-invalidation logic, which is famously one of the hardest problems in computing, on top of a probabilistic agent.

Many stacks make this worse by bolting a separate vector pipeline onto their content. Content lives in one system, embeddings live in another, and a nightly or on-demand job tries to keep them in sync. Every gap in that sync is a window where the agent retrieves an embedding of content that no longer exists. This is the "we'll re-index later" tax, and it is invisible until an agent quotes a deleted paragraph to a customer.

Sanity Context closes that gap because dataset embeddings are tied to the content itself. When a document changes, its embedding updates within minutes, and there is no separate vector store to reconcile. Editors working in Studio can stage a change through Content Releases, review it, and publish, and the retrieval path reflects the new state. This is the automate everything pillar in practice: freshness is a property of the system, not a cron job you maintain. The best practice that follows is blunt. Keep durable facts out of memory entirely. Let memory hold only what is genuinely per-session, and let every factual claim resolve through a fresh retrieval against the shared knowledge base.

Retrieval quality: exact match, semantic recall, and blending both

Even a perfectly fresh knowledge base is useless if the agent cannot find the right passage. This is where the shared-knowledge-base approach earns its keep, and where retrieval quality becomes an engineering decision rather than an afterthought. Two failure modes dominate. Pure keyword search misses the user who asks about "sending an item back" when your policy says "returns." Pure semantic search misses the user who types an exact SKU or error code and needs a precise hit, not a vibe-similar neighbor.

Production retrieval needs both, blended and scored together, not run as two disconnected queries whose results you awkwardly staple. Most vector-database stacks give you semantic similarity and leave the keyword side, the fusion, and the ranking as your problem to assemble. That assembly is where teams spend weeks and still ship inconsistent relevance.

In Sanity Context this is native inside the Content Lake, not assembled around it. A single GROQ query can combine `text::semanticSimilarity()` for semantic recall with a BM25-style `match()` for exact terms, then blend the two using `score()` and `boost()` to control which signal wins for a given query shape. Because it is one query against one store, the ranking is deterministic and inspectable: you can see why a passage ranked where it did, and tune it, rather than treating relevance as a black box across two systems. The best practice is to route every factual question through hybrid retrieval and reserve memory for continuity, so the agent's recall of facts is always a query result you can reproduce, not a remembered impression you cannot.

Governance: memory you cannot review versus instructions you can stage

Ask a hard question about most agent-memory systems: who reviews what the agent decided to remember? Usually no one. Memory accumulates silently, and when an agent starts giving a subtly wrong answer, tracing it back to a poisoned memory entry is archaeology. For a consumer toy that is a shrug. For an agent quoting compliance rules, pricing, or medical or financial guidance, unreviewable state is a governance failure waiting for an audit.

A shared knowledge base flips this. The content the agent grounds on is the same content your editors already govern: reviewed, versioned, and attributable. Changes go through an editorial workflow before they reach production, which means the agent's factual behavior is auditable by construction rather than reconstructed after an incident.

Sanity Context puts that governance where editors already work. Agent instructions and the knowledge documents behind them live in Studio, and teams stage agent behavior through Content Releases the same way they stage the website. You can preview how an instruction change lands, review it, and roll it forward or back, so agent behavior is a reviewable artifact, not an emergent property of accumulated memory. On the enterprise side, Sanity supports SOC 2 Type II, GDPR, regional hosting and data residency, and a published sub-processor list, which matters when the knowledge base holds regulated content. Roles and Permissions and Audit logs mean you can answer "who changed what the agent knows, and when," a question a pile of session memory simply cannot answer. This is the shared foundation argument: one governed store, many agents, one review process, instead of per-agent memory silos nobody can inspect.

Operations and cost: two pipelines to babysit versus one governed store

The operational bill for the DIY path is easy to underestimate. Choosing agent memory plus a separate vector database plus a content backend means you now run three systems that must agree with each other. You maintain an embedding pipeline, an invalidation strategy, a sync job between your content store and your vector store, and monitoring for all of the seams between them. Each seam is a place where content and its embedding diverge, and each divergence is a potential wrong answer in front of a customer.

There is a lock-in dimension too. When your embeddings, your retrieval logic, and your memory schema all live in bespoke glue code, moving off any one component means rewriting the glue. The cost is not just the vector database bill; it is the standing engineering time to keep the parts synchronized and the switching cost baked into custom infrastructure.

Sanity Context consolidates this. Because embeddings are tied to content in the Content Lake and hybrid retrieval runs in GROQ against that same store, there is no second pipeline to babysit and no reconciliation job to monitor. Production agents connect through the Sanity Context MCP endpoint, and Agent Actions provide schema-aware APIs for LLM-driven workflows like generate, transform, and translate, so content operations and retrieval share one foundation. This is the pillar of scaling output instead of scaling headcount: legacy stacks force you to add people to keep pipelines in sync, while a single governed store lets a small team run more agents against more content. The best practice for ops teams is to minimize the number of systems that must agree, because every system you remove is a class of drift you no longer have to monitor.

A decision framework: when to use memory, when to use the shared base

Reduce the choice to a single test: is this fact allowed to be wrong for the length of a session? If yes, it can live in memory. The user's stated preference for dark mode, the fact that they already authenticated this session, the running summary of a long thread. None of these are your system of record, and if they lapse, the worst case is a re-ask. Put them in agent memory, keep them scoped to the session, and let them expire.

If the fact must be correct every single time it is quoted, it belongs in the shared knowledge base, retrieved fresh per turn. Prices, policies, product specs, compliance language, documentation. Anything an editor might change and expect to see reflected instantly. The rule of thumb: memory personalizes, the knowledge base grounds. When in doubt, ground it, because the cost of a stale fact in front of a customer dwarfs the cost of one extra retrieval.

The practical wiring in Sanity Context follows that split. Session memory stays in your agent framework, short-lived and disposable. Durable knowledge lives in the Content Lake and surfaces through Knowledge Bases, which turn datasets, websites, PDFs, and support databases into agent-readable documents on the shared retrieval path. Agents reach it through the Sanity Context MCP endpoint, resolve facts with hybrid GROQ retrieval, and editors govern the whole thing in Studio with Content Releases. Sanity Context is the AI Content Operating System, the intelligent backend that owns the durable layer so your memory layer can stay small, honest, and disposable. Get the boundary right and the stale-policy bug at the top of this guide simply stops happening: the policy changes once, and every agent, in every session, is current the next time it answers.