You correct an AI assistant, close the session, and discover later that the correction did not survive. A settled product decision gets reopened. A project constraint disappears. The assistant returns to the format you already rejected. If this keeps happening, replacing the model may not solve the problem.

You need a memory system that carries durable context across sessions, retrieves situational context only when it is useful, and gives people control over what is stored. The hard product decision is not whether an assistant can remember. It is deciding what deserves to persist, where it belongs, when it should resurface, and how you will know it is still correct.

Key takeaways

• Persistent memory belongs to the assistant system, not to the model alone. The application must store, select, and supply relevant context.
• Keep stable instructions separate from the larger archive of project history, documents, meetings, and learned context.
• Do not save raw conversations by default. Distill durable rules, decisions, updates, and lessons into reviewable memory entries.
• Give every memory a scope, provenance, status, sensitivity level, and review condition so that old information cannot silently overrule current reality.
• Measure whether the right memory changes the assistant’s behavior. Storage volume is not a useful definition of memory quality.

Persistent memory is a context system, not a model feature

A language model responds to the context supplied for its current task. It does not automatically bring every previous interaction, decision, and correction into a new session. Something outside the model has to preserve that information and decide when to put it back into context.

This distinction becomes easier to see when you separate three concepts that are often grouped under memory:

• Context window: the temporary material available to the model for the current request, including instructions, conversation turns, retrieved records, and tool results.
• Conversation history: the raw sequence of messages from one or more interactions. It may be retained, but retention alone does not make it useful.
• Persistent memory: selected information that survives beyond the current session and can be reintroduced when its scope and relevance match a later task.

A basic implementation can save a transcript to a JSON file, reload it, and send the accumulated history back to the model. That proves persistence is possible, but it does not solve retrieval. As the transcript grows, irrelevant details compete with the few facts that matter. Cost and latency can increase, contradictions accumulate, and the assistant may still miss the needed decision inside a large block of text. Remembering everything is not the same as retrieving the right thing.

Claude Code illustrates the underlying architecture: a new coding session can receive durable context through CLAUDE.md or auto-memory instead of inheriting an unlimited record of earlier sessions. The product around the model is responsible for continuity.

That leads to a clearer product contract. A useful assistant should preserve information with future value, retrieve only what applies to the current task, reveal material assumptions when they affect the answer, and make correction or deletion straightforward. If your memory feature cannot satisfy that contract, it is closer to a transcript archive than an assistant memory.

Give each kind of memory a different home

One undifferentiated memory store creates predictable trouble. A formatting preference, a signed-off roadmap decision, an old meeting transcript, and a relevant market report do not have the same authority or retrieval needs. Treating them alike makes conflicts harder to resolve and increases the chance that incidental conversation becomes permanent instruction.

A practical architecture uses four distinct memory layers:

Layer	What belongs there	How it should be used
Instruction memory	Stable working rules, approved preferences, policies, recurring commands, and active constraints	Keep it small and make it available whenever its scope applies
Experience memory	Durable corrections, useful discoveries, recurring failure patterns, and lessons from completed work	Promote it only after deciding that the lesson should influence future behavior
Retrieval memory	Documents, meeting records, project history, research, transcripts, and other large bodies of knowledge	Leave it outside the prompt until the current request makes it relevant
Action memory	Reminders, unresolved commitments, decision triggers, and stored context tied to a future moment	Surface it when a condition is met and make the proposed action visible to the user

The action layer is especially important. A record sitting in a database has been stored, but it has not yet helped anyone. Memory creates value when a relevant fact appears before a decision, an unresolved promise appears before the next meeting, or a project constraint prevents the assistant from proposing an invalid plan.

Add scope and provenance before adding embeddings

Semantic retrieval can find conceptually related text, but similarity does not establish authority. A preference from one user should not become an organization-wide rule. A decision from a completed project should not govern a new project merely because the wording is similar. Scope and provenance need to narrow the candidate set before relevance ranking begins.

