Memory and context do different jobs.

Context is what the model receives for a task. Memory is what a system carries forward—and must choose whether to put back into context.

Context is a working input.

A model invocation receives instructions, messages, tool results, and other selected material within its context. That input is the model’s immediate working material.

An agent framework may persist conversation state or checkpoints and restore them later. This makes a session resumable, but does not automatically give every retained statement the authority of a reviewed instruction.

Longer context can reduce the need to discard working material. It still requires decisions about what is current, permitted, and worth including. Token availability is only one constraint.

Memory is continuity across work.

Persistent memory retains information across tasks or sessions. A project decision, a time-bounded fact, a user preference, and a reusable procedure all have different lifecycles even when each can be represented as text.

A single vector representation does not erase those differences. A preference may require consent and revision. A historical fact may need both valid and recorded time. A lesson may require independent review before activation.

Choose a representation and policy around the kind of continuity required. In UniMem, lessons, atomic facts, conversations, and core-memory blocks are distinct product concepts rather than one undifferentiated list of embeddings.

UniMem memory model

Retrieval is a bridge, not the entire lifecycle.

Retrieval selects candidate material for the present task. Lexical, semantic, graph, and reranking techniques can improve that selection. Admission checks must then enforce scope, time, and authority.

After delivery, a different question becomes possible: did the selected memory help? Retrieval quality and downstream task success can be measured separately, because an agent can find the right passage and still use it incorrectly.

Keep this separation visible in instrumentation. Record candidate selection, delivered memory identities, and outcomes without assuming one is a substitute for the others.

Design the boundary deliberately.

A useful architecture can preserve canonical records, maintain rebuildable indexes, admit only visible and current information, deliver a bounded context, and connect that delivery to later outcomes.

UniMem can start as a local store or wrap an existing retrieval callable through its Python measurement interface. This offers a way to evaluate guidance without requiring an immediate replacement of every storage component.

The first practical question is what crosses the boundary into the agent’s working context. The second is how you will learn whether that inclusion was useful. Both deserve an explicit contract.

CausalMemory interface

Put experience to work.

Try the local loop, or bring one workflow to a pilot conversation.

Technical details link to the inspected source. Check deployment requirements before enabling optional features.