Short answer: Bounded memory allows at most one entry per scope. Unbounded memory can keep accumulating many entries over time.
A user profile often needs one canonical record. Event history needs many. Choosing the wrong cardinality creates duplicate summaries or blocks useful accumulation. Engram bounded topics encode the one-per-scope case directly.
Shared versus private answers who a memory belongs to. A separate, equally important question is how many of a given kind of memory are even allowed to exist for one scope at a time: capped at exactly one canonical entry, or free to accumulate as many separate entries as get written over time. This is the bounded-versus-unbounded distinction, and choosing the wrong one for a given kind of content produces two very different, very predictable failure modes.
What Does It Actually Mean for a Memory to Be Bounded?
A bounded memory is constrained to at most one entry per scope. Every new write to it doesn’t add a separate record alongside what’s already there, it replaces or updates the single existing entry in place, so no matter how many times something gets written, there’s only ever one current version sitting in storage. An unbounded memory has no such ceiling. Every new write can produce a fresh, additional entry, and the same scope can go on accumulating as many of them as ever get written, each one coexisting with all the others.
The difference isn’t about content quality or importance, it’s purely about cardinality: is this scope meant to hold exactly one thing, continuously kept current, or is it meant to hold a growing collection of distinct things that all deserve to coexist?
Which Kinds of Content Naturally Want to Be Bounded?
Anything meant to represent a single, current state rather than a history of individual occurrences wants to be bounded. A user profile is the clearest example: there should only ever be one, and it should always reflect the latest known state, not a growing pile of profile snapshots from every point in time it was ever updated. A running conversation summary works the same way, continuously rewritten as a conversation progresses rather than accumulating a new summary entry after every single message.
This connects directly to something already covered when discussing semantic memory: a semantic fact is supposed to consolidate down to one canonical statement, not sit as several competing near-duplicates. Bounding a topic is exactly this requirement enforced structurally, guaranteeing that consolidation actually happens by design, rather than depending entirely on a transform step correctly catching every duplicate after the fact.
Why Would Anything Want to Be Unbounded at All?
Episodic memory is the clearest case for the opposite shape. Every distinct occurrence genuinely deserves its own separate record, and collapsing them all down into a single, continuously overwritten entry would destroy exactly the information that made episodic memory valuable in the first place, the individual events and the sequence connecting them. Unbounded is the correct shape whenever more than one thing genuinely needs to coexist in storage, rather than the newest entry legitimately replacing everything that came before it.
What Actually Goes Wrong When the Wrong Shape Gets Chosen?
A fact-like memory left unbounded when it should have been bounded ends up accumulating near-duplicate restatements exactly the way already covered as a failure mode for semantic memory, forcing every retrieval to sort out which of several competing entries is actually the current one. Nothing about the content itself is wrong, the shape it’s stored in is simply mismatched to what it’s supposed to represent.
The opposite mistake is just as damaging in the other direction. An episodic-like memory forced into a bounded shape loses exactly the history it was supposed to preserve, since each new write silently overwrites the record of the last occurrence instead of adding to a growing sequence. The individual events disappear entirely, and the kind of multi-episode retrieval already covered, reconstructing a full arc from several related past events, becomes impossible, because there’s simply nothing left in storage to reconstruct it from.
How Does Weaviate Engram Guarantee This at the Structural Level?
Weaviate Engram makes this a structural configuration rather than a convention someone has to remember to follow. A bounded topic derives a deterministic identifier from the topic and the scope it belongs to, so a new write always lands on the exact same memory and updates it, rather than generating a fresh entry. An unbounded topic generates a new identifier for every write by default, letting the same scope accumulate as many memories as ever get added to it.
Consider a home-security monitoring assistant tracking a household’s system. The current arm-or-disarm status is exactly the kind of thing that should exist as a single, always-current entry:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
status = client.memories.search(
query="current arm status",
user_id="household-4471",
retrieval_config=FetchRetrieval(limit=1),
)
Fetching this bounded topic always returns exactly one current answer, no matter how many times the system has been armed and disarmed since it was first set up, because every update rewrote the same entry rather than adding to a growing pile of past statuses. Individual motion-detection events, by contrast, genuinely need to coexist as their own separate records, since each one is a distinct occurrence worth keeping on its own:
events = client.memories.search(
query="motion detected in the last 24 hours",
user_id="household-4471",
retrieval_config=HybridRetrieval(limit=20),
)
This search can legitimately return many separate entries, one per distinct detection event, because that topic was never meant to collapse down to a single answer the way the arm status was. Both patterns live in the same memory system, configured deliberately for what each one is actually supposed to represent, rather than one shape being forced to serve both purposes badly.
Bounded and unbounded describes how many entries a scope is allowed to hold. A related but different question is how those entries are actually shaped once they exist, as clean, structured pieces of data with defined fields, or as flowing, unstructured narrative text. Our next chapter, What is the difference between structured facts and narrative memory?, turns to exactly that question.