Each durable memory entry should carry enough structure to answer these questions:

• What is being remembered? Store a concise rule, fact, decision, update, lesson, or commitment rather than an unexplained transcript fragment.
• What type is it? The type determines whether it is always available, retrieved on demand, or activated by an event.
• Where does it apply? Identify the user, team, organization, client, product, or project scope.
• Where did it come from? Preserve the originating conversation, meeting, document, or approved manual entry.
• When was it captured? A timestamp helps reviewers distinguish current information from historical context.
• Why does it matter? Record the future decision or workflow the information is expected to improve.
• What is its status? Distinguish proposed, approved, active, superseded, expired, and deleted entries.
• What can replace it? Link a changed decision to the entry it supersedes instead of leaving both versions active.
• How sensitive is it? Apply access, retention, and retrieval controls before the information reaches the model.
• When should it be reviewed? Use an expiry date or a business event such as a project ending, a policy changing, or a decision being reopened.

You also need an explicit precedence policy. A reasonable default is to apply non-overridable organization policy first, then active project decisions, then user preferences, and finally historical material retrieved for reference. Your actual hierarchy may differ, but it must be deterministic. When two entries of equal authority conflict and neither clearly supersedes the other, the assistant should expose the conflict and ask for a decision. Silently blending contradictory memories creates confident but unstable behavior.

Do not solve conflicts by overwriting history without a trace. Mark the old entry as superseded, connect it to the approved replacement, and exclude it from active retrieval. That preserves an audit path while preventing yesterday’s decision from masquerading as today’s rule.

Build the smallest useful memory, then operate its lifecycle

You do not need a vector database to validate the behavior. Start with one project and a human-readable file called AI-MEMORY.md. The point of this version is not scale. It is to learn which information is worth carrying forward and which controls people need before you automate persistence.

1. Create bounded sections. Use Working Rules, Current Projects, Decisions Already Made, Important Context, Lessons Learned, and Do Not Store.
2. Keep entries operational. A decision should include what was decided, when it was decided, why it was chosen, and what evidence would justify reopening it.
3. Load the file only where its scope applies. A project memory should not be attached to unrelated work merely because it is convenient.
4. Generate proposed updates at the end of meaningful work. Ask the assistant to separate durable rules, decisions, project updates, and lessons from temporary conversation details.
5. Review the diff before persistence. Approve additions, changes, and deletions rather than telling the assistant to remember everything.
6. Prune as part of normal work. When a project closes or a decision changes, archive or supersede its active entries immediately.

Include an explicit prohibition against passwords, API keys, authentication secrets, and sensitive personal information that is unnecessary for the workflow. A memory feature expands the places where data can be retained and later exposed. The safe default is to exclude secrets entirely and retrieve protected business data only through systems designed to enforce the appropriate permissions.

The file will eventually reveal its limits. Rules become contradictory, completed projects remain active, useful knowledge gets buried, and manual loading becomes unreliable. Those are signals to introduce a managed lifecycle, not reasons to pour the same uncurated content into a larger database.

A reliable system follows the loop capture, distill, store, retrieve, act, and review. Each stage has a separate job:

1. Capture: give decisions, meeting notes, useful documents, corrections, and recurring preferences an easy route into the system. Preserve the source, date, project, type, and reason the item matters. Capture should create a candidate, not an unquestioned permanent memory.
2. Distill: convert raw material into retrievable units. For a meeting, extract participants, decisions, action items, open questions, and commitments. For a knowledge item, preserve a concise summary, key ideas, important facts, personal notes, and the projects it may support.
3. Store: separate a small always-on store from the larger retrievable archive. The always-on store contains active rules and constraints. The archive contains material that should enter context only after a relevant request.
4. Retrieve: apply identity, tenant, project, sensitivity, and status filters before ranking candidates. Then use keyword, metadata, semantic, or hybrid retrieval to find relevant entries. Pass a compact result with provenance into the current context rather than injecting an entire document collection.
5. Act: use the memory to alter an answer, surface a commitment, enforce a constraint, or propose a next step. When a memory materially changes the result, make that influence inspectable. Require confirmation before an assistant takes an external, costly, destructive, or otherwise difficult-to-reverse action.
6. Review: expire stale entries, resolve conflicts, test deletions, and examine memories that repeatedly appear without helping. Trigger review when projects end, decisions change, access is revoked, or users correct the assistant. A calendar reminder alone will not catch those state changes.

