What is the difference between summary memory and atomic fact memory?

Preference memory dealt with content that’s inherently graded and nuanced. A different, more structural question applies once a scope has been active for a while and genuinely has a lot of accumulated memory attached to it: should that accumulated content be retrieved as a large set of small, individually addressable facts, or as a single, continuously updated summary standing in for all of it at once? Both patterns show up constantly in real systems, and they trade off against each other in ways worth understanding clearly rather than picking one by habit.

What’s the Actual Difference Between These Two Retrieval Shapes?

Atomic fact memory means each distinct piece of information exists as its own small, independently retrievable record. A search returns exactly the facts relevant to the current query, nothing more, and facts that aren’t relevant simply don’t get pulled in. Summary memory means a single, continuously maintained document stands in for a much larger body of underlying detail, and retrieving it means getting the whole summary at once rather than a filtered subset of individual pieces.

The tradeoff is precision against completeness. Atomic facts let a query surface exactly what’s relevant and nothing else, keeping the context small and focused. A summary sacrifices that precision, since it’s an all-or-nothing retrieval, but in exchange it preserves the connective tissue and overall shape of everything it summarizes, something atomic facts pulled independently can’t recreate no matter how many of them get retrieved together.

When Do Atomic Facts Clearly Serve a Task Better Than a Summary Would?

Atomic facts win whenever a query only needs a narrow slice of everything known about a scope, and pulling in unrelated detail would just waste context space without helping. If an agent needs to know a specific person’s dietary restriction, retrieving just that one fact is far more efficient than retrieving an entire summary of everything ever discussed with that person, most of which has nothing to do with the current question. This efficiency compounds as the volume of stored memory grows: atomic retrieval scales gracefully because the amount retrieved depends on relevance, not on how much total history exists.

Atomic facts also compose more naturally when different pieces of information were learned at very different times and don’t share an obvious narrative thread connecting them. A person’s job, their preferred communication style, and their timezone aren’t really parts of one continuous story, they’re independent facts that happen to belong to the same person, and treating them as one combined summary would force an artificial narrative onto content that doesn’t actually have one.

When Does a Summary Actually Serve the Task Better Than a Pile of Individual Facts?

A summary earns its place whenever the connective flow between pieces of information matters as much as the pieces themselves, which is exactly the situation already covered when discussing narrative memory earlier in this Part. A long, evolving planning process is the clearest case: knowing the current state of every individual decision made along the way is useful, but understanding how those decisions relate to and built on each other, why an earlier choice got revisited, what tradeoffs were already considered and rejected, is something a collection of independent atomic facts struggles to convey no matter how many of them get retrieved together.

A summary also has the advantage of constant, predictable size. No matter how long the underlying activity being summarized runs, the summary itself stays roughly the same length, since a bounded summary is continuously rewritten rather than growing without limit. Atomic facts, by contrast, grow in raw count as more gets learned, which is fine for the reasons already covered but doesn’t offer that same fixed-size guarantee if a use case genuinely needs one.

Can These Two Shapes Coexist for the Same Scope Rather Than Forcing a Single Choice?

They can, and combining them is often the strongest pattern rather than treating the choice as either-or. Atomic facts handle the isolated, independently useful details that benefit from precise, narrow retrieval, while a parallel running summary captures the overall shape and flow of a longer process that those isolated facts, retrieved individually, would never reconstruct on their own. Neither shape has to carry the whole burden by itself.

How Does Weaviate Engram Support Both Shapes Side by Side?

Weaviate Engram’s default behavior extracts atomic, unbounded facts per topic, while a separately configured bounded topic can maintain a continuously updated summary alongside them, fetched directly by scope rather than ranked by query relevance. Consider a wedding-planning coordinator assistant helping a couple track vendor decisions across a months-long planning process, where individual vendor facts and the overall arc of how the plan evolved both matter:

from engram import EngramClient

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

client.memories.add(
    "Booked the Riverside Pavilion as the reception venue, deposit paid, catering must be arranged separately since the venue doesn't provide it.",
    user_id="couple-4471",
)

This becomes an atomic fact, independently retrievable whenever a question is specifically about the venue. The overall planning narrative, including how the couple arrived at this venue after reconsidering two earlier options, is better captured as a running summary maintained alongside it:

results = client.memories.search(
    query="wedding planning summary",
    user_id="couple-4471",
    topics=["PlanningSummary"],
    retrieval_config=FetchRetrieval(limit=1),
)

vendor_facts = client.memories.search(
    query="What vendors have been booked so far?",
    user_id="couple-4471",
    topics=["VendorFacts"],
    retrieval_config=HybridRetrieval(limit=10),
)

Fetching the bounded planning summary returns the full arc, including the reconsidered venue options and why the final choice was made, context that would be lost entirely if the assistant only ever had access to isolated vendor facts pulled independently. The atomic vendor-facts search, meanwhile, returns exactly the specific bookings relevant to a narrower question without dragging the whole planning history along with it. Neither retrieval mode alone would serve this couple as well as the two working together, which is exactly the point: atomic facts and summaries aren’t competing solutions to the same problem, they’re complementary answers to two genuinely different questions a memory system needs to be able to answer.

Summary and atomic fact memory both describe content an agent might passively recall about a person or situation. A different, more active category concerns something an agent learns not about a person, but about itself, specifically, how to actually operate its own tools correctly, which turns out to need its own distinct treatment. Our next chapter, What is tool-use memory?, takes up exactly that question.