An agent resumes a software project after several days. It can read the code but may not know why the team rejected a change or which result still needed checking. Memory can restore that context. It can also carry forward an obsolete observation or an instruction nobody approved.
Continuity therefore requires a choice of storage mechanism and a decision about the authority of its contents. A visible lifecycle distinguishes a proposal from validated knowledge and from a note that should no longer influence the work.
Distinguish working context from persistent knowledge
A stateless API call does not retain earlier calls by itself. The application supplies the required information. Some products add history, summaries or memory, with capabilities determined by their configuration.
Four mechanisms provide a useful distinction. They can coexist and are not universal product categories.
| Mechanism | Purpose | Question to examine |
|---|---|---|
| Versioned knowledge base | Keep identified, approved documents | Which version governs and who can read it? |
| Memory tool | Let the model request reads and writes | Which code authorises and executes them? |
| Context editing or compaction | Reduce the current conversation | Which information remains available? |
| Persistent-memory service | Retrieve information across sessions | How are versions, access and deletion managed? |
Anthropic’s memory tool illustrates the second mechanism. The model requests operations and the application handles storage and execution. The /memories path does not by itself identify provider-managed storage.
Compaction summarises a conversation to continue within a limited working window. It does not automatically create a durable, shared and governed memory. The application must define retention and retrieval.
Record information with its provenance
Suppose a development agent finds that a migration fails on old records missing a newly mandatory field. The observation may help the next session, but it must stay connected to the test and code version.
The note records the observation and its source, including its scope and approval state. A reference to the test log or correction prevents a local finding from becoming an unexplained general rule.
The team distinguishes the observation from instructions defining the agent’s mandate. Memory can inform work without granting publication rights or changing security policy. Separate files help organise the boundary; permissions and application code enforce it.
External material must not become privileged instruction merely because the agent has stored it. Updates with substantial consequences may need human approval before later use.
Andrej Karpathy’s LLM Wiki pattern describes another approach to compiling sources into knowledge pages. Organisational use still needs an explicit decision about those pages’ authority and approval.
Retrieve the right information when needed
Persistent memory need not be inserted wholesale into every request. The agent may browse, search or receive a selection prepared by the application. Retrieval must preserve references and respect the current user’s access.
In the example, the migration observation appears when the agent works on that migration. Unrelated tasks do not need every past incident. Focused retrieval reduces both irrelevant context and the risk of an old note redirecting the work.
Evaluation includes a relevant fact, missing information and conflicting versions, as well as a note the current role cannot access. The team checks retrieval and how the agent expresses uncertainty. Confident wording is not evidence of a correct selection.
Passwords and access tokens remain in a secrets system. Personal data belongs in memory only where the task and applicable framework justify it. Information maintained in code or business software is often better referenced than copied without an update mechanism.
Correct, replace and withdraw a note
After the software is corrected, the migration observation may no longer describe current behaviour. The process marks it as replaced or expired and links to the correcting version. Current retrieval should then prefer the applicable state.
An item can move from proposed to approved, then available to authorised roles, reviewed and eventually withdrawn or replaced. Each transition has an owner and a defined effect on indexes and caches. This is an architectural pattern to adapt to the chosen mechanism.
History explains past decisions but does not justify retaining all data indefinitely. Corrections and deletions must reach the derivative stores concerned under their legal and technical conditions. Backup retention and restoration rules must also address reintroduction of withdrawn information.
When two sources disagree, the system can expose provenance and request a decision. The newest note is not automatically the correct one. An accountable owner determines which reference applies.
Measure the value of continuity
The trial should demonstrate a benefit such as correct task resumption or fewer repeated searches. It also measures errors caused by old notes and the effort needed to maintain them.
Cost includes writing, retrieval and review, plus the context sent to the model. Caching can reduce some expenses under provider-specific conditions. Large, rarely relevant memory can cost more than retrieving the original source when needed.
Usable memory lets the team establish where information came from, why the agent may use it and how to withdraw it when validity changes. That connects continuity with control of the system.
Continue with a versioned knowledge base.