Agent Memory vs Shared Knowledge Base: When to Use Each and How to Wire Both

Your support agent nailed the answer to a returns question this morning and gave a confidently wrong version of the same answer this afternoon, because the policy doc changed at noon and nobody re-embedded it. Meanwhile a second agent kept "remembering" a discount that expired last quarter, because someone treated its scratchpad notes as if they were the product catalog. Both failures come from the same root cause: treating agent memory and a shared knowledge base as one undifferentiated bucket of "context."

They are not one thing. Sanity Context, the product that gives agents structured, governed access to your content, starts from a sharper taxonomy: context is four types with different lifetimes, owners, and access patterns. Agent-authored notes are memory, private to the agent and written for its own future self. Retrieved content is the shared knowledge base, product catalogs and docs and policies pulled on demand. This article draws the line between the two, shows when each is the right tool, and shows how to wire both on one foundation. Sanity is the Content Operating System for the AI era, the intelligent backend where both context types can live under real governance instead of scattered across systems that never agree on the truth.

Four kinds of context, not one bucket

The move most engineering teams miss is that context is not one thing. It is four things, with different lifetimes, different owners, and different access patterns, and if you treat them as one bucket you will underbuild three of them. Static instructions are release-scoped and owned by product and brand. Per-turn runtime state lives for a single turn and belongs to your app. Retrieved content is stable and owned by the content team. Agent-authored notes cross sessions and are owned by the agent itself.

Two of those four are the subject of this guide. Retrieved content is the shared knowledge base: product catalogs, docs, knowledge bases, and policy documents, pulled on demand by the agent based on the question. This is what most teams assume "context" means. It is important, but it is one of four, not the whole game. Agent-authored notes are the memory type: summaries and distilled context the agent writes for its own future self. This barely existed a year ago. Anthropic recently introduced "dreaming," where an agent reflects on a session and writes a playbook for the next one, and that kind of context is in your engineering plan whether you have noticed or not.

The taxonomy matters because each kind has different governance. The team that authors brand voice is not the team that writes session-state injection. The compliance officer who signs off on what the agent can say is not the engineer tuning retrieval. If your stack collapses all four into one store, the wrong people end up making the wrong decisions about the wrong data. Drawing the memory versus knowledge-base line is the first architectural decision, not a detail you sort out later.

Shared knowledge base: stable, authored, pulled on demand

A shared knowledge base holds the facts the organization owns and everyone should agree on: the current price, the shipping policy, the API reference, the warranty terms. It is authored by humans (or by a governed pipeline), it changes on a publishing cadence, and the agent reads it but does not write to it. The failure mode when it goes wrong is stale or unstructured retrieval, and the fix is disciplined, fresh, hybrid search rather than "we have embeddings."

Here is where teams under-invest. Vector search alone answers on vibes; it retrieves things that are semantically nearby but ignores the constraints that have to hold, like in-stock, in-region, and under budget. Anthropic's contextual retrieval research measured this directly: contextual embeddings cut top-20 retrieval failures by 35 percent, adding contextual BM25 took that to 49 percent, and adding reranking brought it to 67 percent. None of the three layers alone was enough. The discipline is hybrid, and "RAG" is one ingredient, not the strategy.

In Sanity Context, the shared knowledge base lives in Content Lake and hybrid retrieval is native in a single GROQ query. A predicate does the filtering that has to hold, then a score pipeline blends a BM25 keyword match with semantic similarity: `*[_type == "product" && category == $category && price < $maxPrice && stockLocation == $warehouse] | score(boost([title] match text::query($queryText), 2), text::semanticSimilarity($queryText)) | order(_score desc)[0...10]`. The title match is weighted 2x because title hits matter more. The predicates guarantee the constraints; the score pipeline ranks the rest. Knowledge Bases turn datasets, support databases, websites, and PDFs into pristine documents with a clear table of contents, so messy sources become well-ordered before the agent ever queries them.

Agent memory: private, cross-session, agent-authored

Agent memory is a different animal. It is not the organization's facts; it is the agent's own distilled notes, written for its future self so it does not re-derive the same context every session. Think of a support agent that summarizes "this customer runs a fleet, prefers email, and has an open RMA" at the end of a conversation, or a coding agent that writes a playbook after a long debugging session. The lifetime is cross-session, the owner is the agent, and crucially the agent both reads and writes it.

Mechanically, this matters because in the agent loop the conversation `history` array is the model's only memory between calls. Every turn the model sees the same three things: the system prompt, the whole history so far, and the tool menu. The harness is the wrapper you build around the model, and it is where you add the programmatic logic that controls the context window: what goes in, and how much. Memory is the strategy for what survives when a session ends and the history array is thrown away. Without it, the agent starts every conversation amnesiac; with it wired badly, the agent carries forward notes that have quietly gone stale or that leak one customer's context into another's.

