What three questions must every memory architecture answer?

Everything covered so far about memory, why it’s needed, how it gets reconciled, why raw logging fails, why trust depends on consistency, keeps circling back to the same three underlying decisions, even when they aren’t named explicitly. Any real memory architecture has to answer what actually deserves to be remembered, when the writing and recalling of that information should actually happen, and how it gets found and delivered once it’s needed. These are genuinely separate questions, easy to blur together, and getting any one of them wrong undermines a system even if the other two are handled perfectly.

What Actually Deserves to Become a Memory?

Not everything said in a conversation is worth keeping. A passing comment, a speculative guess, or something said half-jokingly shouldn’t get treated with the same weight as a confirmed preference or a durable decision someone clearly meant to stick. Deciding what crosses that line is its own design question, separate entirely from when it gets captured or how it later gets found.

Getting this wrong in one direction floods memory with noise: uncertain, low-confidence, or purely transient details competing for attention alongside things that genuinely matter, making every later retrieval less reliable. Getting it wrong in the other direction means real, useful information never gets captured at all, because the bar for “worth remembering” was set so high that ordinary, valuable facts never clear it. Answering “what” well means being deliberate about both ends of that spectrum, not just avoiding the more obvious failure of forgetting things.

When Should Writing and Recalling Actually Happen?

Even once it’s clear what’s worth keeping, timing is a separate decision with its own failure modes on both the writing side and the recalling side. On the writing side, capturing something the instant it’s said isn’t always right, since some information only becomes clearly worth keeping once a decision is actually finalized, or once a task reaches a natural checkpoint rather than mid-sentence. Waiting too long risks losing something if a session ends abruptly before it gets captured; capturing too eagerly risks storing half-formed, premature versions of a fact that later changes.

On the recalling side, memory can be pulled in at the very start of a session to prime context before the first question even arrives, checked before every single turn, or triggered only on specific signals like a resumed task or a clear cross-reference to earlier work. Recalling too often adds latency and cost to every single interaction, even ones that don’t need it. Recalling too rarely means the exact moment memory would have mattered most is precisely the moment it doesn’t get checked. Neither of these timing decisions is about what gets remembered; both are entirely about when the system actually acts on it.

How Should Retrieval Actually Find and Deliver the Right Memory?

Once something is captured at the right moment, a separate mechanical question remains: how does it actually get found again later? Memory can be pulled in automatically, using whatever the current message is about as an implicit search, so relevant context shows up without anyone deciding to look for it. It can instead be exposed as a tool an agent chooses to call on its own, searching as often or as rarely as it decides a given step actually needs. Or, for something that’s supposed to have exactly one current answer, like a standing profile of stable facts, it can be fetched directly by name rather than searched for at all.

Each of these mechanisms trades off differently. Automatic injection is convenient but can’t distinguish a step that genuinely needs memory from one that doesn’t. Giving an agent a search tool hands over control, but only helps if the agent actually reaches for it when it should, which isn’t guaranteed. A direct fetch is fast and predictable, but only works for the narrow case where a single, bounded answer is genuinely what’s needed. Picking the wrong mechanism for a given kind of memory can undermine everything upstream, even when the content and timing decisions were both handled correctly.

Why Do All Three Questions Have to Be Answered Together, Not in Isolation?

A wrong answer to any one of these three questions quietly breaks the other two, even when they were each handled well on their own. Capturing exactly the right facts but only recalling them sporadically still produces an agent that looks forgetful in precisely the moments that matter most. Getting the timing right on both ends but being too permissive about what counts as worth remembering leaves genuinely useful facts buried under noise that never should have been kept in the first place. And correctly identifying what to remember and when to act on it, but choosing a retrieval mechanism that doesn’t fit how that memory actually needs to be used, still leaves the system feeling unreliable end to end, even though two out of three decisions were made correctly.

This is why these three questions are worth treating as genuinely separate design decisions rather than one vague notion of “does the agent have memory.” Each one can be reasoned about, tested, and adjusted independently, but the architecture as a whole only holds together when all three get deliberate, matching answers rather than one getting worked out carefully while the other two are left to default behavior.

How Does Weaviate Engram Let You Answer These Three Questions Explicitly?

Weaviate Engram maps onto these three questions directly rather than treating memory as one undifferentiated setting. What gets remembered is controlled by the topics configured for a project, natural-language descriptions of the kinds of information worth extracting, so speculative chatter and confirmed facts don’t get treated identically by default. When capture and recall happen is controlled by when an application calls into Engram and which retrieval trigger it uses, whether that’s on every message, at specific checkpoints, or at session start to prime context before anything else happens. How retrieval actually finds and returns something is a separate, explicit choice at query time.

Picture a volunteer-coordination assistant for a nonprofit, matching volunteers to opportunities based on their skills and availability. Some information, like a volunteer’s confirmed availability, deserves exactly one current answer rather than a ranked list of possibilities:

from engram import EngramClient

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

availability = client.memories.search(
    query="availability",
    user_id="volunteer-2905",
    retrieval_config=FetchRetrieval(limit=1),
)

Matching that same volunteer to a brand-new kind of opportunity, on the other hand, benefits from a broader, ranked search over everything relevant to their background, not a single fixed answer:

matches = client.memories.search(
    query="What skills and past volunteer experience does this person have relevant to event logistics?",
    user_id="volunteer-2905",
    retrieval_config=HybridRetrieval(limit=5),
)

The difference between these two calls isn’t about what was captured or when, both draw from memory built the same way. It’s purely a “how” decision, made deliberately for the shape of question being asked. That’s what it looks like to treat what, when, and how as three genuinely separate, intentional choices rather than a single, vague setting labeled “memory,” and getting each one right independently is what makes the other two actually pay off.

Answering these three questions well is what makes memory work reliably at the level of a single agent and a single user. It’s also, increasingly, what separates agentic products that feel disposable from ones people keep coming back to, which raises a broader question worth addressing directly. Our next chapter, How is memory a competitive advantage for agent products?, looks at exactly that.