Architecture pillar
Agent memory as data architecture
Memory is a data architecture with schemas, scope, provenance, correction, retention, and deletion.
Agent memory is often introduced as a retrieval feature: embed past interactions, rank them against a new query, and put the nearest results back into context. That can improve recall, but it does not answer the harder questions. What kind of record is this? Who may use it? When was it true? What superseded it? How is it corrected? When must every derived copy disappear?
Those are data-architecture questions. They have to be answered at admission and storage time, before retrieval quality becomes the optimization target. A vector index may accelerate one read path; it cannot serve as the system of record for provenance, scope, temporal correctness, or deletion.
Diagnose memory that cannot be trusted →
Separate session state from durable memory
Session state exists to recover a run exactly. It preserves the transcript, tool outcomes, checkpoints, and ordering needed to resume or replay work. Its correctness property is fidelity, and its lifecycle is usually bounded by the task.
Long-term memory exists to support selective reuse across runs. It is curated, typed, revisable, and intentionally lossy. Facts, preferences, episodes, and references have different write rules and retention periods. Combining this store with session state gives both the wrong schema: lossy summaries cannot recover a run, while raw transcripts make poor durable knowledge.
Session state and long-term memory are different schemas →
Govern admission before ranking retrieval
A memory write is a publication decision. Typed admission should establish what the record represents, who or what it is about, where it came from, which policy permits retention, and how its validity can later be challenged. Untrusted tool output should not become durable instruction merely because a model summarized it confidently.
Retrieval should then intersect relevance with authority, scope, freshness, and policy. Similarity only ranks candidates that are already eligible. This ordering prevents a highly similar but unauthorized, stale, or superseded record from winning the context window.
Agent memory needs governance before it needs embeddings →
Make change and forgetting cross-substrate operations
Durable memory changes over time. A correction should preserve what the system previously believed while making the current record unambiguous. That requires validity and system-time semantics, supersession rules, and provenance—not overwrite-in-place updates that erase the decision trail.
Deletion has the opposite requirement: it must propagate. Removing a source record while leaving its embedding, cache entry, summary, graph edge, or evaluation fixture behind is not forgetting. The architecture needs an inventory of derived substrates, tombstone and purge semantics, and evidence that deletion completed across them.
Scope retrieval to the actor and purpose
Memory scope is more than a namespace prefix. Organization, team, user, and task records have different writers, readers, retention rules, and conflict semantics. The schema should carry those boundaries so access control and retrieval use the same ownership model. A filter added after vector search is too late if the candidate set already crossed a tenant or purpose boundary.
Proof and limits
The companion reference build implements a narrower pattern with typed records, scoped access, bi-temporal reads, tombstone-then-purge forgetting, an audit trail, and a rebuildable semantic index over DuckDB and Delta Lake. It is inspectable implementation evidence—not deployment, compliance, benchmark, or client-outcome evidence, and it does not prove the full governance contract described here.
Inspect the memory reference build
See how the architectural boundary becomes a runnable local pattern: governed records remain the system of record, while embeddings stay a derived read accelerator.