Short answer: Shared memory is visible across users or agents. Private memory belongs to one user or one agent alone.
Who can read and write a memory is as important as what it says. Preferences are usually private. Team playbooks are often shared. Getting this wrong causes privacy leaks or forces every agent to rediscover the same lessons.
Whether a memory belongs to everyone using an agent or to exactly one person has come up already, mostly in passing, when procedural memory turned out to usually make more sense shared across a whole project rather than scoped to an individual. It deserves its own direct treatment, because this shared-versus-private question cuts across every content category already covered, not just procedural memory, and getting the answer wrong in either direction has real, predictable consequences rather than being a minor configuration detail.
What Actually Makes a Memory Shared Rather Than Private?
Shared memory is visible to, and shaped by, everyone using a given agent within a project. Private memory belongs to exactly one individual and stays invisible to everyone else, including other people using the identical agent for the identical kind of task. This distinction is orthogonal to content type: an episodic memory can be shared, like a team’s collective record of past incidents, or private, like one person’s individual history with a support agent. The same is true of semantic and procedural memory. Content type describes what kind of information something is; shared versus private describes who it belongs to.
How Does a System Decide Whether Something Should Be Shared or Private?
The deciding test is straightforward to state, even if applying it takes real judgment: would this information genuinely help, or genuinely belong to, everyone using the agent, or is it specific to one individual’s own relationship with it? A diagnostic technique learned from troubleshooting one bug report usually helps every future user hitting a similar issue, which points toward shared. A person’s own stated preference for how they like explanations phrased belongs to them specifically, and has no obvious reason to shape how a completely different person gets treated, which points toward private.
This decision has to be made deliberately, category by category, rather than defaulted to one answer for an entire system. Treating everything as shared by default, or everything as private by default, both fail in predictable, opposite ways.
What Actually Goes Wrong When This Decision Gets Made Incorrectly in Either Direction?
Getting it wrong toward over-sharing means a personal detail meant for one person surfaces for someone else entirely, which erodes trust immediately and can violate a reasonable expectation of privacy the moment it happens, even once. Getting it wrong toward under-sharing has a quieter but still real cost: a lesson that genuinely should have benefited everyone stays locked to whichever single person or session happened to produce it, so other users of the exact same agent go on repeating a mistake that’s already been solved once, simply because the fix never had a path to reach them.
Neither of these is a hypothetical edge case. Both are the direct, predictable outcome of not making the shared-versus-private decision on purpose, for the specific kind of information involved, rather than treating one default as automatically safe for everything.
Does This Distinction Need to Be Technically Enforced, or Is Careful Intention Enough?
Careful intention alone isn’t sufficient, for the same reason careful intention alone was never enough for memory isolation in general. If keeping private memory private depends on application code consistently remembering to check the right condition every single time, it will eventually be missed, not because anyone was careless on purpose, but because manually-enforced rules degrade under enough repetition and enough different code paths touching the same data.
Genuinely private memory needs hard isolation enforced at the storage layer itself, so a leak between people is structurally impossible rather than merely unlikely given diligent code. Shared memory doesn’t need that same hard boundary, since being visible to everyone is the entire point, but it still benefits from being an explicit, deliberate configuration choice rather than something that happens to be true by accident because nobody set up isolation for it.
How Does Weaviate Engram Enforce This Distinction at the Storage Layer?
Weaviate Engram makes this an explicit, per-category configuration rather than an assumption baked into application code, and enforces the private side of it using Weaviate’s own multi-tenancy, meaning isolation holds structurally rather than depending on every query remembering to filter correctly. Consider a corporate mentorship-matching assistant, where a mentor’s general coaching techniques should benefit every mentee the assistant ever helps match, while a specific mentee’s private career goals should never surface for anyone else:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"When matching a mentee who's uncertain about direction, ask about energizing moments from their recent work before asking about long-term goals directly.",
group="mentorship-technique",
)
No `user_id` is attached here, deliberately, because this coaching approach should be available to every future mentorship match the assistant helps arrange, not locked to whichever conversation first produced it. A specific mentee’s own private goals, by contrast, get stored with strict isolation from every other mentee:
client.memories.add(
"This mentee is specifically interested in transitioning into a technical leadership role within eighteen months.",
user_id="mentee-5502",
)
Searching for the second mentee’s goals as any other user, even another mentee going through the exact same matching process, returns nothing, because that isolation is enforced by the storage layer itself rather than by application code that has to remember to filter correctly every time. The shared coaching technique, meanwhile, is available to every future matching conversation without needing to be re-taught. That’s the practical difference deliberate, enforced scoping makes: genuine privacy that holds even when application code has a bug, and genuine sharing that reaches everyone it should, rather than staying accidentally trapped wherever it happened to be learned first.
Shared versus private describes who a memory belongs to. A related but separate question is how much of it can exist at all for a given scope, whether it’s allowed to grow without limit or deliberately kept to a single, current entry. Our next chapter, What is the difference between bounded and unbounded memory?, takes up exactly that question.