12. Context, Summaries, and Long-Term Memory Are Different

Context is directly visible to the current model call. A summary is new content produced by compressing history. Long-term memory lives outside model calls and becomes visible only after retrieval.

Memory needs provenance

“The project uses Zola” becomes useful later only with source, time, and scope.

User preferences, project facts, incident conclusions, and tool instructions have different authority and update frequency and should not share one undifferentiated store.

A summary is a lossy transformation

A lossy transformation cannot reconstruct the complete input. A fluent summary can remove a prohibition, failed retry, or incomplete step.

Every summary therefore references the event range from which it was produced. A conflict can be investigated from the original trace instead of summarized again.

A stale-memory experiment

Store “the project uses Python 3.11,” change the project to Python 3.13, and start a new session. Observe whether retrieval returns the old record, the runtime checks current configuration, the conflict updates memory, and the old record remains in change history.

Using the old value directly is a failure of invalidation policy, not a shortage of model memory.

Injection can persist through memory

If a page contains operational instructions and a summarizer stores them as a preference, the injection survives across sessions. Memory writes require source-trust and persistence checks. Retrieved memory remains data and is re-evaluated under current permissions.

Retention extends lifetime; it does not increase authority.

Retrieval uses ranking and a budget

Memory does not enter context automatically. Retrieval first filters by project, principal, and type, then ranks by relevance, freshness, and confidence. A fixed Token budget limits selected records.

Semantic similarity alone can rank an outdated but closely worded memory ahead of current configuration. Retrieval events record candidate count, exclusion reasons, selected records, and Tokens. A missing fact can then be attributed to absent storage, failed retrieval, or model use.

Updates preserve history

When new evidence conflicts with old memory, create a replacement relation rather than silently overwriting. Explicit user updates can replace preferences. Current configuration validates project facts. Model inference cannot automatically replace direct evidence.

Deletion distinguishes withdrawal, expiration, and end of scope. These reasons determine audit behavior and whether a record may be regenerated.

Boundary of the packet capture

The original test isolated some skills and extensions. It supports analysis of core prompts and tool loops, not a comparison of product memory quality. The design here is a runtime experiment rather than an unobserved product claim.

Every memory fact should answer: where did it come from, where does it apply, and when does it stop applying?

Three stores have different responsibilities

A session summary compacts a trajectory, working memory holds current-task state, and long-term memory carries stable facts across tasks. Combining them in one vector store lets stale intermediate conclusions compete with durable preferences.

Each fact records subject, assertion, source, scope, validity interval, and confidence state. Vector similarity measures textual relevance, not validity or authorization.

Retrieval first recalls semantically related candidates, then reranks by scope, time, provenance, and task need under a Token budget. A highly similar expired address cannot override an address supplied this turn.

The stale-memory experiment observes recall, adoption, execution, and derived write-back. OWASP's 2026 guidance treats memory as an attack surface because poisoned state persists and propagates. OWASP, Memory is a feature; it is also an attack surface

Report recall, contamination, stale adoption, cross-project leakage, and write-back amplification.