How it works
Cross-session memory separates durable knowledge from the temporary context of one agent run. At the end of a run, the harness identifies information that may remain useful, converts it into a bounded memory record, and writes it to storage. A later run retrieves only records relevant to its current task and inserts them into the assembled context.
A controlled memory path usually has five steps:
- Capture: Select a candidate fact, preference, decision, or outcome from the run.
- Validate: Check that the candidate is supported, attributable, and safe to retain.
- Store: Write a structured record with scope, provenance, timestamps, and lifecycle metadata.
- Retrieve: Rank eligible records against the new task rather than loading the entire history.
- Revise or expire: Supersede stale records, resolve conflicts, and remove information that no longer belongs.
The memory store should not be treated as a transcript archive. A transcript records what happened. Memory supplies selected state to future reasoning. That distinction matters because every retrieved record can influence a later decision. The harness therefore needs a write policy as well as a retrieval policy. If the model can promote any statement into durable memory without validation, an incidental remark or injected instruction can silently become standing guidance.
Why it matters in an agent harness
Cross-session memory lets an agent continue work without reconstructing its operating state on every run. It can preserve a confirmed user preference, the reason behind an architectural decision, a previously failed approach, or the current status of a long-running task. This reduces repeated discovery and makes discontinuous work feel coherent.
Continuity is only the visible benefit. The deeper engineering value is that memory makes persistence explicit. Once durable knowledge has a schema, scope, and provenance, the harness can inspect it, evaluate it, and control its influence. Operators can ask which record affected a decision, where that record came from, and whether it was valid for the current task. Without those controls, persistence exists informally in copied prompts, hidden summaries, or accumulated files and is harder to govern.
Memory also expands the system's failure surface. A bad response in one session normally ends with that session. A bad memory can contaminate many later sessions. Stale instructions can override current intent. Records from one user, project, or environment can leak into another. A plausible but unsupported summary can gradually be treated as fact. Sensitive data can persist beyond its legitimate use.
For that reason, memory authority should be narrower than task authority. Permission to read a repository does not automatically imply permission to retain its contents indefinitely. Permission to propose a preference does not imply permission to establish it as durable policy. High-impact memories should require stronger evidence, narrower scope, or an approval checkpoint.
Reversibility matters as much as retention. An operator should be able to inspect, correct, invalidate, or delete a memory without editing an opaque model state. Records should be versioned or journaled when their downstream effects matter. Retrieval should expose record identifiers in traces so that failures can be reproduced with the same memory set and tested again after correction.
Evaluation must cover sequences of sessions, not just isolated answers. Useful tests include whether the system recalls a valid decision after interruption, ignores an expired preference, keeps projects isolated, and resists storing untrusted instructions. A memory system that improves immediate convenience but cannot pass those boundary tests is transferring work into future debugging.
Cross-Session Memory vs session context
Session context and cross-session memory both supply information to a model, but they carry different operational expectations.
| Dimension | Session context | Cross-session memory |
|---|---|---|
| Lifetime | One run or conversation | Multiple independent runs |
| Selection | Assembled for the current invocation | Captured earlier and retrieved later |
| Main risk | Context overload or immediate contamination | Persistent contamination, staleness, and scope leakage |
| Required controls | Context budgeting and source separation | Write policy, provenance, scope, expiry, and correction |
| Recovery | Start a clean session | Invalidate records and replay affected work |
This distinction changes architecture. Context assembly can be ephemeral, but durable memory needs lifecycle management. Saving every conversation and searching it later does not remove that requirement; it merely hides the write policy inside retention and retrieval behavior.
The Rifty take
We optimize for inspectable continuity, not maximum recall. A smaller set of scoped, attributable memories is more useful than a large store that quietly shapes behavior. We accept the cost of validation and expiry because durable influence should be earned, reversible, and visible in the execution trace.
Implementation checks
- Define which record types may persist and which must remain session-local.
- Attach provenance, owner, scope, creation time, and expiry or review conditions.
- Separate model-proposed memories from validated, active memories.
- Prevent retrieval across users, projects, or environments unless explicitly authorized.
- Make conflicts and superseded records visible instead of silently choosing one.
- Record the memory IDs supplied to each run for debugging and replay.
- Provide correction and deletion paths that also address derived summaries.
- Test stale, malicious, contradictory, and out-of-scope memories as negative controls.
- Bound retrieval volume so memory does not crowd out current instructions and evidence.
Frequently asked questions
What information should an agent store in cross-session memory?
Store information that is likely to matter later, can be stated precisely, and has a clear scope and source. Good candidates include confirmed preferences, durable decisions, task outcomes, and known constraints. Avoid retaining speculative conclusions, incidental conversation, secrets without a retention need, or instructions taken from untrusted content.
Why not store every transcript and retrieve relevant passages later?
A transcript archive preserves history but does not provide a safe memory policy. Retrieval can resurface stale, sensitive, or adversarial content without distinguishing observations from approved guidance. If transcripts are searchable, the harness still needs scope enforcement, provenance, retention rules, relevance thresholds, and a way to invalidate harmful records.
Who should be allowed to write durable agent memories?
The harness should mediate durable writes rather than granting the model unrestricted authority. Low-impact records may pass deterministic validation, while preferences, permissions, and operating rules may require explicit confirmation. The appropriate gate depends on the record's future influence, sensitivity, scope, and cost of being wrong.
How should cross-session memory be evaluated?
Evaluate it across linked runs with both positive and negative cases. Test correct recall, deliberate forgetting, expiry, conflict handling, project isolation, and resistance to injected memory candidates. Traces should show which records were retrieved so evaluators can separate a reasoning failure from a storage, ranking, or scoping failure.
How can a harness recover from an incorrect persistent memory?
Recovery requires identifying the record, invalidating or correcting it, and determining which later runs consumed it. Versioned records and retrieval traces make that investigation possible. For consequential actions, replay affected work from a clean checkpoint and verify any external side effects rather than assuming that deleting the memory repairs them.