Short answer: A raw log solves storage cost briefly, then becomes noisy, hard to search, and full of contradictions as conversations grow.
Embedding every message looks like an obvious fix after transcript resend gets expensive. Over weeks it piles up chit-chat, duplicates, and stale claims. Real memory needs extraction, consolidation, and cleanup, not an ever-growing chat dump.
Once it’s clear that resending a full conversation on every call is unsustainable, a natural next idea is to log every message somewhere durable, embed it, and search over that log later instead of resending it in full. This looks like a reasonable, even obvious fix, and it does solve the immediate cost problem. Used for real, over real conversations that accumulate over weeks and months, it runs into specific, predictable failures that have nothing to do with how good the search over that log happens to be. The problem isn’t retrieval quality. It’s that raw logged messages were never the right thing to be searching over in the first place.
Why Does Logging Every Message Look Like a Reasonable Memory Strategy?
The appeal is straightforward. Instead of stuffing the entire conversation history into every request, each message gets stored externally as it happens, and a search step pulls back only whatever seems relevant to the current question. This directly addresses the cost and latency problem from resending everything, and it feels like the natural next step once it’s already accepted that memory shouldn’t live inside the context window at all.
It’s also simple to build. There’s no need to decide what’s worth extracting or how to phrase it; every message just gets saved exactly as it was said, and the search step does the work of finding whichever ones seem closest to the current query. On paper, this looks like a complete solution: memory lives externally, retrieval keeps context size manageable, and nothing gets thrown away.
Why Do Retrieved Raw Messages Often Fail to Be Useful on Their Own?
The trouble shows up the moment a single logged message gets pulled out of its original conversation and handed to the model in isolation. Real conversation is full of messages that only make sense with everything around them still attached: “yes, let’s do that,” “sounds good, go with the second one,” “actually, that works better.” A message like this can score as highly similar to a search query and still be completely useless once separated from whatever it was originally responding to, because the actual content, the “that” or “the second one” it refers to, lived in a different message entirely.
This is exactly the failure that extracting a self-contained fact avoids. Turning a conversation into something like “the user prefers dark mode” produces a statement that means the same thing whether or not anything else from that conversation comes along with it. A raw logged sentence carries no such guarantee. It might be perfectly clear in its original context and completely opaque the moment it’s retrieved on its own, and a memory system built on raw logs has no way to know in advance which of these two situations it’s going to hit.
What Happens to a Raw Log When the Same Fact Gets Repeated or Contradicted Over Time?
A raw transcript has no built-in way to recognize that five different phrasings across five separate conversations are all describing the same underlying preference, or that a later statement has quietly replaced an earlier one. A search over raw messages just returns whichever ones score highest against the current query, with nothing telling it that one of them is current and the other is months out of date. Two directly contradictory messages, one saying a preference and a later one reversing it, can both come back side by side with identical apparent validity, because nothing about storing them as raw text ever resolved which one should actually win.
This is precisely the trust problem already covered: recall that surfaces stale or contradictory information with full confidence is worse than recall that simply admits it doesn’t know. A raw log doesn’t just risk this failure occasionally, it has no mechanism at all for avoiding it, since resolving contradictions was never part of what “save every message” was designed to do.
Can Better Retrieval Alone Fix What’s Wrong With Storing Raw Messages?
It’s tempting to assume a smarter ranking step, better filtering, or a more sophisticated similarity search could patch over these problems without needing to change what actually gets stored. Retrieval improvements can help surface more relevant messages, but they can’t manufacture context that was never captured to begin with, and they have no principled way to decide which of two equally real, equally logged, directly contradictory messages should be treated as current. Both messages genuinely happened. Nothing about ranking them differently changes that fact, or tells the system which one reality has since moved past.
The actual problem sits one level below retrieval: the unit being stored and searched over is wrong. A raw message is a record of something that was said, not a self-contained statement of something that’s true. No amount of retrieval sophistication turns the first kind of thing into the second. That transformation has to happen before storage, not after.
How Does Weaviate Engram Avoid the Naive-Logging Trap?
Weaviate Engram’s extraction step exists specifically to make this transformation before anything gets committed to storage. Rather than saving a conversation’s sentences as they were spoken, the pipeline pulls out the atomic, self-contained facts those sentences actually convey, so what ends up stored means the same thing whether or not the surrounding conversation comes with it.
Picture a car dealership’s sales follow-up assistant, tracking leads across several separate calls as they consider a purchase. A raw call log would be full of exactly the kind of context-dependent fragments that don’t survive being pulled out on their own:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
[
{"role": "user", "content": "I'm looking at somewhere between 25 and 30 for the new one."},
{"role": "assistant", "content": "Got it — and are you planning to trade in your current vehicle?"},
{"role": "user", "content": "Yeah, a 2019 sedan, and I'd rather finance than lease this time."},
],
user_id="lead-58213",
)
Stored as raw sentences, “somewhere between 25 and 30” and “yeah, a 2019 sedan” mean nothing without the exact questions that preceded them. Extracted properly, they become self-contained and searchable regardless of which call they came from:
results = client.memories.search(
query="What is this lead's budget, trade-in, and financing preference?",
user_id="lead-58213",
)
What comes back is something like “budget range $25,000–$30,000,” “trading in a 2019 sedan,” and “prefers financing over leasing,” each one meaningful entirely on its own, regardless of which call it originally came from or what was said immediately before it. That’s the actual fix for naive conversation logging: not a better way to search a pile of raw sentences, but converting those sentences into facts that don’t depend on their original surroundings to mean anything at all.
Getting extraction right still leaves an important question unanswered: for any given piece of information, how does a system actually decide whether it’s worth extracting into memory at all, when it should be captured, and by what mechanism it gets written and later retrieved? Our next chapter, What three questions must every memory architecture answer?, lays out exactly that framework.