Move beyond the file when the product needs shared access across users, strict tenant isolation, fine-grained permissions, event-triggered resurfacing, retrieval over a substantial archive, or auditable deletion. Those requirements justify structured storage and retrieval infrastructure. They do not remove the need for the small, curated instruction layer.

Measure trust and task improvement, not storage volume

A memory demo is easy to make impressive. Give the assistant a distinctive preference, start another session, and show that it can repeat the preference. A production evaluation has to answer harder questions: Did the system select the right fact? Did it ignore irrelevant history? Did it respect scope? Did the retrieved memory improve the work? Could the user correct or remove it completely?

Make control part of the core experience

People should be able to inspect what the assistant remembers, see where an entry came from, understand where it applies, correct it, mark it as superseded, and delete it. If memory is invisible until it causes a strange answer, users are forced to debug the assistant through conversation.

Enterprise controls should also cover tenant boundaries, role-based access, sensitivity classification, retention, deletion propagation, audit history, and an operational kill switch for memory retrieval. These are not secondary administration features. They determine whether the assistant can safely use persistent context at all.

Build evaluations around expected and forbidden memories

Create a test set from representative tasks. For each request, specify the memories that should be retrieved, the memories that must not be retrieved, any precedence relationship, and the behavior expected from the assistant. Include stale decisions, cross-project lookalikes, conflicting preferences, revoked access, deletion requests, and cases where no memory is relevant.

Track measures that reveal where the system fails:

• Capture acceptance: how often proposed memories survive human review without being rejected or substantially rewritten.
• Retrieval precision: the share of retrieved entries that are relevant to the current task.
• Retrieval recall: the share of expected relevant entries that the system successfully retrieves.
• Stale-memory use: how often an expired or superseded entry influences the answer.
• Conflict handling: whether the assistant applies precedence correctly or asks when authority is ambiguous.
• Unauthorized exposure: whether content crosses a user, project, role, sensitivity, or tenant boundary.
• Deletion integrity: whether a deleted memory disappears from active storage, retrieval results, derived summaries, and other copies governed by the deletion request.
• Task benefit: whether memory improves the quality or completion of the target workflow when compared with the same task performed without memory.

I would treat unauthorized exposure and failed deletion as release blockers, not as average-quality metrics that can be offset by good retrieval elsewhere. Targets for the other measures should reflect the consequence of the workflow. Remembering a preferred report layout and carrying a commercial commitment into a customer response do not require the same level of review.

Increase authority only after retrieval is dependable

Roll out memory in modes that increase its influence gradually:

1. Shadow mode: retrieve and log candidate memories without exposing them to the model’s answer. Compare the results with the expected set.
2. Suggestion mode: show the user a proposed memory or reminder and require approval before it affects future work.
3. Assisted mode: inject approved, low-risk memories automatically while showing which entries influenced the response.
4. Action mode: allow narrowly defined triggers to propose or execute work only after the required authorization and confirmation controls are in place.

This sequence separates retrieval quality from action risk. If an irrelevant memory appears in shadow mode, you have a ranking problem. If the correct memory triggers the wrong operation, you have an action-policy problem. Combining both layers in the first release makes failures harder to diagnose.

Start with one recurring workflow and one clearly bounded scope. Create its small always-on memory, record decisions with provenance, require review for updates, and run representative tasks with memory enabled and disabled. Expand only when the assistant retrieves the right context without importing unrelated history. Until that happens consistently, you have persistence, but you do not yet have dependable memory.

References

• Think Tank AI – Make an AI That Never Forgets

---