Short answer: Share task and process knowledge project-wide; keep personal preferences and history user-scoped.
Defaulting everything shared risks privacy leaks. Defaulting everything private wastes lessons that should improve the product for everyone. A useful test: information about a person stays user-scoped; information about how to do a task can be shared. Engram lets teams set this choice deliberately per topic.
The previous chapter introduced project-wide and user-scoped memory as two of the scoping options available in a memory system. This chapter looks more closely at the actual decision behind choosing one over the other, since picking the wrong one in either direction carries real consequences, one erodes user trust and the other defeats the entire purpose of remembering anything at all.
What Kind of Information Genuinely Belongs at the Project Level Rather Than Locked to One User?
Project-wide memory fits information that describes how something works or should be done, independent of who happens to be involved in a given interaction. A lesson an agent learns about a recurring mistake, a best practice discovered through trial and error, a piece of institutional knowledge about how a specific process should actually be handled, none of these are genuinely about any one individual, they’re about the task itself, and locking them to whoever happened to be present when they were first learned would only prevent everyone else from benefiting.
What Kind of Information Genuinely Requires Strict User-Level Isolation Instead?
User-scoped memory fits information that’s actually about a specific individual, their stated preferences, their personal history, their private circumstances, information that would feel like a genuine violation if it surfaced for someone else entirely. A user’s stated communication style, a customer’s account details, a patient’s medical history, these all belong to that specific person and to no one else, and sharing them project-wide wouldn’t just be an odd design choice, it would be a direct breach of what that person reasonably expected when they shared it.
What Actually Goes Wrong When a System Defaults to Sharing Everything Project-Wide for the Sake of Simplicity?
Over-sharing is the easier mistake to make, since a single unscoped pool of memory is simpler to build and simpler to search than a carefully scoped one. But the cost shows up the first time a personal detail meant for one person surfaces in front of someone else, and once that kind of leak happens, the damage isn’t just the specific piece of information exposed, it’s the user’s confidence that anything else they’ve shared is actually safe. Trust, once broken this way, doesn’t rebuild itself just because the underlying bug gets fixed.
What Actually Goes Wrong When a System Defaults to Strict User Isolation Even for Information That Should Genuinely Be Shared?
Under-sharing is the quieter, less dramatic mistake, but it defeats the entire premise of a system meant to learn and improve over time. A lesson painstakingly learned from one user’s feedback, locked unnecessarily to that single user’s own isolated scope, never reaches anyone else the system serves, meaning the same mistake gets repeated for every other user who wasn’t the one to originally flag it. This isn’t a privacy failure, it’s a wasted opportunity, the system had a chance to genuinely improve for everyone and chose isolation instead, for no actual privacy reason.
How Should a Team Actually Decide Which Way to Scope a Given Piece of Information When It’s Genuinely Unclear?
A useful test is asking whether the information describes a person or describes a task. Information describing a person, their preferences, their history, their identity, generally belongs scoped to that person specifically. Information describing a task, how to do something correctly, what approach tends to work, what mistake tends to recur, generally belongs shared, since the whole point of learning it was to avoid repeating the same mistake for the next person too. When a single piece of information genuinely straddles both, describing a task in a way that’s also revealing about the specific person who reported it, that’s usually a signal to extract the general lesson separately from the specific personal detail, rather than forcing one scope to carry both.
How Does Weaviate Engram Let a Team Configure This Choice Deliberately Rather Than Accepting Whatever a Default Happens to Produce?
Weaviate Engram lets each topic declare its own scoping independently, so a single group serving one use case can hold both project-wide and user-scoped topics side by side, each configured deliberately for the kind of information it actually holds. Consider a corporate learning platform helping employees complete compliance training, where an employee’s own progress is obviously personal, but a pattern in which training modules employees commonly struggle with is genuinely useful to share across the whole organization:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"Employee completed the workplace safety module but scored low on the hazardous materials section and may benefit from a refresher.",
user_id="employee-corplearn-7734",
)
client.memories.add(
"Employees consistently struggle with the section on chemical storage labeling, suggesting the module's explanation needs clearer visual examples.",
)
The employee’s own individual progress stays locked to their own user identifier, never surfacing when the platform reviews a different employee’s training history, while the general observation about which section confuses learners is deliberately shared project-wide, letting the platform’s instructional designers see the pattern across the entire organization rather than rediscovering it employee by employee. This is exactly the value deliberately choosing between these two scopes delivers for a use case like corporate training, where an individual’s personal progress deserves privacy while a genuine, broadly useful lesson about the training material itself deserves to reach everyone who could benefit from it.
Choosing between project-wide and user-scoped memory comes down to whether a piece of information is genuinely about a person or genuinely about a task, and getting that choice right protects both privacy and the system’s ability to actually improve. Custom property scopes add a further layer of nuance to this same decision, offering isolation that’s more flexible than a strict, always-enforced boundary. Our next chapter, What is property-scoped memory and soft isolation?, takes up exactly that flexibility.