Short answer: An atomic fact is one discrete, stand-alone piece of information, not a bundle of unrelated ideas.
Bundling several facts into one memory dilutes search matches and complicates updates when only one detail changes. Splitting too hard can strip needed context. A practical test: if two details might update independently, store them separately. Getting size right keeps retrieval precise and later reconciliation clean. Engram’s extraction aims for that atomic granularity in practice.
The previous chapter described extraction as the process of pulling durable facts out of raw conversation. It left one important question mostly unanswered: exactly how big should each extracted fact actually be? Bundle too much into one memory and it loses precision. Split too aggressively and it loses the context that made it meaningful in the first place. This chapter looks at atomic facts, the practice of finding the right size for a single unit of memory.
What Does It Actually Mean for a Fact to Be Atomic?
An atomic fact captures exactly one discrete piece of information, complete enough to stand on its own without needing a surrounding paragraph to make sense of it, but not so broad that it bundles several unrelated ideas together into a single entry. A memory stating that a user prefers dark mode is atomic. A memory stating that a user prefers dark mode, works primarily in Python, and is building a specific kind of application bundles three genuinely separate facts into one, and that bundling has real consequences for how well that memory actually serves later search and later updates.
Why Does Bundling Several Facts Into One Memory Actually Hurt Search Quality?
A bundled memory produces a single vector embedding that has to represent every idea packed inside it at once, and that embedding ends up as a kind of blurred average across all of them rather than a sharp representation of any single one. A later query about just one of those bundled ideas, dark mode preference specifically, competes against the diluting influence of everything else crammed into that same embedding, making the match weaker than it would have been if that preference had its own clean, focused memory. Smaller, single-idea memories produce sharper embeddings precisely because they have only one thing to represent, and a sharper embedding is what actually makes a targeted search reliable.
Does Splitting Facts Too Aggressively Create Its Own Set of Problems?
It does. A fact split down to a fragment too small to make sense on its own, a phrase lifted out of context with no indication of what it’s actually about, fails a very simple test: if a fact doesn’t make sense to a person reading it in isolation, it won’t make sense to a search system either. Splitting also has a practical cost beyond comprehension, since every additional memory means additional storage and additional vectors to maintain, and splitting far past the point where any real distinction still exists between the resulting pieces adds overhead without adding any real benefit to search quality.
How Should a Team Actually Decide Where the Right Boundary Between Facts Sits?
The right boundary sits at the edge of a genuinely distinct idea, everything relevant to expressing that one idea belongs together, and anything belonging to a separate idea belongs in its own memory instead. A useful practical test asks whether two pieces of information would ever need to be updated independently of each other, since if one might change while the other stays exactly the same, bundling them together means an update to one risks disturbing or duplicating the other unnecessarily. Facts that will always change together, and that only make sense read together, are the exception where keeping them combined actually makes more sense than splitting them apart.
Why Does Getting Granularity Right Matter Specifically for How Memories Get Updated Later?
A bundled memory containing several facts becomes considerably harder to update cleanly the moment just one of those facts changes, since a system now has to decide whether to rewrite the entire bundled memory, accepting the risk of losing nuance in the untouched parts, or leave the bundle stale on the outdated portion while the rest remains accurate. An atomic memory sidesteps this problem entirely: when a single, well-scoped fact changes, exactly one memory needs updating, cleanly and completely, with no risk of accidentally disturbing unrelated information that happened to be sharing the same entry.
How Does Weaviate Engram’s Extraction Process Apply This Atomic Granularity in Practice?
Weaviate Engram’s extraction step is designed to produce atomic, information-dense memories, splitting distinct ideas into their own separate entries even when they originally appeared together in the same raw conversation. Consider an independent film production company’s contract and rights-tracking assistant, helping a production coordinator keep track of licensing terms across many different vendors and collaborators:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
[
{"role": "user", "content": "The composer's contract grants us worldwide sync licensing rights through 2030, and separately, the sound editor's agreement caps overtime hours at fifteen per week without prior written approval."},
],
properties={"production_id": "production-lowland-fields"},
)
Engram’s extraction step recognizes these as two entirely unrelated facts about two different vendors, splitting them into separate memories rather than storing one bundled entry that would blur both together into a single, less precise embedding:
sync_rights = client.memories.search(
query="What are our sync licensing rights and how long do they last?",
properties={"production_id": "production-lowland-fields"},
)
overtime_terms = client.memories.search(
query="What's the overtime cap in the sound editor's agreement?",
properties={"production_id": "production-lowland-fields"},
)
A coordinator checking on sync licensing rights months later gets a precise, unblurred match because that fact was stored as its own atomic memory, not diluted by an unrelated overtime clause that happened to be mentioned in the same original sentence. This is exactly the value atomic granularity delivers in practice: each fact stays cleanly independent, easy to update in isolation should either vendor’s terms ever change, and easy to retrieve precisely without unrelated details muddying the match.
Atomic facts give memory the right shape for precise search and clean updates. But splitting facts this finely raises a related risk, the same underlying idea getting captured more than once as similar conversations happen again over time. Our next chapter, What is deduplication at the representation level?, takes up exactly that risk.