Save information between sessions when it is likely to change a future decision and you can preserve its source, scope, and conditions of validity. Good candidates include an explicit user preference, the reason for an accepted project decision, or a verified route to evidence that is expensive to rediscover. A memory should also say when to recheck it and how it can be corrected or removed.
Do not treat persistent storage as a promotion from “someone said this” to “this is true.” A remembered test result describes a particular revision and environment. A remembered approval covers a particular action. Neither becomes a standing fact merely because it survives the conversation.
Choose the destination before saving the sentence
Different kinds of information need different lifetimes and audiences.
| Information | Useful destination | What limits reuse? |
|---|---|---|
| “Use concise explanations in my personal work” | Personal preference memory | The user’s later correction and the current task’s needs. |
“The importer depends on total_cents” |
Reviewed project contract, with a memory pointer if useful | The consumer and contract version. |
| “The current migration has two failing checks” | Active task handoff | The working revision and latest test run. |
| “This package currently costs a particular amount” | Dated research record | Pricing changes and the next consequential use. |
| A credential copied from a terminal | Secret-management system, never conversational memory | Access policy and rotation requirements. |
The distinction affects collaboration. A local memory cannot substitute for documentation the whole team needs to review. VS Code’s memory documentation describes different systems by agent harness. Its Local harness uses user, repository, and session memory files stored locally by default; those repository files are not shared project files. The Copilot harness instead uses cloud-backed Copilot Memory, whose repository facts can be shared with people who have access to the repository and Copilot Memory. Check the selected harness, storage, and visibility before saving information or assuming colleagues can retrieve it.
The design below is a proposed application record. It is not a portable format automatically understood by every agent.
Store a claim with enough context to challenge it
Consider a synthetic order-export project. A team decision requires CSV amounts to remain integer cents. A useful memory could look like this:
{
"id": "orders-export-money-unit",
"kind": "project_decision",
"scope": "project:orders-export",
"statement": "CSV total_cents remains an integer in cents.",
"source": "docs/export-contract.md#money",
"source_kind": "reviewed_project_document",
"observed_at": "2026-10-28T12:00:00Z",
"last_verified_at": "2026-10-28T12:00:00Z",
"status": "active",
"revalidate_when": ["export contract changes", "consumer changes"],
"supersedes": null
}
The scope prevents a convention from one project spilling into another. The source lets a future session check the owning document. The dates distinguish when the information was observed from when it was last verified. The revalidation triggers make clear that “active” does not mean permanently correct.
A source pointer also needs identity. If a path could refer to different repositories, store the repository identifier. If historical interpretation matters, preserve a revision or immutable document reference. Avoid saving a private URL into a shared memory store merely to make the reference convenient.
For an inference, use a different kind or status and keep the uncertainty in the statement: “This consumer appears to depend on integer cents; confirm against its decoder.” Do not let summarization quietly remove “appears” or “confirm.”
Use expiration for the decision at hand
A fixed expiration date is useful for temporary constraints: a feature freeze ends on a known date, or a cache entry should not be reused after a short interval. Other memories need event-based invalidation. A build command becomes suspect when the build system changes, even if it was checked yesterday.
A practical retrieval policy can apply these checks in order:
- Is the requesting user or agent allowed to read this memory?
- Does its scope match the current project and task?
- Is it active rather than superseded or deleted?
- Has a time limit or invalidation event been reached?
- Is its source accessible, and does the current action require revalidation?
The last check depends on consequence. Remembering where a test lives can guide a read immediately. Remembering that a service was healthy last week cannot establish that deploying to it is safe today. Retrieve the historical note, then inspect current state.
Make stale records visibly stale. Silently returning an expired statement with a slightly lower search score asks the language model to infer a policy the storage system already knows. For a simple implementation, filter ineligible records before ranking and include validity information with retrieved results.
Correct the active record, then the routes that find it
Suppose the team changes the export contract to a decimal string called amount. A new memory should identify the replacement decision and explicitly supersede the old record. Retrieval for the current contract should return the new one. Historical queries may still need the old decision, clearly marked with its period of validity.
Corrections require more than appending “ignore the previous note” to an unrelated chat. Update the memory entry, any summary derived from it, and the search representation that retrieves it. Otherwise the stale claim can remain the most visible result.
Deletion has a different purpose. If a user asks for a personal preference to be forgotten, removing it from the active search index may be insufficient if summaries or cached copies can reintroduce it. Identify the stores you control and their deletion behavior. Keep only the audit information your policy permits; do not retain the sensitive text inside a tombstone whose purpose is to say it was deleted.
This article does not establish a particular service’s retention guarantees. That requires checking its storage, backup, and deletion implementation.
A small maintenance exercise
A local synthetic fixture tested a minimal eligibility rule: select only active records in the requested project whose optional expiry is later than the supplied time. It contained an active export decision, an expired temporary instruction, a superseded decision, a deleted entry, and a valid entry from another project. Only the active matching decision was selected.
The fixture then replaced that decision with a corrected record and verified that current retrieval returned only its replacement. Finally, marking the replacement deleted left no eligible records. The checks passed with Python 3.14.2.
This verifies the fixture’s filtering and replacement rules. It does not test natural-language extraction, relevance ranking, authorization enforcement, backup deletion, or whether a model follows the retrieved note. Those are separate behaviors to evaluate in a real memory system.
Keep the memory store reviewable
A useful periodic review asks which records still influence decisions, which have unreachable sources, and which duplicate information that now lives in a maintained project document. Remove obsolete copies or replace them with a pointer to the owning source.
Anthropic discusses structured note-taking as a technique for continuity beyond the live context window. Persistence supplies continuity; the record and maintenance policy proposed here supply accountability for what persists.
Start with one recurring rediscovery or correction. Save the smallest useful record with its provenance and invalidation rule. On the next relevant task, inspect what was retrieved and whether it helped make the intended decision. That gives you evidence for improving the memory system without assuming that a larger archive is a better one.
Documentation checked October 28, 2026. The record format and maintenance exercise are synthetic and vendor-neutral.
