What are conversation summaries as persistent context?

The previous two chapters looked at feedback and preference as the raw material of personalization. This chapter looks at a different, complementary kind of persistent memory, a running summary of an entire conversation, kept as a single, continuously updated record rather than as a scattered collection of individually extracted facts.

Why Would a System Need a Running Summary at All When It Could Simply Extract Individual Facts From Each Message as They Happen?

Individual fact extraction works well for discrete, standalone pieces of information, a preference, a stated goal, a specific correction, but a long, winding conversation often carries something extraction alone tends to lose, the overall thread and flow of what’s actually being discussed, how one part connects to another, and where the conversation currently stands as a whole. A running summary captures that broader continuity directly, giving a system a coherent sense of the entire conversation’s arc rather than only a disconnected pile of individually true but isolated facts pulled from different points along the way.

What Actually Makes a Conversation Summary Different From Simply Replaying the Full Conversation History on Every Turn?

Replaying full history keeps every message intact but grows without bound as a conversation lengthens, consuming more and more of a model’s limited context with every additional exchange, exactly the context-budget problem covered earlier in this knowledge base. A running summary solves this differently, condensing the conversation’s substance into a single, bounded piece of text that gets updated in place as new messages arrive, rather than accumulating indefinitely. The token cost of including a summary in a model’s context stays roughly constant no matter how long the underlying conversation actually runs, while a summary still preserves the model’s sense of the conversation’s overall shape.

Why Does a Conversation Summary Specifically Need to Behave as a Single, Continuously Updated Record Rather Than as Yet Another Growing Collection of Separate Memories?

A summary that accumulated as a new, separate memory every time it got updated would recreate exactly the problem it was meant to solve, a growing pile of overlapping, increasingly redundant summaries a future search would have to somehow sort through and reconcile. What a conversation genuinely needs is one canonical, current summary that gets rewritten in place as the conversation progresses, always reflecting the latest understanding of where things stand, rather than a trail of successive summary snapshots competing with each other for relevance.

How Does a System Actually Decide What Belongs in a Running Summary Versus What Should Be Extracted as Its Own Separate, Standalone Memory?

A running summary is well suited to capturing the conversation’s overall context and flow, what’s being discussed, what’s been resolved, what’s still open, while individually extracted facts remain better suited to durable, standalone pieces of information that genuinely deserve to exist independently of any one specific conversation, a stated preference, a confirmed fact about the user. These two mechanisms aren’t competing, they’re complementary, a summary gives a model conversational continuity within the current exchange, while individually scoped memories give it durable knowledge that persists and remains searchable well beyond the conversation that originally produced it.

Does a Running Conversation Summary Ever Need to Be Scoped More Narrowly Than an Ordinary User-Scoped Memory Would Be?

Yes, and this is exactly the kind of situation the property-scoped soft isolation covered earlier in this knowledge base was built for. A person who has many separate conversations over time needs each one’s own summary kept distinct from the others, a summary from last week’s conversation shouldn’t quietly blend into or overwrite a summary from an entirely different, unrelated conversation happening today. Scoping a conversation summary by both the user and a specific conversation identifier keeps each conversation’s own running context cleanly separated, while still letting a broader search sweep across all of a user’s conversations when that wider view is genuinely what’s needed.

How Does Weaviate Engram Let a System Maintain a Single, Continuously Updated Conversation Summary Rather Than an Accumulating Pile of Snapshots?

Weaviate Engram’s bounded topics, scoped by both user and conversation identifier, keep exactly one running summary per conversation, rewritten in place with every new exchange rather than accumulating as separate, competing entries. Consider a technical support chat tool helping a user troubleshoot a multi-step networking issue across a long back-and-forth conversation, where the assistant needs to keep track of what’s already been tried without replaying the entire exchange on every turn:

from engram import EngramClient
from engram import FetchRetrieval

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

client.memories.add(
    [
        {"role": "user", "content": "My router keeps dropping the connection every few minutes."},
        {"role": "assistant", "content": "Have you tried resetting the router to factory settings?"},
        {"role": "user", "content": "Yes, that didn't help. It's still dropping."},
    ],
    user_id="user-techsupport-6620",
    properties={"conversation_id": "session-networking-4471"},
)

current_summary = client.memories.search(
    query="conversation summary",
    user_id="user-techsupport-6620",
    properties={"conversation_id": "session-networking-4471"},
    topics=["ConversationSummary"],
    retrieval_config=FetchRetrieval(limit=1),
)

As this troubleshooting conversation continues across many more exchanges, the summary keeps updating in place, always reflecting the current state of the investigation, including that a factory reset was already tried and didn’t resolve the issue, so the assistant never wastes the user’s time suggesting a step they’ve already ruled out. This is exactly the value a single, continuously updated conversation summary delivers for a use case like technical support, where keeping track of what’s already been attempted matters as much as the individual facts about the problem itself.

Conversation summaries give a system a bounded, continuously updated sense of a specific exchange’s overall arc, complementing rather than replacing the individually extracted, durable facts covered in earlier chapters of this Part. Our next chapter, What is a user-knowledge layer?, takes up how these different kinds of memory come together into one coherent picture of who a specific user actually is.