[{"data":1,"prerenderedAt":13},["ShallowReactive",2],{"note-what-i-learned-giving-agents-memory":3},{"slug":4,"title":5,"topic":6,"status":7,"published":8,"summary":9,"minutes":10,"href":11,"html":12},"what-i-learned-giving-agents-memory","What I learned giving agents memory","AI","published","2026-09-23","Memory is not a transcript. On selection, lifetimes, forgetting and what persistent agents change about software.",6,"\u002Fnotes\u002Fwhat-i-learned-giving-agents-memory","\u003Cp>Most AI products still have a peculiar form of amnesia.\u003C\u002Fp>\n\u003Cp>They can reason surprisingly well about whatever is in front of them, but start a new conversation and much of that understanding disappears. You explain the company again. The project again. Your preferences again. The reason a decision was made three weeks ago, again.\u003C\u002Fp>\n\u003Cp>For a chatbot, that can be mildly annoying.\u003C\u002Fp>\n\u003Cp>For an agent that is supposed to do useful work over time, it becomes a fundamental limitation.\u003C\u002Fp>\n\u003Cp>Over the past year I’ve spent a lot of time building with agents and thinking about what happens when they stop being isolated prompts and begin operating as persistent software systems.\u003C\u002Fp>\n\u003Cp>Memory turns out to be one of the more interesting parts.\u003C\u002Fp>\n\u003Cp>Not because storing information is difficult. We have been exceptionally good at putting things into databases for several decades.\u003C\u002Fp>\n\u003Cp>The difficult part is deciding \u003Cstrong>what deserves to be remembered, what it means later, and when it should come back.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2 data-no=\"01 \u002F 07\">Memory is not a transcript\u003C\u002Fh2>\n\u003Cp>The obvious implementation of agent memory is to save every conversation.\u003C\u002Fp>\n\u003Cp>That is useful, but it isn’t really memory.\u003C\u002Fp>\n\u003Cp>A transcript is history. Memory is compression.\u003C\u002Fp>\n\u003Cp>Humans don’t replay every sentence they have ever heard before making a decision. We retain some facts, forget others, form abstractions and gradually build a model of the world.\u003C\u002Fp>\n\u003Cp>An agent needs something similar.\u003C\u002Fp>\n\u003Cp>Imagine an engineering agent working inside a large codebase.\u003C\u002Fp>\n\u003Cp>Over time it might discover that:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>a certain service deliberately avoids local state,\u003C\u002Fli>\n\u003Cli>a particular API has an ugly compatibility constraint,\u003C\u002Fli>\n\u003Cli>the team prefers one architectural pattern over another,\u003C\u002Fli>\n\u003Cli>a bug that looks obvious has already been investigated twice,\u003C\u002Fli>\n\u003Cli>one engineer tends to care deeply about backwards compatibility,\u003C\u002Fli>\n\u003Cli>another system is scheduled to disappear in six months.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of those facts necessarily belong in the immediate prompt.\u003C\u002Fp>\n\u003Cp>But they can dramatically change the quality of the next decision.\u003C\u002Fp>\n\u003Cp>The useful unit of memory therefore isn’t:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>Here is everything that happened.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>It is closer to:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>Here is what appears to remain important.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>That distinction sounds small. It changes the architecture considerably.\u003C\u002Fp>\n\u003Ch2 data-no=\"02 \u002F 07\">More context is not the same as more intelligence\u003C\u002Fh2>\n\u003Cp>Large context windows created a tempting idea: perhaps we can simply give models everything.\u003C\u002Fp>\n\u003Cp>Eventually, that becomes its own failure mode.\u003C\u002Fp>\n\u003Cp>An agent with access to thousands of irrelevant facts can be worse than one with ten useful ones. Retrieval becomes noisy. Old assumptions survive long after reality changed. Contradictory information accumulates.\u003C\u002Fp>\n\u003Cp>Context has a cost even when the model can technically accept it.\u003C\u002Fp>\n\u003Cp>The real problem becomes \u003Cstrong>selection\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>When an agent is working on a database migration, what should it remember about the product?\u003C\u002Fp>\n\u003Cp>When it is replying to a customer, what should it know about the architecture?\u003C\u002Fp>\n\u003Cp>When a user changes their mind, how quickly should an older preference lose authority?\u003C\u002Fp>\n\u003Cp>The quality of a memory system is therefore not measured by how much it stores.\u003C\u002Fp>\n\u003Cp>It is measured by how well it decides what to surface.\u003C\u002Fp>\n\u003Cp>That starts looking less like a database problem and more like an information architecture problem.\u003C\u002Fp>\n\u003Cp>Which, conveniently, means software engineers get to reinvent librarianship with embeddings.\u003C\u002Fp>\n\u003Ch2 data-no=\"03 \u002F 07\">Memories have different lifetimes\u003C\u002Fh2>\n\u003Cp>Another thing that becomes obvious surprisingly quickly: not all memory should behave the same way.\u003C\u002Fp>\n\u003Cp>Some things are effectively permanent.\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>This application uses PostgreSQL.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>Some are durable preferences.\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>Prefer boring infrastructure over introducing another service.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>Some are observations.\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>The current implementation appears to be CPU-bound during type checking.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>Some are temporary.\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>We are debugging the authentication flow this week.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>And some are conclusions that may later turn out to be wrong.\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>This bug is probably caused by caching.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>Treating all of these as equivalent creates trouble.\u003C\u002Fp>\n\u003Cp>Useful agent memory needs some notion of \u003Cstrong>provenance, confidence and time\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Where did this belief come from?\u003C\u002Fp>\n\u003Cp>Was it explicitly told to the agent or inferred?\u003C\u002Fp>\n\u003Cp>Has it subsequently been contradicted?\u003C\u002Fp>\n\u003Cp>When was it last relevant?\u003C\u002Fp>\n\u003Cp>That metadata matters because an agent is not merely retrieving facts. It is retrieving beliefs about a changing system.\u003C\u002Fp>\n\u003Cp>Software changes.\u003C\u002Fp>\n\u003Cp>Organizations change.\u003C\u002Fp>\n\u003Cp>People change their minds.\u003C\u002Fp>\n\u003Cp>A memory system that cannot forget eventually becomes a very confident historian of a world that no longer exists.\u003C\u002Fp>\n\u003Ch2 data-no=\"04 \u002F 07\">Forgetting is a feature\u003C\u002Fh2>\n\u003Cp>This may be the counterintuitive part.\u003C\u002Fp>\n\u003Cp>Good memory requires good forgetting.\u003C\u002Fp>\n\u003Cp>Engineers naturally like persistence. Losing information feels like failure.\u003C\u002Fp>\n\u003Cp>But forgetting can be an important form of compression.\u003C\u002Fp>\n\u003Cp>If an agent worked through twenty hypotheses before finding the cause of a production bug, the useful long-term memory probably isn’t all twenty hypotheses.\u003C\u002Fp>\n\u003Cp>It might be:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>Requests to this service can appear stale because this cache is process-local. Prefer the shared Redis path for cross-instance state.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>The investigation mattered while solving the problem.\u003C\u002Fp>\n\u003Cp>The conclusion matters afterward.\u003C\u002Fp>\n\u003Cp>That raises an interesting question: should agents periodically reinterpret their own histories?\u003C\u002Fp>\n\u003Cp>I think increasingly they will.\u003C\u002Fp>\n\u003Cp>Rather than memory being written once and retrieved forever, persistent agents may continuously consolidate what they know. Recent experiences become observations. Repeated observations become patterns. Some patterns become durable knowledge. Others decay.\u003C\u002Fp>\n\u003Cp>That starts to resemble learning, even if the underlying model weights never change.\u003C\u002Fp>\n\u003Ch2 data-no=\"05 \u002F 07\">Memory changes the interface\u003C\u002Fh2>\n\u003Cp>Persistent memory also changes how software feels.\u003C\u002Fp>\n\u003Cp>Today we largely think of AI interfaces as conversations.\u003C\u002Fp>\n\u003Cp>Open a box. Ask a question. Receive an answer.\u003C\u002Fp>\n\u003Cp>But once the system remembers projects, decisions, people and unfinished work, the conversation becomes only one view into something larger.\u003C\u002Fp>\n\u003Cp>The interesting object isn’t the chat.\u003C\u002Fp>\n\u003Cp>It is the evolving relationship between the agent and its environment.\u003C\u002Fp>\n\u003Cp>An agent might remember that a migration was postponed, notice the dependency has since disappeared, and bring the issue back months later.\u003C\u002Fp>\n\u003Cp>It might understand why a particular architectural decision was made instead of merely observing that the code exists.\u003C\u002Fp>\n\u003Cp>It might recognize that the problem somebody is describing today looks suspiciously similar to an incident from last year.\u003C\u002Fp>\n\u003Cp>At that point the system begins to feel less like a tool waiting for commands and more like another participant in the work.\u003C\u002Fp>\n\u003Cp>That introduces plenty of uncomfortable questions around privacy, control, observability and trust.\u003C\u002Fp>\n\u003Cp>It also makes the software considerably more useful.\u003C\u002Fp>\n\u003Ch2 data-no=\"06 \u002F 07\">The model is only part of the product\u003C\u002Fh2>\n\u003Cp>Building with increasingly capable models has reinforced something I already believed about software.\u003C\u002Fp>\n\u003Cp>The cleverest component is rarely the whole product.\u003C\u002Fp>\n\u003Cp>A powerful model without the right context can produce a mediocre result. A slightly less capable model embedded in a system with good tools, useful memory and strong feedback loops can be remarkably effective.\u003C\u002Fp>\n\u003Cp>The surrounding architecture matters.\u003C\u002Fp>\n\u003Cp>So does product judgment.\u003C\u002Fp>\n\u003Cp>What information do we expose?\u003C\u002Fp>\n\u003Cp>What actions can the agent take?\u003C\u002Fp>\n\u003Cp>When should it ask instead?\u003C\u002Fp>\n\u003Cp>What should be remembered?\u003C\u002Fp>\n\u003Cp>What should disappear?\u003C\u002Fp>\n\u003Cp>What can the user inspect and correct?\u003C\u002Fp>\n\u003Cp>Those decisions increasingly determine whether an AI system feels impressive for five minutes or remains useful after five months.\u003C\u002Fp>\n\u003Ch2 data-no=\"07 \u002F 07\">Where this gets interesting\u003C\u002Fh2>\n\u003Cp>I don’t think the eventual form of agent memory will look much like a folder labelled \u003Ccode>memories\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>It will probably be distributed across several layers: explicit facts, semantic retrieval, project state, interaction history, environmental observations and learned preferences.\u003C\u002Fp>\n\u003Cp>Some memory will belong to a person.\u003C\u002Fp>\n\u003Cp>Some to a company.\u003C\u002Fp>\n\u003Cp>Some to a task.\u003C\u002Fp>\n\u003Cp>Some to the agent itself.\u003C\u002Fp>\n\u003Cp>And agents will need to reason about the boundaries between them.\u003C\u002Fp>\n\u003Cp>We are still early enough that many of these systems feel slightly improvised. That is part of what makes working on them fun.\u003C\u002Fp>\n\u003Cp>A lot of AI right now is focused on making the model smarter.\u003C\u002Fp>\n\u003Cp>I suspect an equally important frontier is making software around the model better at \u003Cstrong>remembering what matters\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Because intelligence without continuity is useful.\u003C\u002Fp>\n\u003Cp>But continuity is what starts turning intelligence into a system.\u003C\u002Fp>\n",1790175176155]