Short answer: Structured facts are short, self-contained claims. Narrative memory preserves longer passages and conversational flow.
Facts are easy to filter, update, and contradict cleanly. Narratives keep nuance and context that atomic facts drop. Real systems usually need both shapes, with different write and retrieval rules for each.
Beyond how many entries a scope holds and who they belong to, there’s a further question about the actual shape of what gets stored: a short, self-contained fact, or a longer passage that preserves the flow and nuance of an entire exchange. Structured facts and unstructured narrative memory aren’t competing approaches to the same problem, they’re two genuinely different shapes suited to two genuinely different retrieval needs, and a memory system that only offers one of them is quietly leaving something valuable on the table.
What Actually Distinguishes a Structured Fact From an Unstructured Narrative?
A structured, atomic fact is a short statement distilled down to one clear idea: “prefers dark mode,” “works primarily in Python,” “budget tops out around four hundred thousand dollars.” Nothing about it depends on the surrounding conversation to make sense, and nothing about it tries to capture more than the one specific thing it’s stating. An unstructured narrative memory is a longer passage that preserves the flow of an actual exchange, the connective detail, the tone, and the sequence of how something unfolded, rather than distilling it down into a handful of isolated statements.
The difference is between a fact and a story about how that fact, and several others, came to be true, in a form that still reads coherently as one continuous account rather than a list of discrete claims.
Why Are Atomic Facts Usually the Default Choice?
Atomic facts are easy to reconcile against each other, exactly the consolidation requirement already covered for semantic memory: one clean statement is simple to check against another clean statement and update in place when something changes. They’re also cheap and precise to retrieve individually, since a search can pull back exactly the handful of facts relevant to a specific question without dragging along everything else that happens to be loosely related. This is why the default extraction behavior in a well-built memory pipeline distills raw conversation down into individual atomic facts rather than storing the full transcript: “lives in Berlin” and “prefers specialty coffee” are each independently useful, independently retrievable, and independently easy to keep current.
What Gets Lost When Everything Gets Reduced to Atomic Facts?
Reducing everything to atomic facts throws away nuance, tone, and the connective tissue that actually held an exchange together. A list of facts pulled from a conversation, “mentioned a trip to Lisbon,” “wants a historic neighborhood,” reads nothing like the conversation that actually produced them, and it loses whatever emotional context, hesitation, or reasoning surrounded those facts in the moment they were said. For plenty of purposes this doesn’t matter at all. For others, it matters quite a lot, particularly whenever an agent genuinely needs to pick up the full thread of what happened rather than work from a distilled list of bullet points standing in for it.
When Does Preserving Full Narrative Actually Matter Enough to Justify It?
Full narrative earns its cost in situations where the flow of an entire exchange carries real information that a list of atomic facts would flatten away: a customer complaint with real emotional weight behind it, a complex negotiation that unfolded across several back-and-forth turns, or any case where picking the conversation back up requires understanding how it got somewhere, not just where it ended up. In these situations, a single well-maintained narrative summary genuinely serves the task better than a pile of disconnected facts ever could.
This is exactly why narrative memory tends to work best as a dedicated, continuously updated summary sitting alongside atomic facts rather than replacing them. The two shapes aren’t in competition. Atomic facts remain the efficient, composable default for everything that’s genuinely just a fact, while a narrative summary handles the specific cases where the whole flow of an exchange is itself the thing worth remembering.
How Does Weaviate Engram Support Both Shapes at Once?
Weaviate Engram’s default extraction behavior produces atomic facts per topic, exactly the composable, easily reconciled shape most memory should take. Alongside that, a bounded conversation-summary topic can maintain a single, continuously rewritten narrative that preserves the full flow of a specific exchange, updated in place as the conversation continues rather than fragmented into isolated statements. Consider a real-estate buyer’s-agent assistant, where stable preferences and one especially nuanced, difficult negotiation both need to be remembered, but in very different shapes:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"Budget tops out around $400,000. Needs at least three bedrooms. Prefers walkable neighborhoods over larger lots.",
user_id="buyer-2290",
)
These preferences work well as atomic facts, each independently useful whenever a new listing needs to be evaluated against them. A specific, emotionally complicated negotiation on one particular property, by contrast, is better served by preserving the actual flow of how it unfolded:
results = client.memories.search(
query="conversation summary",
user_id="buyer-2290",
properties={"conversation_id": "listing-8842-negotiation"},
retrieval_config=FetchRetrieval(limit=1),
)
Fetching this bounded narrative summary returns the actual story of how the negotiation developed, the buyer’s hesitation, the seller’s counteroffers, and why a particular compromise was eventually reached, none of which would survive being flattened into a handful of disconnected facts like “offer was rejected once” or “final price was lower than asking.” Meanwhile, the atomic budget and bedroom-count facts stay exactly as clean and independently retrievable as they need to be for evaluating every other listing that comes up. Both shapes are doing real work here, and neither one could substitute for the other without losing something the task genuinely needed.
Every category and dimension covered in this Part so far has assumed a memory belongs to some identifiable scope, a user, a project, a conversation, without looking closely at what that scoping actually means in practice or how deliberately it needs to be chosen. Our next chapter, What is scoped memory?, takes up exactly that question directly.