Agent Memory That Earns Its Keep

When should an agent forget that you switched suppliers?

Picture a procurement agent in its fourth month of work. It knows your main vendor well by now. It also still knows the previous vendor's payment terms, the approver who left in spring, and a delivery address from a one-off order in February, and it treats all of it as equally current. Nothing in that memory is fabricated. Every entry was true when it was written. The failure is quieter than a hallucination: the agent remembers accurately, and acts on facts whose time has passed.

That is the normal failure mode of agent memory, and it arrives because the first version worked. Remembering helped, so the team let the agent remember more, with no rule for what expires. Storing was never the hard part. The hard part is the editing: what gets in, how long it stays, and how it leaves.

Run state is not memory

Start by separating two things that often get built as one. Run state belongs to a single thread: the messages so far, the intermediate results, where this run has got to. It exists so this run can continue, and when the run ends, most of it should end too. Memory is what crosses threads. It is read in a later session, by a later run, and it changes how that run behaves.

LangGraph draws the line in exactly those terms: short-term memory is thread-scoped and persisted so a thread can resume, while long-term memory lives in a separate store, organised by namespace, and can be recalled in any thread. The distinction sounds like plumbing. It is actually a gate. If a detail only matters inside this run, it is state, and it should die with the run. Only a detail that should change a future run's behaviour earns a place in memory, and that bar should be high, because everything past it becomes a standing instruction your future self never re-read.

Three kinds of memory, three shelf lives

What passes the gate comes in three kinds, and they age differently.

Facts about a user, a vendor, an account: call this semantic memory. A preferred invoice format, a plant's shutdown week, who approves spend above a threshold. Facts are the most useful kind and the fastest to rot, because the world they describe keeps moving. An experience is different. Episodic memory holds what happened: the extraction that failed because a field was blank, the escalation that worked. Episodes age more slowly, and their value is as examples, a record of what this situation looked like last time. The third kind is procedural: the instructions the agent runs under. When an agent revises its own instructions from feedback, it is editing the rules, not the record, and that deserves a review gate the other two kinds do not need. A wrong fact misleads one run. A wrong rule misleads every run after it.

Writing is the hard part

Retrieval gets the attention, but the quality of a memory system is set at write time. Two choices decide most of it.

The first is when the writing happens. Writing in the hot path, during the run, makes a memory available immediately and lets you show the user what was saved. It also makes the agent do two jobs at once, and the second job gets done badly at busy moments. Writing in the background keeps the run fast and lets a separate pass distil properly, but a second thread can start before the first thread's lessons exist. There is no free option here. Pick per deployment, and know which cost you accepted.

The second choice is shape. A single profile document, updated in place, is easy to read back whole and hard to update safely as it grows; each rewrite risks quietly dropping a field. A collection of small, separate memories is easier to add to and tends to recall better, but now the system has to update and delete entries rather than only appending, and search has to find the right one. Either way, store the distilled entry, not the transcript it came from. A transcript is a log. A memory should read like a note the agent wrote to its future self: the fact, who it belongs to, where it came from, and when it stops being safe to trust.

One vendor, three sessions

Take the procurement agent again, this time with those rules in place.

In the first session, a person corrects the agent: this vendor's invoices are rejected unless the purchase order number sits on the first line. The correction is written as a fact, scoped to that vendor, with the session it came from attached. In a new thread weeks later, the agent retrieves the fact before processing the next invoice, places the number correctly, and nobody is asked a question they already answered. In the third session, the vendor changes its invoicing portal and the old instruction stops applying. The person says so once. The memory is updated, the old entry is retired rather than left to compete with the new one, and the next run never sees it.

Read that sequence again and notice what did the work. Not the store. The scope, the provenance, and the retirement did.

The reading side has to be just as deliberate. The useful pattern is old: MemGPT treated the context window as main memory and everything else as external storage, paging information in and out instead of pretending the window could hold a lifetime of interaction. In Claude Managed Agents, memory stores are collections of text documents mounted into the session, so the agent reads what it needs with ordinary file tools rather than receiving its whole past in the prompt. That shape matters. An agent handed fifty retrieved memories per task has not been given a memory; it has been given a distraction with a search index. Retrieve narrowly, by scope first and similarity second.

When remembering is the wrong call

Some deployments should have little long-term memory, or none. A one-shot extraction over a document set gains nothing from remembering the last client's documents, and in a multi-tenant system a namespace mistake is not a bug with an error message; it is one customer's facts surfacing in another customer's session. Sensitive detail raises the stakes again. A memory system that cannot truly delete is a liability: in the Claude Managed Agents design, every change creates an immutable version, and the redact operation exists precisely so a leaked secret or a piece of personal data can be scrubbed from history while the audit trail survives. If your stack cannot do the equivalent, be honest about it and store less.

A delete button is not enough. Forgetting also needs a clock. Facts should carry review dates tied to how fast their subject changes: an approver's name gets months, a price gets weeks, a regulatory deadline gets checked against its source. A memory with no expiry and no owner will outlive its truth, and it will do so confidently, in fluent prose, inside a session whose user has no reason to doubt it.

So the test we would apply to any memory feature is simple to state and awkward to pass. Show the write rule, the scope, the expiry, and the correction path. If a team can show all four, their agent's memory will probably earn its keep. If the answer is "it remembers everything," you are looking at next quarter's incident, already written down and waiting to be retrieved.

Work with us

If your agents keep re-asking questions your users already answered, or keep acting on facts that stopped being true last quarter, the gap is rarely the model. It is the memory design around it, and that is deployment work we do. Tell us where yours breaks through Trida AI's intake.