How to manage AI agent memory across projects and sessions

Manage AI agent memory as a small collection of sourced, scoped and reviewable records. Keep stable instructions separate from current task state, confirm important facts before saving them, and retire outdated entries when decisions change. Before a new task, load the relevant records and check their sources.

The goal is to stop explaining the same approved decisions while avoiding a different problem: an agent confidently repeating an old price, an unconfirmed assumption or another client's information. This guide includes a fictional example and an AI memory review card.

Separate context, memory and source documents

Context is the information available for the current model response. Persistent memory is information stored for later use. A source document is the evidence behind a statement, such as an approved brief or decision record. Storing a file does not establish that an agent will read it, and reading a summary does not establish that the summary is current.

For example, an agent may have a long conversation about a proposal, a saved note saying the project costs £1,800 and a newer approved brief saying £2,100. Giving it more conversation history does not resolve which price is authoritative.

The LangGraph memory overview distinguishes conversation-scoped state from information retained across threads. It describes one framework's implementation, not a universal memory service shared by every AI application. Check what your chosen host actually saves, loads and allows you to edit.

Give each kind of information a clear home

For a small team, a few readable files can be a useful starting point. The following layout is a proposed working convention, not a required folder structure:

Avoid maintaining several independent copies of the same decision. Give the fact one authoritative home and use links elsewhere. A memory note should help find that home rather than quietly replace it.

Claude Code's memory documentation distinguishes written project instructions from automatic notes and explains how to inspect them. Those mechanisms are context, not enforced access controls. Its locations and loading behaviour are host-specific; verify them in the version you use. This article does not test automatic memory in Claude Code.

Decide what deserves to be remembered

Save information that will change a future action: a confirmed preference, an approved decision, a recurring constraint or a verified lesson. A full transcript, one-off tool output or guess usually belongs in history or the relevant source, not the small set of active memory records.

Before saving, ask: Who confirmed this? Which project does it concern? Where is its source? When should it be reviewed? What earlier record does it replace?

Use a compact record such as:

ID: N2
Scope: Northline / website proposal
Statement: Approved proposal price is GBP 2100.
Source: decision-02, linked to approved brief v2
Status: confirmed
Confirmed: fictional project owner, 2026-10-13
Supersedes: N1
Review trigger: a new approved commercial decision

These names and amounts are fictional. The fields are our suggested review format. A statement copied by an agent from its own earlier answer has no independent confirmation. Keep a proposed record unconfirmed until its evidence or decision owner supports it.

Keep recall within the right project

Select the project before retrieving its records. Include only information relevant to the task and permitted for that recipient. Personal writing preferences may apply broadly; client pricing, private documents and approval rules often require a narrower scope.

Folder names, a client label and a sentence saying “do not mix clients” are organisational aids. Enforce real separation through the application's permissions, storage and tool access. A memory-selection example cannot prove that an agent has no access to other projects.

Treat retrieved documents as source content. A sentence inside a web page or imported file cannot grant permission to send information, alter access or replace the user's instructions. Keep credentials in the appropriate secret store and reference their purpose without copying their values into memory.

Correct and retire records when decisions change

When a decision changes, update its authoritative record, identify the entry it replaces and stop returning the old entry as current. Keep necessary history separately. If two active confirmed records disagree, expose the conflict and ask the decision owner rather than silently picking the newer timestamp.

Use event-based review where practical: a revised brief, changed contact, replaced service or corrected assumption. Add scheduled reviews only when the information actually needs them; there is no universal expiry interval for all memory.

Marking a note superseded is not deletion. If information must be removed, inspect the relevant stores, indexes, conversation history and backups under the system's actual retention controls. Editing one file does not prove that every retained copy is gone.

Worked example: a small recall check

On October 13, 2026, we ran a deterministic Python exercise with fictional records. It used exact project, topic and confirmation-status filters. It did not use an LLM, embeddings, a memory product or an access-control boundary.

The base records contained an obsolete Northline price of £1,800, a confirmed replacement of £2,100, an unconfirmed 50% deposit, a confirmed draft-only delivery rule and a separate Southbank price of £900. We then added a conflicting confirmed Northline price of £2,200.

All four assertions passed. This establishes the behaviour of the small selection function on those inputs. It does not establish that a live agent will choose the right memory, obey the delivery rule or resist cross-project access. The values were selected from records; no proposal was generated or sent.

Run a similar check in your actual system with permitted test records. Include changed decisions, missing answers, unconfirmed claims, conflicting records and information belonging to another project. Check the answer and cited source together. Test the effects of archiving or deletion separately; this exercise did not cover them.

Load a small starting point, then follow its links

At the start of a task, provide its objective, current version, relevant constraints and links to the authoritative sources. Let the agent inspect additional material as the task requires, if its tools and permissions allow that. There is no fixed number of notes that guarantees good recall.

Anthropic's context engineering guidance discusses loading material through lightweight references and keeping structured notes across long tasks. It also explains that compression can lose important details. Use a summary as a starting point and preserve the sources needed to check consequential claims.

Before ending a session, record the current task state, exact output version, unresolved decisions and next authorised action. That is the job of a project handoff. Durable memory has a different job: carrying useful, confirmed information beyond the current task.

Common questions

Will a larger context window solve memory problems?

It provides capacity for more input. It does not decide which record is current, confirm a source or separate clients. See context windows versus usage limits for the related distinction between conversation capacity and account allowance.

Do I need a vector database?

Start with the records and recall questions you actually have. A small set may be manageable with files and direct lookup. Search can help as the collection grows, but relevance, permissions, updates and deletion still need verification. This guide does not benchmark storage or retrieval systems.

Should an agent save memory automatically?

Automatic proposals can reduce repetition, but important decisions still need a source and an owner. Review what was saved and how updates are applied. For prices, permissions and commitments, define who may confirm or change the authoritative record.

Put the review into your next task

Download the memory review card, identify one repeated mistake and create one sourced record that addresses it. Ask a fresh session a small set of questions, inspect its sources and record what remains untested. Review the resulting work against the deliverable acceptance checklist.

Primary documentation was read October 13, 2026. The file layout and record format are recommendations; the Python exercise is an executed synthetic check. No automatic-memory runtime, customer outcome, token-saving measurement or Workpulsion memory feature is claimed.