Give your agent a useful memory, not a junk drawer

1. Check what the product means by memory

Memory can mean several different things: the conversation currently visible to the model, saved notes reused across conversations, files in a project, or information retrieved from a connected knowledge base. These mechanisms have different limits and controls. Before relying on any of them, find out what your agent stores, when it reads that information, and how you can inspect or remove it.

LangChain's memory documentation distinguishes information scoped to one conversation from information reused across conversations. That distinction is useful even if you never use its software. A deadline for today's task belongs in current task state. A preference for dates in day-month-year format might belong in persistent preferences. Keeping those separate prevents an expired deadline from appearing to govern unrelated work next month.

2. Save facts that change future decisions

Useful memory reduces repeated explanation. It can preserve a writing preference, a project convention, a settled decision, or a recovery procedure that was actually verified. A transcript contains much more: abandoned ideas, temporary errors, jokes, guesses, and obsolete instructions. Saving the whole conversation without curation makes the next task responsible for sorting all of that again.

Use a simple test: will this fact change a likely future action, and can I say where it applies? ‘Use the existing invoice template for customer invoices’ can guide repeat work. ‘We discussed invoices on Tuesday’ rarely can. Store a pointer to a large source document instead of copying it into every note. Anthropic's context-engineering guidance treats context as a finite resource and discusses retrieving relevant information when needed. The practical aim is a compact starting point with a path to deeper evidence.

1. Choose one future decision

   Name the action the note should influence, such as selecting a template or preserving a design choice.

2. State the scope

   Specify the project, team, task type, or person the note applies to.

3. Keep the evidence nearby

   Link to the source, decision record, or verified result that makes the note trustworthy.

3. Give each note a small structure

Write a memory note with five fields: fact or preference, scope, source, date checked, and refresh condition. The refresh condition names the event that makes the note questionable. A team convention might need review when ownership changes. A tested command might need review after a dependency update. A product price needs current verification whenever it affects a purchase decision.

Separate an observed fact from your interpretation. ‘The export contained 148 rows’ is an observation about one run. ‘Exports always include every record’ is a much broader claim that the observation does not establish. A durable note should preserve that limit. When the agent proposes a memory update, inspect the actual wording. Small changes such as replacing ‘in this project’ with ‘always’ can turn a helpful preference into an unwanted rule.

4. Resolve contradictions explicitly

As work changes, memory will contain conflicts. One note might say to send a weekly digest; a later decision might replace it with a monthly report. Ask the agent to identify the conflict, inspect the authoritative source, and propose a replacement note. Do not simply add a third note describing the contradiction. Repeated additions leave the next agent to make the same decision again.

Give current instructions their proper context. If you ask for an unusual format today, say whether it is a one-time exception or a new default. If the agent misapplies an old preference, correct the stored scope instead of repeatedly compensating in every prompt. Keep a small change record for consequential team decisions. It should show what was superseded and why, so a future reader can distinguish a deliberate change from an accidental deletion.

5. Test retrieval with a fresh task

A note being saved does not prove the agent will use it. Start a fresh task that should benefit from the note and ask the agent to identify the relevant preference before acting. Check both inclusion and exclusion: it should use the Atlas update template for an Atlas monthly update, and leave that template aside for an unrelated incident report.

If the right note is not retrieved, inspect its title, scope, storage location, and the product's retrieval behavior. A concise note titled ‘Atlas monthly customer updates’ is easier to target than a large file called ‘Things to remember.’ If too many unrelated notes appear, narrow the memory set available to the task. Keep the test small enough that you can compare the actual output with the approved example and identify which instruction caused a mistake.

6. Retire notes as deliberately as you save them

Review memory when a project ends, a decision changes, or a note causes a wrong action. Archive finished task state and remove duplicates. Keep credentials and private account tokens in their intended secret store, not in memory notes. Record only the personal details that are necessary for the work and that you actually want reused.

Use the memory sorter to practice choosing between retain, task only, and discard. Some notes need rewriting before they fit any category. ‘The customer is difficult’ is a judgment with little operational value. ‘For this customer, attach the source spreadsheet and state assumptions explicitly, as requested in the kickoff’ preserves an actionable preference with a source. Good memory should make the next task easier to start and easier to audit, while remaining small enough for you to understand what the agent thinks it knows.