The honest framing today is memory-as-documents. There is no magic memory that governs itself. Agent-authored notes can be persisted as governed documents in the same content backend that holds the shared knowledge base, which means they inherit version history, permissions, and audit trails rather than living in an opaque side store. That distinction, that Sanity Context is not only an MCP endpoint but also has a knowledge base and an ingest path, is what lets both context types share one foundation instead of two systems that never reconcile.

When to use each: a decision framework

The decision is almost always answered by three questions about a piece of context. First: who owns the truth? If a human authors it and the organization must agree on it (price, policy, product spec), it belongs in the shared knowledge base. If the agent derives it for its own convenience (a customer summary, a solved-problem playbook), it is memory. Second: who writes it? If the agent writes it back, it is memory by definition; a knowledge base the agent can silently edit is a governance incident waiting to happen. Third: what is the blast radius if it is wrong? A stale knowledge-base fact gives every user the same wrong answer, so it needs freshness and review. A stale memory note usually harms one session, but a memory note that leaks across users is a privacy failure, so it needs isolation.

The most common mistake is putting agent-derived assumptions into the shared knowledge base, where they get treated as authoritative and served to everyone. The mirror-image mistake is stuffing authoritative facts into per-session memory, where they drift out of sync with the source of truth the moment the source changes. Keep the boundary crisp: knowledge base is read-mostly, human-authored, and singular; memory is read-write, agent-authored, and scoped.

Production data backs the priority order. When you look at how agents actually call the Context MCP endpoint, the heavy majority of calls are structured GROQ queries and schema lookups, with semantic search a small slice. Embeddings are opt-in and off by default, and most projects never turn them on, because agents fail on the structural side of the query first. The practical lesson: get the shared knowledge base's structured retrieval right before you invest in either embeddings or an elaborate memory layer. Most teams overspend on memory and underspend on getting the facts fresh and filterable.

Wiring both on one governed foundation

The architecture that avoids two-systems drift is to put both context types behind one backend and one query path. The shared knowledge base is retrieved content in Content Lake, queried with the hybrid GROQ pattern above, with dataset embeddings tied to the content so they stay fresh. This is the freshness point that separates native from assembled: Content Lake keeps the search index fresh automatically. Building freshness yourself, incremental indexing, re-embedding on change, deletion handling, and backfill, is a real project and a whole class of bug. When retrieval is wired into the content backend, freshness stops being something you maintain; with a separate vector DB plus glue code, it becomes a permanent line item on your roadmap.

Memory rides the same foundation as governed documents. Agent-authored notes persist as content, which means the ingest path, permissions, and history that protect the knowledge base also protect the notes. Both surfaces are reachable through the Sanity Context MCP endpoint, a hosted read-only surface any agent loop can connect to, so the agent has one door to structured retrieval instead of stitching a vector DB to a memory store to a CMS.

Static instructions get the same treatment, and this is where governance becomes concrete. The application system prompt should be authored in Studio and staged with Content Releases, not shipped as a string in the codebase. Splitting the prompt into fields is access control: brand owns voice, product owns how the agent uses user context, support owns escalation, and compliance owns the never-say list, and none of them files a pull request or waits for a deploy. Stage agent behavior with Content Releases the same way you stage your website, and preview before you ship. Author it like content; gate it like code.

Enterprise, cost, and lock-in considerations

Once both context types are in production, the governing questions become operational: who can see what, who can change what, and what happens when it breaks. A shared knowledge base is often the most regulated data in the stack, because it is what the agent is allowed to tell customers. Sanity's compliance posture covers SOC 2 Type II, GDPR, regional hosting and data residency, and a published sub-processor list, and because staged prompt changes flow through Content Releases you get drafts, scheduling, version history, permission gating, and audit trails on the exact text that shapes agent behavior. Two customer signals show why editorial governance of agent context is not a nicety: Vipps asked for the whole organization to contribute to prompt writing, and Nearform tuned an agent's voice with no code changes.

On cost, the expensive path is not the license; it is the glue. A vector-DB-plus-search-plus-memory-store topology means you pay in engineering time to keep three systems consistent, and you pay again every time a schema or a policy changes and the re-embedding pipeline has to catch up. Consolidating retrieval and memory onto one backend removes an entire category of synchronization work, and the production data (structured calls dominating, embeddings usually off) suggests many teams are paying for a vector layer they barely use.

Lock-in cuts the other way from the usual worry. Content in Content Lake is queryable with GROQ and reachable over an open MCP endpoint, so your agents are not welded to a proprietary retrieval SDK. The Content Operating System model, model your business, automate everything, and power anything, is explicitly about one governed foundation feeding many surfaces, which is the opposite of a memory store whose contents you can only reach through one framework's API.