Remember selectively and retrieve evidence.

Memory is more than model weights

A system can retain useful information in several forms. The categories describe what the information does, not a mandatory storage technology or a claim of biological equivalence.

Memory role	Example in the notebook	Possible implementation
Working	Current goal: remove item 7 using Store v2	Active state, context, or a shared workspace
Episodic	A particular failed call, error, time, and version	An execution log or event database
Semantic	A checked fact about the v2 argument schema	A structured record, graph, document, or learned representation
Procedural	A scoped sequence for diagnosing and repairing an argument error	A stored procedure, controller, or trained skill

The source’s coding example stores a stack trace as an episode, a library-version change as a semantic fact, and a repeatedly successful debugging sequence as a procedural skill. Keeping these roles distinct helps avoid interpreting “this once happened” as “this is always true.”

Updating an external record does not automatically change a model’s parameters. The lab’s schema inspection stores a fresh semantic record. Its weight-update count is zero. Parameter learning is a separate process that may be slower, more expensive, or more likely to affect unrelated behavior than changing a small record.

Associative retrieval finds related candidates

Associative retrieval uses a query to find or weight stored information. In the lab, each record has a two-number key. Its score is the dot product of query and key. Softmax turns eligible scores into nonnegative weights that sum to one, and a soft read adds the weighted value vectors.

For query [1, 0], the old guide’s key [2, 0] gives score 2, while the current guide’s key [1.6, 0.8] gives score 1.6. The old guide therefore ranks above the current guide in similarity-only mode. Increasing the second query coordinate can change that ordering. Lowering temperature concentrates the weights; it does not verify the winner.

The query and keys here are hand-designed teaching values. In a learned memory system, a network might produce them and train them through a task objective. The numerical read is similar to the weighted-value calculation in attention, but usefulness still depends on what the keys and values represent.

The lab’s value coordinates encode an object-argument flag and a major-version number. Their weighted mixture can contain a fractional version such as 1.6. That is a continuous feature mixture, not a valid API contract. Soft reads can be useful inside learned computation; exact symbolic operations still need appropriate structure and verification. Do not average incompatible code snippets and treat the result as executable evidence.

Exact constraints answer a different question

The working task refers to demo-project. The small graph says demo-project uses store-v2, whose major-version is 2. Following those exact relations gives a constraint that a similar-sounding v1 guide cannot satisfy. Relational filters and graph queries are useful for dependencies, identities, and other exact requirements.

Version filtering alone is insufficient. The failed-call episode is a v2 record and ranks highly, but it reports a particular error rather than the current schema. The recent forum tip has high assigned confidence but no verification. The evidence-aware mode therefore also requires a semantic fact, a checked source, and a verification date that is still valid under this toy policy.

These checks establish only their stated properties. The notebook’s authoritative reference is a small local simulation. A real memory system would need to verify the actual source and handle uncertainty, ambiguity, contradictions, and incomplete evidence.

Access comes before similarity

The restricted synthetic record is deliberately very similar to the query. The student role cannot retrieve it, even in similarity-only mode. Switching to the simulated maintainer role demonstrates how the permitted candidate set changes before weighting.

All examples are fictional and present in this browser teaching application. This is a demonstration of an access policy, not a security boundary for real confidential information. In a real system, authorization must be enforced where records are stored or served; a client-side role selector cannot establish identity or permission.

Keep provenance and freshness visible

A useful record can include source, observed time, applicable version, verification scope, confidence, and access constraints. Confidence alone is not evidence: the unverified tip has a higher assigned confidence than the checked current guide. It still fails the evidence gate.

At simulated day 7, the original current guide’s verification has expired. Protecting it from archiving preserves its history; it does not renew its validity. The evidence-aware query can correctly return no supported answer. Inspecting the local schema adds a fresh v2 fact with a new timestamp and source reference.

Expiration is a chosen memory policy, not proof that a fact becomes false at midnight. It marks when this system requires rechecking before relying on the record. Conversely, a recent timestamp does not make an unverified claim true.

Consolidation needs a scope and counterexamples

Consolidation can turn repeated experience into a more reusable representation or procedure. Two successful repairs in the notebook suggest a rule for Store v2 argument-type errors on scalar ID inputs. They do not show that every failure can be solved by wrapping an argument in an object.

The broad candidate repairs every error. The scoped candidate repairs an argument-type error but stops and reports denied access. The promotion gate requires two supporting successful episodes and appropriate responses to both fixed development cases. The third episode provides a concrete counterexample to the broad rule.

Storing the scoped procedure writes a programmed record with episode references. It does not train a neural skill. A later distillation process could learn a policy from many verified traces, but it would need additional tasks, independent evaluation, and regression checks. Passing two familiar checks does not establish broad generalization.

Decide what to retain and what to discard

Memory policies choose what to store, retrieve, summarize, archive, or protect. More stored information can increase irrelevant retrieval, contradictions, storage costs, and verification work. Forgetting everything can erase useful evidence and repeated failure patterns.

The lab lets you archive expired unprotected records and restore them. A real summarizer should preserve the distinctions needed later, such as a failed call’s version and error type. Compressing “two argument repairs succeeded and one permission failure remained blocked” into “repairing errors works” would lose the critical exception.

Memory decisions can be programmed, learned, or combined. Evaluate them according to future usefulness and the costs of mistakes, rather than rewarding the number of stored items alone.

Write a policy for three kinds of evidence

The source exercise asks how to store a new fact, a failed tool call, and a repeatedly successful workflow. Draft a policy before opening the example.

Example retention policy

• New fact: record the claim, source, version, time, verification scope, and access constraints. Keep it separate from an unverified hypothesis. Recheck it when the task or dependency changes.
• Failed call: retain the exact request, error, environment version, and outcome as an episode. Avoid storing unnecessary private data. A failure can be valuable evidence even though it is not a successful procedure.
• Repeated workflow: preserve the supporting episodes, propose a limited procedure, test counterexamples, and record its preconditions. Promote it only within the tested scope and keep a way to revise or retire it.

Use fast working state for the current task, durable records for selected evidence, and separate evaluated training when parameters need to change.