What are bounded topics in memory?

This Part has spent its chapters so far on isolating memories from one another correctly, making sure the right boundaries separate the right data. This chapter looks at a related but distinct concern: making sure a specific kind of memory never accumulates duplicates within its own scope in the first place, staying as exactly one canonical version rather than growing into a scattered pile of overlapping entries.

Why Would a System Ever Need a Scope to Hold Only a Single Memory Rather Than Accumulating Many Over Time?

Some information is genuinely meant to represent a single, current state rather than a running history of separate, individually true facts. A user’s overall profile, a running summary of one specific conversation, these aren’t collections of many distinct observations, they’re one comprehensive, continuously updated picture that should always reflect the latest understanding rather than a stack of successive snapshots a caller would have to somehow reconcile on their own. Treating this kind of information the same way as an ordinary, ever-accumulating memory would leave a system with dozens of partial, potentially contradictory versions of what should have been a single, current source of truth.

What Actually Happens Without a Mechanism Enforcing This Single-Memory Constraint?

Every update to what should have been one profile or one summary instead creates a brand new, separate memory, leaving a search to somehow sort through an accumulating pile of overlapping, sometimes contradictory entries rather than simply retrieving the one current answer directly. A profile updated ten times over a relationship’s lifetime would leave ten separate memories behind, some of them capturing outdated information that’s since been superseded, with no structural signal indicating which one a caller should actually trust. This is exactly the kind of scattered, duplicated pile a well-maintained memory system exists to prevent.

How Does a Bounded Topic Actually Guarantee Only One Memory Exists for a Given Scope?

A bounded topic derives a memory’s identifier deterministically from the topic itself and the specific scope it belongs to, rather than generating a fresh, unique identifier for every new piece of content the way an ordinary topic would. Because the identifier is always the same for a given scope, a new update naturally overwrites the existing memory in place instead of creating a separate one alongside it, guaranteeing there’s never more than one memory to find for that scope no matter how many times it gets updated over time.

Why Does Deriving the Identifier Deterministically Actually Matter More Than Simply Checking for and Deleting Old Duplicates Before Every Write?

Checking for duplicates before every write would require first searching for whatever existing memory might already occupy that scope, comparing it against the new content, and then deciding how to reconcile the two, an entire extra step that has to happen correctly every single time a write occurs. Deriving the identifier deterministically sidesteps this problem structurally, since there’s simply no separate lookup-and-reconcile step required, writing to the same deterministic identifier is inherently an update rather than an insert, guaranteed by the identifier itself rather than by a fallible check a developer has to remember to run.

What Kind of Information Should a Team Actually Avoid Treating as a Bounded Topic, Even Though It Might Initially Seem Convenient?

Information that’s genuinely meant to accumulate as a history of individually true, standalone facts doesn’t belong in a bounded topic, since bounding it would mean each new fact overwrites and destroys the previous one rather than adding to a growing, retrievable record. A log of individual customer interactions, a list of separate purchases, a record of distinct support tickets, these all benefit from staying unbounded, each one a genuinely separate memory a future search might need to find on its own. Bounding this kind of information wouldn’t tidy it up, it would actively destroy the history a system might later need.

How Does Weaviate Engram Implement Bounded Topics to Guarantee a Single, Current Memory Per Scope?

Weaviate Engram lets a topic be marked as bounded, deriving each memory’s identifier from the topic and scope so that repeated updates rewrite the same memory in place rather than accumulating separate entries. Consider a personal fitness coaching app maintaining one continuously updated training profile per member, capturing their current fitness level, injury history, and goals, alongside a separate, unbounded log of each individual workout they’ve actually logged:

from engram import EngramClient
from engram import FetchRetrieval

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

client.memories.add(
    "Member is currently training for a half marathon, recovering from a mild hamstring strain, and prefers morning workouts.",
    user_id="member-fitnessapp-6612",
    topics=["TrainingProfile"],
)

current_profile = client.memories.search(
    query="training profile",
    user_id="member-fitnessapp-6612",
    topics=["TrainingProfile"],
    retrieval_config=FetchRetrieval(limit=1),
)

Every time this member’s circumstances change, a new injury, a new goal, a shift in scheduling preference, writing to the bounded `TrainingProfile` topic updates this same single memory in place rather than leaving behind an accumulating trail of increasingly outdated profile snapshots the coaching app would otherwise have to somehow reconcile. Meanwhile, the app’s separate log of individual completed workouts stays unbounded entirely on purpose, since each workout genuinely deserves its own permanent, retrievable record rather than being overwritten by whatever workout happens to come next. This is exactly the value bounded topics deliver for a use case like fitness coaching, where a member’s current training profile needs to stay a single, trustworthy source of truth, while their workout history needs to keep accumulating exactly the way a genuine history should.

Bounded topics guarantee a scope’s single source of truth stays genuinely singular, rewritten cleanly in place rather than scattered across an accumulating pile of outdated versions. This kind of deliberate, structural design becomes even more critical once a memory system has to satisfy not just good engineering practice but actual regulatory obligations. Our next chapter, How should you design memory systems for regulated industries?, takes up exactly that requirement.