Digest

Welcome to a deep dive on agentic information retrieval. This is the reading path behind a collection I’ve been building: nineteen papers that trace a single idea from its roots to its frontier. The idea is this. For most of the last decade, retrieval meant similarity. You turned a query into a vector, you turned every document into a vector, and you found the documents that sat closest in space. Fast, cheap, and for a huge class of questions, good enough. But there’s a different bet being made right now, and it’s the reason this collection exists. The bet is that the best way to find the right document is not to embed harder. It’s to think. To spend real computation at the moment of the search, reasoning about what the query actually means and whether a candidate truly answers it. That’s the thesis behind SID’s recent technical report, which they title, plainly, test-time compute for retrieval. And what’s striking is that this isn’t one company’s pitch. It’s the convergence point of a whole line of research. So let’s walk that line, from the foundations to the open edge.

Start with the foundations, because you can’t appreciate where this is going without seeing what it’s replacing. In 2020, a paper called Dense Passage Retrieval did something that sounds obvious now and was contested then. It trained two neural encoders, one for questions and one for passages, so that a question and its answer would land near each other in vector space. And it beat BM25, the venerable keyword-matching baseline, on open-domain question answering by a wide margin. That’s the moment dense retrieval stopped being a research curiosity and became the default. Every retriever we’ll talk about descends from it.

The same year, another paper gave the architecture its name: Retrieval-Augmented Generation. The move was to take a language model that generates text and bolt onto it a retriever that fetches passages from a big external index. The model no longer had to memorize all the world’s facts in its weights. It could look them up. That’s RAG, and if you’ve touched anything in applied AI in the last few years, you’ve touched RAG. It’s the scaffolding the entire field now builds on. There’s a survey in the collection, from late 2023, that maps the whole RAG design space, naive to advanced to modular, and it’s the reference I’d point anyone to for where a given technique fits.

But I want to flag one more foundational paper, because it’s the first crack of light for everything that follows. It’s called HyDE, hypothetical document embeddings. The problem it tackled was zero-shot retrieval, retrieval with no labeled training data for your domain. And the trick was beautiful. Instead of embedding the user’s query directly, you ask a language model to hallucinate a fake answer. A made-up document that would, if it were real, answer the question. Then you embed that fake document and use it to find real ones nearby. Think about what that means. The language model’s generation, its reasoning about what a good answer looks like, is being injected into the retrieval step itself. The query is no longer a static string. It’s the product of a model thinking. HyDE was 2022, and in hindsight it’s the hinge. It’s the first place where generation and retrieval stopped being separate stages and started to blur.

That blurring is the whole second act, which I think of as agentic search loops. Here retrieval stops being a thing you do once, up front, before the model runs. It becomes an action the model chooses to take, in the middle of its reasoning, as many times as it needs.

The paper that crystallized this is ReAct, reasoning and acting. The insight was to interleave chain-of-thought reasoning with tool use, in a loop. The model thinks a little, decides to take an action like a search, reads the result, thinks again, and continues until it’s done. Once you’ve seen that pattern you see it everywhere, because it’s the pattern under basically every search agent shipping today. Retrieval is an action the model decides to take, conditioned on what it’s figured out so far. That’s a profound shift from the RAG default, where you retrieve once with the raw question and hope the top results are enough.

A companion paper, IRCoT, made the same point specifically for multi-hop questions, the ones where you have to chain several facts together. It interleaved retrieval with each step of the chain of thought, using the partial reasoning to write the next query. And the lesson was clear: hard, multi-step retrieval has to be guided by reasoning and done iteratively. One shot won’t cut it. You can already feel reasoning-intensive retrieval being born here.

Then two papers pushed on the control question, the question of when to retrieve at all. FLARE, active retrieval-augmented generation, had the model watch its own confidence as it generated. When it was about to say something it wasn’t sure about, it paused and retrieved, using the sentence it was trying to write as the query. Retrieval on demand, triggered by doubt. And Self-RAG went further: it trained the model to emit special reflection tokens, little control signals that decide when to go retrieve, and then critique whether the passages it got back are actually relevant and actually support the claim. That’s retrieval control and self-criticism folded directly into the model’s own decoding. And notice, that’s the model spending extra computation, at inference time, to manage its own retrieval. We’re inching toward the thesis.

The most recent papers in this act make the loop the explicit training target. Search-R1 uses reinforcement learning to teach a model to interleave reasoning with live calls to a real search engine, learning, end to end, when to search and what to ask for, optimized directly against getting the final answer right. It’s the o1 and R1 reasoning-RL recipe, the same family of methods behind the reasoning models everyone’s talking about, pointed straight at search. And MCTS-RAG brings in Monte Carlo Tree Search: it explores a tree of interleaved reasoning and retrieval steps, and by doing that search over paths, it lets a small model punch up to the level of a frontier model on knowledge-heavy tasks. That phrase, scaling inference-time compute, is exactly the lever we care about. Spend more compute when you search, get better answers. Even from a small model.

Which brings us to the third act, and the part of the collection I find most clarifying: reasoning-intensive retrieval. Because there’s a category of query where the old similarity bet just breaks. Not because the embeddings are bad, but because relevance itself isn’t about surface similarity. The connection between the question and the right document runs through a chain of inference. Think of a coding error whose fix lives in documentation that never mentions the error. Or a math problem whose solution depends on a theorem stated in completely different words. The right document and the query barely share any vocabulary. Their relationship is logical, not lexical.

The paper that nailed this down is BRIGHT, a benchmark released in 2024 built entirely from these reasoning-intensive queries. And the headline result is brutal for the old paradigm: standard retrievers, even strong dense ones, score poorly. The thing that made retrieval work for a decade, semantic similarity, is precisely the thing that fails here. BRIGHT is the yardstick that made the rest of this act necessary, because once you can measure the gap, you can try to close it.

And researchers did. ReasonIR, from 2025, is the first retriever trained specifically for reasoning tasks. They built a synthetic data pipeline that generates genuinely hard queries paired with hard negatives, documents that look related but don’t actually help, and trained on those. It set a new state of the art on BRIGHT. But here’s the detail that ties it back to the thesis: ReasonIR uses test-time compute more effectively. Give it a longer, richer, rewritten query, the product of more reasoning, and its performance keeps climbing. The retriever itself rewards thinking harder at search time. RankRAG, meanwhile, came at it from another angle, instruction-tuning a single model to both rank the contexts and generate the answer, collapsing two stages that used to be separate components into one. And there’s a 2026 survey in the collection that systematizes this entire subfield, reasoning-intensive retrieval, organizing the benchmarks and laying out a taxonomy of where, exactly, reasoning can enter the retrieval pipeline. It’s the roadmap for the territory SID-1 is staking out.

So now we arrive at the fourth act, the destination: test-time compute for ranking. This is the thesis stated outright, as a body of work.

The keystone paper is Rank1, from early 2025. And the title is almost the whole story: test-time compute for reranking in information retrieval. What they did was train a reranker, the component that takes a handful of candidate documents and decides their order, to actually reason before it scores. They distilled hundreds of thousands of reasoning traces from frontier reasoning models, the o1s and R1s, so that a much smaller reranker learns to think step by step about whether a document is relevant, and only then assigns its score. Three things came out of that. It hit state of the art on the hard reasoning and instruction-following retrieval benchmarks. It generalized remarkably well to data it had never seen, because it could respond to instructions in the prompt rather than relying on a fixed notion of relevance baked into an embedding. And, crucially, it produced an explainable reasoning chain for every ranking decision, something you can show a user, or hand to a downstream RAG system as evidence. Rank1 is the clearest academic statement of the idea SID-1 is productizing: a fundamentally new kind of reranker, one whose quality scales with the compute you let it spend at the moment of the search.

If you’re skeptical, the natural worry is cost. Reasoning is expensive. Does this only work with a giant model? The answer, from a paper sometimes called InteRank, is no. They distilled and then reinforcement-tuned reasoning into a three-billion-parameter reranker, tiny by today’s standards, that generates a relevance explanation at inference time. And it placed third on the BRIGHT leaderboard, beating models more than twenty times its size. The win survives compression. You can have a small, cheap, fast reranker that still reasons, and still explains itself. That’s what makes the whole approach practical rather than a luxury.

The newest papers in the collection sketch where this goes next. Verbal-R3 frames a verbal reranker, one that reasons in natural language, as the missing bridge between retrieval and generation, instead of just dumping raw passages into the model’s context and hoping. GRC goes for the most ambitious unification: one model that handles reasoning-driven generation, retrieval, and compression together, sharing its training across what used to be separate embedding and generation tasks. It points at a future where the retriever and the generator aren’t even different things. And RICE-PO takes on what I think is the deepest unsolved problem here. When you have an agent that reasons, queries, reads, reasons again, and re-queries, you can measure whether the queries were good, but how do you assign credit to the reasoning steps in between, the latent thinking that shaped which queries got asked? RICE-PO turns the retrieval interactions themselves into localized learning signals for those hidden reasoning steps. It’s an opening move on the training problem that, frankly, the whole agentic-retrieval program is going to live or die on.

So let me pull the arc together, because that’s the point of reading these in sequence. We went from dense retrieval, similarity in vector space, to RAG, looking things up instead of memorizing them. Then HyDE slipped generation into the query, and the agentic loop papers, ReAct, IRCoT, FLARE, Self-RAG, Search-R1, MCTS-RAG, turned retrieval into a repeated action the model reasons its way through. Then BRIGHT proved that for a whole class of queries, similarity simply isn’t enough, and ReasonIR and the reasoning-intensive crowd built retrievers that think. And finally Rank1 and InteRank made it concrete and cheap: rerankers that spend test-time compute, reason explicitly about relevance, and explain themselves. That’s the through-line. Retrieval is becoming a reasoning problem, and reasoning costs compute, and the field is deciding that the compute is worth it.

I’ll leave you with the open problems, because that’s where the collection actually points. First, nobody yet routes test-time compute by how hard the query is. We spend reasoning uniformly, when we should detect when relevance is genuinely inferential and only pay the reasoning cost then. Second, credit assignment for the latent reasoning inside a retrieve-reason agent is barely solved; RICE-PO is a first step, not a finish. Third, almost all of this is English and text-only, while the queries that most need reasoning, code, mathematics, scientific literature, multimodal data, are exactly the ones we have the fewest trained retrievers and benchmarks for. Fourth, the boundary between retriever and generator is dissolving, and nobody has measured the real cost and latency tradeoffs of erasing it versus keeping a clean separate index. And fifth, these systems now produce a reasoning chain for every decision, and we mostly throw it away, instead of showing it to the user or feeding it forward as grounded evidence.

That’s the map. Dense retrieval got us here. Test-time compute is what’s taking us forward. And the most interesting question in retrieval right now isn’t how to embed better. It’s how much thinking a search is worth. Thanks for listening.

Welcome back to the agentic information retrieval reading path. This is episode two, and if episode one was the theory, this one is the field test. Last time we walked a single idea from its roots to its frontier: the bet that the best way to find the right document is not to embed harder but to think. We traced it from dense passage retrieval, where you turn a query into a vector and find its neighbors, through retrieval-augmented generation, where you bolt that index onto a language model, through HyDE, where the model hallucinates a fake answer and retrieves real documents near it. Then we watched retrieval stop being a thing you do once, up front, and become an action the model chooses in the middle of its reasoning: ReAct, IRCoT, FLARE, Self-RAG, Search-R1, MCTS-RAG. And we ended on the hard cases, the reasoning-intensive queries where surface similarity simply breaks, and on the rerankers that spend real test-time compute to judge relevance: BRIGHT as the yardstick, ReasonIR as the retriever that rewards thinking, Rank1 and InteRank as the rerankers that reason before they score. The through-line was simple to say and expensive to do. Retrieval is becoming a reasoning problem, and reasoning costs compute, and the field is deciding the compute is worth it.

That was the lab. Today we go to work. Because none of that thesis matters until it lands in a product that someone depends on, and the moment it lands, the domain pushes back. Each domain has its own physics. The thing that makes retrieval hard in a codebase is not the thing that makes it hard in a support queue, and neither is the thing that makes it hard for an agent that knows you personally. So the plan for the next forty-odd minutes is to take the advances from episode one and run them through three real worlds, in order. First, coding agents, which is the deepest movement, the place the most money and the most measurement are pointed right now. Then support and customer-service agents, where the cost of being confidently wrong is a refund or a lawsuit. And finally personal agents, where the retriever and the memory start to become the same thing. For each, I want the same three questions: what does this domain actually demand, what is genuinely new in the last year, and where does it break. Let’s start in the codebase, because that is where the thesis is being stress-tested hardest.

Here is the first thing to understand about code retrieval, and it is the load-bearing fact for everything that follows: code is not text with a different vocabulary. The CodeSearchNet benchmark named the core problem back in 2019, and it never went away. A developer’s query and the snippet that answers it often share almost no words. You search for “retry with backoff” and the function is called scheduleAttempt, with a loop and a sleep and an exponent, and the word “backoff” appears nowhere. Worse, code has an open vocabulary; programmers coin new identifiers endlessly, so the off-the-shelf text embedding chokes on the very tokens that matter most, the rare ones. And the meaning you actually want lives in structure that text retrieval throws away: who calls this function, where does this value come from, what breaks if I change this signature. That is data flow and control flow and the call graph, and a cosine distance between two vectors cannot see any of it. So from the very beginning, code retrieval has been a different animal. The lineage that tried to tame it ran from CodeBERT, the bimodal encoder trained on comment-and-code pairs, through GraphCodeBERT, which injected data flow and got the first clean win for structure over tokens, through CodeT5 and UniXcoder. That is the embedding lane. Hold it in mind, because it is exactly the lane that a surprising number of frontier coding tools just walked away from.

Let me tell you the most striking thing that happened in this space in the last year, because it cuts directly against the embedding-everything instinct. In May of 2025, Anthropic took vector search out of Claude Code. They removed the embedding pipeline, the local vector database, the chunking heuristics, all of it, and replaced it with grep. The agent gets filesystem tools, glob to match file patterns, grep to search contents, read to load a specific file, and it explores the codebase on demand, the way a human engineer would, opening things, reading them, searching again. The reason was not ideology. It was measurement. The engineers said, plainly, that agentic search outperformed the RAG version by a lot, and that the margin surprised them. And it was not one team’s quirk. Over the following months, Windsurf, Cline, Devin, and Sourcegraph’s Amp all dropped vector search for tool-driven search. Sourcegraph specifically retired Cody’s embeddings in favor of an adapted keyword index over their code graph, citing the operational pain of shipping a customer’s proprietary code off to an embedding service, the cost of maintaining a vector database, and the way embeddings scale badly past a hundred thousand repositories. And in February of 2026, a team at Amazon Science put a number on the intuition: across a battery of retrieval tasks, agentic keyword search hit over ninety percent of full RAG performance with no vector database at all.

Now, why would that be true? Why would letting a model drive ripgrep in a loop beat a carefully trained embedding index? This is where episode one pays off, because the answer is the agentic-loop thesis applied to code. The embedding index is frozen. It was computed at some point in the past, on some snapshot of the repo, with some chunking strategy, and it gives you a fixed similarity ranking no matter what the question is. The agent, by contrast, reasons. It reads the error message, forms a hypothesis, greps for a specific symbol, reads what it finds, realizes it’s in the wrong module, and greps again with a better term. That is ReAct in a codebase. Retrieval is an action it decides to take, conditioned on what it has figured out so far, against the live source rather than a stale vector. On a codebase that changes every single commit, a search that runs against ground truth and reasons its way to the answer beats a search that runs against a memorized approximation. The grep-in-a-loop crowd is not being lazy. They are spending test-time compute on navigation instead of paying it up front on indexing, and on code, where freshness is everything, that trade has been winning.

But here is where it gets genuinely interesting, because the field did not actually converge on grep. It split. While Anthropic and the agentic crowd were tearing out embeddings, Cursor went the other direction and doubled down. In November of 2025 they published their results from training their own code embedding model, and the headline is that semantic search improved their agent’s accuracy across every frontier model they tested, by an average of twelve and a half percent, ranging from six and a half up to over twenty-three percent depending on the model. And crucially, the gains were largest exactly where grep is weakest: in big codebases with inconsistent naming and legacy patterns, the places where the word you’d search for isn’t the word that’s actually in the code. The vocabulary-mismatch problem, the one CodeSearchNet named in 2019, is still there, and grep does not solve it. If the function is called scheduleAttempt and you search for “retry,” ripgrep returns nothing and the agent has to get lucky with its next guess. Semantic search returns it anyway. So Cursor’s bet is that you give the agent both, and let the embedding catch the cases where lexical search comes up empty.

And the way they trained that embedding model is itself a lovely instance of the episode-one thesis, so let me dwell on it. They used the agent’s own sessions as training data. When the agent works through a task, you can look back at the trace afterward and see what it eventually needed, what file it should have opened on turn two instead of turn nine. So they take those traces, hand them to a language model, and have it rank which content was actually helpful at each step. Then they train the embedding model to make its similarity scores agree with that LLM-generated ranking. That is the same move HyDE made, just relocated. The reasoning of a language model is being baked directly into the retriever. The embedding is no longer trained on a generic notion of “these two strings look similar.” It’s trained on a model’s judgment of “this is what a competent agent would have wanted here.” That is reasoning-intensive retrieval, in the precise sense episode one defined it, compiled down into a fast vector lookup. ReasonIR proved you could train a retriever to reason; Cursor is doing it in production, supervised by agent trajectories.

GitHub Copilot sits in roughly the same camp, and added its own wrinkle this year. Copilot’s coding agent uses semantic code search to find conceptually related code, so you can describe a login bug in plain English and it surfaces the authentication middleware without your knowing the file path. The interesting part is operational: in March of 2026, GitHub shipped pre-indexing, parallel context loading, and session-level caching that cut the agent’s initialization time roughly in half on typical enterprise codebases. That matters because it names a cost the academic papers mostly ignore. When your agent boots a fresh virtual machine, clones a giant repository, and has to build up its context before it can do anything useful, the indexing latency is a real tax on every single task. So one frontier of code retrieval right now is not “find the right file” at all, it’s “amortize the cost of being ready to find the right file” across thousands of agent runs against a repo that is also changing under you.

Step back and look at this disagreement squarely, because it is the most clarifying thing in the whole movement. You have two camps, both serious, both with numbers, reaching opposite conclusions. The agentic-grep camp says embeddings are a stale liability and a live model with search tools wins. The trained-embedding camp says grep can’t bridge the vocabulary gap and a retriever taught by agent traces wins. And the resolution, the thing almost everyone actually ships, is that they are both right and the answer is hybrid. There’s a nice line going around that the grep replacement for AI agents is three tools, not one: give the agent lexical search for exact symbols and rare identifiers, semantic search for intent and concepts, and structural or graph search for relationships, and let it choose per question. This is exactly the additive-ladder picture from the code-retrieval literature: lexical owns rare-token recall, dense embeddings own intent, graph methods own behavior, and no single mode suffices, so everyone ends up hybrid. The argument was never really grep versus vectors. It was about which tool is the default and which is the fallback, and the field is settling on: let the agent decide.

Now let me push into the part of code retrieval that I think is the most underrated, because it is where structure comes roaring back: localization. In an enterprise codebase, the hard problem is usually not generating the fix. It’s finding where the fix goes. The bug manifests in one file and the cause lives three import hops and a config file away, and flat similarity retrieval will never get you there, because the symptom and the cause don’t look alike. The reading path has a striking number on this. KGCompass, from 2025, builds a repository-aware knowledge graph linking issues and pull requests to the actual code, and then narrows a bug down to around twenty candidate functions. The number that should stop you is this: sixty-nine point seven percent of the bugs it correctly localized required multi-hop traversal of that graph to find. More than two thirds of real fix sites are not reachable by looking at what resembles the symptom. They’re reachable only by walking the structure, call edge by call edge. And it did this at about twenty cents a repair, hitting roughly forty-six percent on SWE-bench Lite. LocAgent makes the same case from a different angle: parse the codebase into a heterogeneous graph, do multi-hop reasoning over it, and you get ninety-two point seven percent file-level localization and a double-digit lift in issue resolution, about eighty-six percent cheaper with a fine-tuned thirty-two-billion-parameter model. The lesson generalizes. The agentic-grep crowd is right that a model with search tools beats a frozen index, but the model navigates faster and cheaper when the thing it’s navigating is a structured world rather than a flat pile of files.

That insight is now turning into benchmarks, which is how you know a field is getting serious, and two from 2026 are worth naming because they reframe the whole problem. The first is SWE-Explore, which isolates repository exploration as its own task. Forget writing the patch; just measure whether an agent, given an issue and a repo snapshot, can return a ranked list of the line-level code regions that matter, under a fixed budget. It spans eight hundred and forty-eight issues across ten programming languages and two hundred and three repositories, and the ground truth is clever: they distilled it from independent successful agent trajectories, keeping a region only when at least two separate runs that actually resolved the issue both touched it. That sidesteps the contamination problem that haunts code benchmarks. And the headline finding maps directly onto the camps we just discussed: agentic explorers form a clear tier above classical lexical and dense retrieval. File-level localization is basically a solved problem for modern methods. The remaining headroom is line-level precision and efficient ranking. Knowing the file is easy now; knowing the exact lines, cheaply, is the frontier.

And once you grant that agentic exploration beats the frozen index, a new cost shows up that the embedding world never had to pay: the agent wanders. Every grep that comes back empty, every file opened and discarded, every wrong hypothesis is real compute and real latency, spent on navigation rather than on the actual task. A 2026 field study put numbers on it by analyzing seven thousand and twelve Claude Code sessions, and the finding is that giving the agent a formal architecture descriptor, a compact map of how the codebase is laid out, cut navigation by thirty-three to forty-four percent, with a large effect size and a fifty-two percent drop in the variance of how many steps a task took. The variance number is the one that matters operationally, because unpredictable agents are hard to budget for. And there’s a counterintuitive design lesson buried in it: the best format for that map is the one that fails safely when the agent misreads it, not the one the language model says it prefers. Undirected exploration is a measurable tax, and the fix is to hand the agent a cheap structural prior before it starts thrashing. That is the same insight as the localization work, one level up: structure doesn’t just help you find the fix site, it stops the agent from getting lost on the way there.

The second benchmark goes even harder at the assumption that code retrieval is query-to-snippet matching, and it’s the one I’d point a skeptic to. CORE-Bench, also 2026, reframes retrieval for agentic coding as requirement-driven repository search. A real development request, “add rate limiting to the upload endpoint,” carries an enormous gap between the intent and the implementation, and the evidence you need is scattered, some in code, some in configuration, some in a dependency, some in the docs. It is never sitting in one tidy function. So they ground every query in a repository snapshot checked out to the commit right before the relevant pull request, score you on retrieving all the chunks an edit touches plus the surrounding context an agent would browse, and they do it at scale: six hundred and thirty-two repositories, nine point three eight million chunks at their hardest level. And here is the result that should reorder your priors. Embedding retrievers that look excellent on traditional code search collapse on the agentic levels. One strong open model, Qwen3-Embedding-8B, scores seventy-one point seven on the easy level and falls to twenty point three and thirty-four point four on the harder, agentic ones. In-domain fine-tuning on pull-request supervision helps at every difficulty, but recall still degrades as the corpus grows larger and denser. The takeaway is blunt: the code-search scores everyone has been quoting for years overstate how useful a retriever actually is to a working coding agent. We have been measuring the wrong thing, and the new benchmarks are built to stop us.

Now layer in enterprise scale, because that’s where my own day job lives, and scale doesn’t just make these problems bigger, it changes which problems exist. Google’s monorepo is something like two billion lines of code, nine million files, forty thousand commits a day. You cannot do a linear search at query time, and you cannot fully re-index per change. The real production systems are an escalation ladder: grep at the bottom, then a trigram index like Zoekt, then a semantic index like Kythe, then incremental build-integrated indexing like Glean, then cross-repository precise navigation like SCIP. And the single most important property at that scale is one the academic benchmarks almost never test: freshness. There’s a 2026 diagnostic in the reading path, from Weng and colleagues, that nails this. They ran a controlled experiment where they hid commit timestamps so the system would retrieve from stale context, and the result is that stale retrieval is actively net-negative. It injected obsolete API references in fifteen of seventeen samples in one condition, thirteen of seventeen in another, with double-digit-percentage-point drops in correctness. Serving stale context was worse than serving no context at all. That reframes retrieval as a two-variable problem. It’s not just “is this relevant,” it’s “is this still true.” A companion line of work, DocSync, names the same hazard in documentation: drift that is, in their words, functionally lethal yet passes the linter, where the code changed and the doc didn’t, and a retriever that faithfully serves the doc faithfully serves a lie. Temporal validity is its own retrieval dimension, and almost nobody outside industry is gating on it.

And then there is the kind of context that isn’t in the repository at all, which is, I think, the deepest enterprise problem in the whole movement. The reading path has a result that crystallizes it. A 2026 paper measured what happens when you give a coding agent a dedicated product-context retrieval system, separate from the code, that holds decisions, specs, the reasoning behind why something is the way it is. On decisions that were visible in the codebase, the agent was already at a hundred percent. On decisions that depended on product context, the tribal knowledge that lives in a person’s head or a Slack thread or a design doc, the agent scored between zero and thirty-three percent without that system, and forty-six to ninety-five percent with it. The “why” of a decision is never in the source. It’s in people. And it turns out that “why” is retrievable, if you build a separate substrate for it, and retrieving it measurably changes how the agent behaves. This is the part of code retrieval that has nothing to do with code, and it’s where I think the real enterprise value is going to accrue, because every company’s hardest context is the context it never wrote down as code.

There’s a tempting shortcut lurking under all of this that I should address head-on, because the long-context crowd keeps proposing it: if the models can read a million tokens now, why retrieve at all? Just dump the whole repository into the context window and let the model sort it out. The reading path has the receipts on why that doesn’t work, and they’re worth carrying into the other domains too. The first is RepoQA, which runs a searching-needle-function task over long code context across fifty repositories and five languages, and its lesson is that capacity is not comprehension. Models that can technically ingest the whole repo still fail to find and use the one function that matters, and in a result that should give the dump-everything camp pause, they often understood the code better with the comments stripped out, which is the opposite of what more context is supposed to buy you. The second is MutaGReP, which shows the other side: a grounded plan that uses less than five percent of a hundred-and-twenty-eight-thousand-token window can rival GPT-4o working with the full repository in context. Retrieving a small, structured, relevant slice beats stuffing the window, on both cost and quality. The genuinely open question is where the crossover sits, at what repository size and task type the full-context dump finally wins, and nobody has mapped that curve. But the default assumption that bigger context windows make retrieval obsolete is, on the evidence, backwards.

There’s one more enterprise wrinkle I can’t skip, because it’s the thinnest topic academically and the one that bites hardest in practice: access control. In a big company, “find all references to this function” is not a neutral search. If it returns code the person asking isn’t allowed to read, that’s a data leak, full stop. And almost all the academic retrieval work treats permission as a post-hoc filter you slap on after ranking, which is both slow and wrong, because the ranking itself can leak information about what exists. A survey of eight hundred and sixty Microsoft developers this year found that what they actually want is what the authors call bounded delegation: agents that operate with explicitly scoped authority, with provenance on every answer, with a clear sense of their own uncertainty, and with least-privilege access by default. That’s a design language for retrieval, not a feature request. Permission has to be a first-class retrieval input, baked into what the index will even consider, and the field has barely started. So that’s the coding movement: the embedding-versus-grep war that resolved into hybrid, structure and graphs winning at localization, new benchmarks proving the old scores lied, and freshness, tribal knowledge, and permission as the enterprise problems that change the game. Hold the freshness-and-permission theme especially, because it comes straight back in the next two domains.

Let’s change worlds. Support and customer-service agents. On the surface this looks like the easy case, the one RAG was born for: you have a knowledge base of help articles, a history of resolved tickets, a user asks a question, you retrieve the right article and ground your answer in it. And in fact this is the most deployed form of agentic retrieval on earth right now. The current numbers are real and worth saying out loud: a well-built RAG support deployment deflects something like forty to fifty percent of routine tickets, with the 2026 enterprise median around forty-one percent and the top quartile reaching nearly fifty-nine percent. Deflection is the word for a ticket the AI handled so the human never had to, and at the volume of a large support organization, a forty-percent deflection rate is an enormous amount of money. So this domain has the clearest business case of the three. But the apparent simplicity is a trap, and the ways it’s a trap are exactly the ways episode one’s thesis matters here too.

The first hard thing is that the cost of being wrong is asymmetric and high. In a coding agent, a bad retrieval wastes a few tokens and the agent recovers on the next loop. In support, a confidently wrong answer goes to a customer, and it can mean a botched refund, a security misstep, a regulatory violation, a screenshot on social media. So this domain is far less tolerant of hallucination than consumer chat, and that intolerance is structural, not a nice-to-have. It’s why grounding and citation are not garnish here, they’re the product. The discipline that’s emerged is that every answer must be traceable to a specific retrieved source, and increasingly the answer carries the citation back to the article it came from, both so the customer can verify it and so the company has an audit trail when something goes wrong. This is the most successful real-world deployment of one of episode one’s open problems. Remember the last open question I left you with: that test-time-compute systems produce a reasoning chain or an evidence trail for every decision, and we mostly throw it away. Support is the one domain that learned not to throw it away, because the regulator and the angry customer both demand to see the receipt.

The second hard thing is freshness, and notice it’s the same villain as in code. A support knowledge base is a living thing. The refund policy changed last week, the product shipped a new version yesterday, the workaround for that bug is now obsolete because the bug is fixed. If your retriever faithfully serves the old article, it faithfully gives the wrong answer with full confidence and a citation, which is worse than a hedge. The 2026 practitioner consensus is blunt that hallucinations scale with article volume, and that the failure mode isn’t the model making things up out of nothing, it’s the model grounding perfectly on a stale or low-quality document. Garbage knowledge base, confident garbage answer. This is the support-domain version of the Weng staleness result. The retrieval problem is not “find a relevant article,” it’s “find a relevant article that is still true,” and the second clause is the hard one, because relevance is a property of the query-document pair and truth is a property of the world, and embeddings only know about the first.

The third hard thing, and this is where reasoning-intensive retrieval genuinely earns its place, is that real support conversations are multi-turn, and retrieval over a conversation is a different beast than retrieval over a single query. There’s a benchmark that makes this concrete, mtRAG, a multi-turn conversational RAG benchmark with a hundred and ten human-written conversations averaging almost eight turns each across four domains, more than eight hundred tasks total. And what it forces systems to handle is the stuff that breaks naive RAG: questions that only make sense in the context of earlier turns, what they call non-standalone questions, where “does that work on the enterprise plan too?” has no retrievable meaning without the previous three turns; questions that are genuinely unanswerable, where the right move is to say so rather than to retrieve the nearest-looking thing and bluff; and the requirement that the answer be faithful not just to the retrieved passages but to what was already said in the conversation. That “does that work on the enterprise plan too” example is the whole problem in one line. You cannot embed that query and search, because on its own it’s nearly contentless. You have to reason over the conversation to reconstruct what “that” refers to, rewrite it into a standalone query, and then retrieve. That’s HyDE-style query reformulation and IRCoT-style reasoning-before-retrieval, applied to a dialogue. The query is, again, no longer a static string. It’s the product of the model thinking about the conversation so far. Episode one told us retrieval was becoming a reasoning problem; multi-turn support is where ordinary companies are paying for that reasoning whether they call it that or not.

The fourth hard thing is the decision that wraps all of this: deflect or escalate. The single most important judgment a support agent makes is not what to answer, it’s whether it should answer at all, or hand off to a human. And this is precisely the FLARE and Self-RAG move from episode one, relocated into a business workflow with real stakes. FLARE had the model watch its own confidence and retrieve when it was uncertain; Self-RAG trained the model to critique whether its retrieved passages actually supported the claim. In support, that self-assessment becomes the escalation gate: if the retrieved evidence is thin, if the confidence is low, if the question is in a high-risk category, the right behavior is to escalate to a human, with the full conversation context carried along so the customer doesn’t have to repeat themselves. The practitioners have a sharp warning here that the deflection number alone hides: high demand plus low confidence in the underlying content is exactly where deflection quietly fails, and a deflection rate above eighty percent should make you suspicious rather than proud, because it usually means the system is answering things it should have escalated. So the mature support agent is running a self-critique loop on its own retrieval and treating “I don’t have grounded evidence for this” as a first-class, valuable output, not a failure. That is retrieval control and self-criticism, the Self-RAG idea, turned into a customer-safety mechanism.

Notice the symmetry with the coding world. There, retrieval failure is cheap and recoverable, so the agent can afford to explore aggressively and grep its way around. Here, retrieval failure is expensive and customer-facing, so the agent has to be conservative, has to ground every claim, has to know when to stop and call a human. Same underlying machinery, retrieve, reason, critique, decide, but the domain’s cost structure flips the disposition from bold to careful. And the enterprise themes carry straight over from the coding section: permission-aware retrieval matters just as much here, because a support agent pulling from internal systems must respect what this customer, and this agent, are allowed to see; and Glean-style enterprise search is essentially the support problem generalized across every internal tool, indexing files, tickets, messages, code, and docs across a hundred-plus applications, with permission-aware access and source citations as non-negotiable, because, as the vendors put it, a knowledge tool that surfaces the wrong file creates legal and cultural risk. Support and internal enterprise search are the same animal: grounded, cited, permissioned retrieval where being confidently wrong is the thing you’re most afraid of.

Now to the third world, and the one I find most conceptually slippery, because here the boundary we’ve been relying on, the line between the retriever and everything else, starts to dissolve. Personal agents. An agent that knows you. Your calendar, your email, your past conversations with it, your preferences, the project you’ve been grinding on for three weeks. The promise is an assistant that doesn’t make you re-explain your life every morning. And the moment you try to build it, you discover that “retrieval” and “memory” have become the same problem wearing two different names.

Consider what that means, and it connects directly to the agentic-memory reading path some of you have followed. When a support agent retrieves an article, the corpus is external, shared, and the same for everyone. When a personal agent retrieves a fact about you, the corpus is you: your history, private, unique, and constantly growing as you keep talking to it. Retrieval over that corpus is what the memory field calls, well, memory. The mechanism is identical, find the relevant items and pull them into the context window, but the framing flips. The 2026 state of the art on agent memory says the field is moving beyond pure vector similarity, and the way it retrieves a relevant memory now combines semantic similarity, keyword matching, and entity matching before injecting it into context. Read that list. That is exactly the hybrid retrieval stack we just spent the coding movement building: dense for meaning, lexical for exact terms, structural for entities. The personal-agent memory community and the code-retrieval community independently walked to the same hybrid conclusion, from opposite ends, which is a strong signal that the hybrid answer is real and not a fashion.

What makes personal retrieval genuinely different from the other two domains is a set of constraints that don’t apply when the corpus is a codebase or a help center. The first is privacy, and it’s not a checkbox, it reshapes the architecture. When the corpus is your private life, you can’t casually ship it to a cloud embedding API. So a real strand of 2026 work is on-device retrieval: running the whole embedding pipeline locally, with tools like FastEmbed, so the data never leaves the machine, and local-first agents that keep memory in on-device modules off external servers entirely. That’s a hard engineering constraint that the coding and support worlds mostly don’t face, and it pushes personal retrieval toward small, efficient, local models, which connects right back to episode one’s InteRank result: a three-billion-parameter reranker that reasons and explains itself and beats models twenty times its size. The reason that result matters so much for personal agents is that on-device is the regime where you cannot run a giant model, so a small retriever that still reasons isn’t a nice-to-have, it’s the whole ballgame. The test-time-compute-survives-distillation finding from episode one is the enabling technology for private, personal, reasoning retrieval.

The second difference is that the corpus is adversarially dynamic in a way that the others aren’t, and it raises the freshness problem to a new level. Your preferences contradict themselves over time. You liked terse answers last month; this week you’re learning something new and you want detail. You moved cities. You changed jobs. A personal memory store accumulates statements that were true when written and are false now, and unlike a support knowledge base, nobody is editing it for correctness. So personal retrieval has to do something support retrieval mostly punts on: reconcile conflicting memories and weight recency against importance. This is where you see the agentic-memory field reaching past storage and past simple reflection toward what that literature calls the experience stage, abstracting across many episodes into a stable model of the user rather than just retrieving the nearest past statement. The retrieval question isn’t “what did the user say that’s similar to this,” it’s “what is true about the user now, given everything they’ve said,” and those are very different queries. The first is a lookup. The second is an inference. Which is to say, the personal-agent retrieval problem is reasoning-intensive in exactly episode one’s sense: the relevant memory and the current query may share no surface features at all, and the connection between them runs through a chain of inference about who this person has become.

The most visible move in this space landed in January of 2026, when Google wired persistent personalization into Gemini across its whole stack, so the assistant can reference your Gmail, Calendar, Drive, Photos, Search, Maps, and YouTube history to personalize what it tells you. Set aside whether you want that, and look at it as a retrieval system: it is cross-source personal retrieval at consumer scale, pulling from seven or eight private corpora at once and fusing them into one context. That is the personal-agent thesis shipped to a billion people, and it makes the open problems urgent rather than academic. Because the contrary view in the reporting kept raising one thing: persistent memory introduces layers of latent representation, embeddings, inferred summaries, weighted retrievals, that determine what the agent tells you while remaining completely invisible to you. You can’t see why it retrieved what it retrieved, you can’t easily inspect what it thinks it knows about you, and the questions of who can read your stored memories, how long they’re kept, and how you delete them are, as of now, only half-answered. The reasoning chain that episode one said we throw away, in the personal domain, isn’t just a wasted artifact. It’s the thing that would let you understand and contest what an agent has decided about you, and right now it’s hidden.

So let me line the three worlds up against each other, because the comparison is the payoff. In all three, the episode-one machinery is the same: hybrid retrieval that fuses lexical, dense, and structural signal; retrieval as a reasoned action in a loop, not a fixed up-front step; query reformulation that injects the model’s reasoning into the search; and a self-critique gate that decides whether the retrieved evidence is good enough to act on. What changes from world to world is the physics. In coding, the dominant constraint is freshness and scale, the corpus changes every commit and runs to billions of lines, so the field tore out frozen embeddings in favor of agents that search live source, and structure won at localization. In support, the dominant constraint is the cost of being wrong, so grounding and citation and the deflect-versus-escalate decision became the whole game, and the reasoning trail got preserved as a safety receipt. In personal agents, the dominant constraint is privacy and the shifting self, so retrieval went on-device and small, and the retriever-memory boundary dissolved into a single inference problem about who you are now. Same thesis, three different masters.

Which brings us, as it should, to the open problems, because that’s where the reading path actually points, and the satisfying thing is that the cross-cutting questions from episode one show up sharper, not blurrier, once you’ve seen them land in real domains. Let me name five.

The first is routing test-time compute by query difficulty, and every domain we covered is bleeding from this wound. Right now, reasoning is spent uniformly. A coding agent reasons just as hard about “where is the config file” as about “why does this distributed lock deadlock under load.” A support agent runs the same retrieval pipeline for “what are your hours” as for a multi-turn regulatory question. A personal agent reasons the same about “what’s on my calendar” as about reconciling years of contradictory preferences. But most queries, in every domain, are easy, and the expensive reasoning is wasted on them. What’s missing is a controller that detects when relevance is genuinely inferential, when the question actually needs the chain of reasoning, and only then pays for it. Rank1 and ReasonIR proved reasoning lifts retrieval; nobody has built the dispatcher that decides which queries deserve it. Build that, and test-time-compute retrieval goes from a luxury to something you can afford at the scale of a support queue or a monorepo. This is, I think, the single most economically important open problem in the entire field.

The second is that reasoning-intensive retrieval is still mostly English and text, and the domains that most need reasoning are exactly the ones with the fewest trained retrievers and the weakest benchmarks. Code is the leading edge of fixing this, which is why the coding movement was the deepest today, but look at what 2026 actually had to do to get there: CORE-Bench and SWE-Explore had to be built from scratch because the old code-search scores were measuring the wrong thing, and even now they show retrievers collapsing on the genuinely agentic tasks. Math, scientific literature, multimodal data, the GUI-bug work like GALA that grounds a screenshot against a call graph, these are barely benchmarked. The reasoning-intensive retrieval frontier beyond English text is wide open, and code is the proof that closing it requires not just better retrievers but new benchmarks built to resist contamination, because the old ones lie.

The third is the dissolving boundary between retriever and generator, and the personal-agent world made it visceral. Episode one pointed at GRC and RankRAG, one model that retrieves, ranks, and writes. The personal domain shows why that’s not just an efficiency play: when the corpus is you and the memory is the retrieval is the context, the clean separation of index, retriever, reranker, generator stops describing anything real. But, and this is the open part, nobody has measured the actual tradeoffs. What does it cost in latency, in quality, in your ability to audit and to enforce permissions, to collapse the boundary versus keeping a clean separate index you can inspect, secure, and update? In the personal domain especially, a separate, inspectable memory store might be exactly what privacy and user control demand, even if a fused model would be faster. The boundary may be worth keeping for reasons that have nothing to do with performance, and that’s a question nobody has answered with numbers.

The fourth is the reasoning chain as a first-class evidence surface, and across the three domains you can watch it go from wasted to load-bearing. A test-time-compute reranker produces an explicit relevance rationale for every result, and episode one’s complaint was that we discard it. Support has started not discarding it, because the citation and the evidence trail are the product. Personal agents desperately need not to discard it, because the hidden rationale is exactly what would let you understand and contest what the agent believes about you. And coding agents could use it to explain why they navigated where they did, which the architecture-descriptor and exploration work suggests would cut wasted navigation dramatically. The rationale is generated, for free, by every reasoning retriever. Exposing it to the user, and feeding it forward to the downstream model as grounded evidence rather than throwing it in the trash, is a near-free win that almost no system takes.

And the fifth, the one I’ll leave you on, is the deepest and the least solved: credit assignment for the reasoning that shapes retrieval. When an agent reasons, queries, reads, reasons again, and re-queries, you can measure whether the executable actions, the actual searches, were good. But the latent reasoning steps in between, the thinking that decided which query to ask, are what actually determine whether the retrieval succeeds, and they’re nearly impossible to train, because only the actions are directly rewardable, not the thoughts behind them. Episode one named RICE-PO as an opening move, turning retrieval interactions themselves into localized learning signals for those hidden reasoning steps. And every domain today is full of agents whose retrieval quality is bottlenecked precisely there. The coding agent that greps the wrong term first, the support agent that rewrites a multi-turn query badly, the personal agent that retrieves a stale preference, all of them are failing in the reasoning that precedes the search, and we don’t yet know how to teach that reasoning directly. The whole agentic-retrieval program, in coding, in support, in personal agents, is going to live or die on whether we crack it.

So pull it all together. Episode one gave us the thesis: retrieval is becoming a reasoning problem, and the field is paying the compute. Episode two put that thesis to work, and the lesson is that the thesis survives contact with reality, but every domain bends it. Coding tore out frozen embeddings for live agentic search, then discovered structure and hybrid retrieval winning underneath, and built new benchmarks because the old numbers were a mirage. Support turned retrieve-reason-critique into a grounded, cited, escalation-aware safety system where the reasoning trail finally got kept. Personal agents collapsed retrieval and memory into one private, on-device, reasoning-intensive problem about who you are now. And the open questions didn’t dissolve under contact with the real world. They sharpened. The most interesting question in retrieval still isn’t how to embed better. It’s how much thinking a search is worth, and now we get to ask it three times over, once for the codebase, once for the customer, and once for the person. Thanks for listening. I’ll see you on the next one.

The agentic memory reading path, one of five. In 2023, a group of researchers at Princeton noticed that the field of language agents had a vocabulary problem.

Everyone was building agents. Nobody agreed on what the parts were called. One team’s memory was another team’s context, was a third team’s scratch pad. So they did something unfashionable in a field obsessed with the next benchmark. They stopped and they drew a map. That map is where this series begins.

Welcome to a five-part deep dive on agentic memory, following a reading path that runs from the founding taxonomy through the systems people actually deploy into procedural skills, the measurement crisis, and finally forgetting.

This is episode one, Foundations. How we learn to talk about memory, why the field keeps splitting into camps, and what it even means to evaluate an agent that remembers. A quick orientation, because the shape of this series matters.

We are walking… We are walking a curated reading path through the agentic memory literature, 13 papers in six stages, cross-checked against the primary sources and against what is actually shipping in industry right now.

Today, Foundations, we lean on three works. The CoALA Taxonomy from 2023, a 2026 survey called From Storage to Experience, and a 2025 survey on how we evaluate agents at all. Three papers, one job, give you the scaffolding so the rest of the series has somewhere to hang. And here is the thing to hold onto from the start.

Memory is not a feature you bolt onto an agent. It is the thing that turns a stateless text generator into something that accumulates. A model without memory answers each question as if it were the first.

A model with memory has a past, and a past is what makes planning, personalization, and learning possible. The whole field is an argument about how to give an agent a past it can actually use.

Let us start with the math. The founding document for this series is a 2023 paper by Theodore Sumers, Shunyu Yao, Karthik Narasimhan, and Thomas Griffiths titled Cognitive Architectures for Language Agents. CoALA, for short. It has accumulated something like 160 citations, which in this field is a landmark, and its move is clever. Instead of inventing a new framework from scratch, the authors reached back into the history of cognitive science and symbolic artificial intelligence, the production systems, and cognitive architectures of the 1980s and 90s, and they used that older, richer tradition to organize the chaos of modern language agents. CoALA describes any language agent with three pieces. First, modular memory components.

Second, a structured action space, split into internal actions that operate on the agent’s own memory and external actions that operate on the world. And third, a generalized decision-making procedure, a loophole, a loop that chooses which action to take next.

That sounds simple. The power is in the memory decomposition, because this is where the vocabulary of the whole field comes from.

CoALA borrows the classic cognitive science split, working memory, the live information for the current decision, what is in the context window right now. Episodic memory, the agent’s record of specific past experiences, what happened, when, in what order.

Semantic memory, general knowledge and facts, decoupled from any single episode. And procedural memory, the skills and routines the agent knows how to execute, including, in a nice twist, the agent’s own code and prompts. Those four categories, working, episodic, semantic, procedural, are the words you will hear in every paper in this series.

When a vendor tells you their product has episodic and semantic memory, they are speaking CoALA, whether they cite it or not. It is worth dwelling on working memory specifically, because it is the hub every time you use CoALA. In CoALA’s framing, working memory is the central exchange. The decision procedure reads from it, the long-term stores write into it, and get read back through it, and the action space operates on it. Episodic, semantic, and procedural memory are the long-term stores. Working memory is the desk where the agent actually does its thinking. That distinction, a small live workspace versus large, persistent archives, is the same one that operating memory actually does its thinking. That distinction is what operating systems make between RAM and disk, and it is no accident that one whole culture in this field, the one we’ll meet in the next segment, thinks about memory in exactly those operating system terms. The second half of CoALA is just as important and gets cited less, the structured action space and the decision procedure. CoALA splits an agent’s actions into two kinds. Internal actions operate on memory, retrieval, which reads from long-term stores into working memory, reasoning, which processes what’s in working memory and writes results back, and learning, which writes new content into the long-term stores. External actions operate on the world, calling tools, hitting APIs, moving in an environment, and wrapping all of it is a generalized decision-making loop that each cycle chooses the next action, internal or external. Why does this matter for memory? Because it tells you memory is not a passive database the agent occasionally queries. Reading and writing memory is one of the most obvious actions the agent decides to take on the same footing as calling a tool. The agent has to learn when to remember and when to retrieve, not just how. That reframing memory operations as deliberate actions is the seed of the agentic memory idea we’ll see become a whole research direction in episode 2. The choice to reach back into symbolic AI was not nostalgia, and it’s worth understanding why. In the 1980s and 90s, there were many new architectures, systems like SOAR and ACT-R that tried to model general intelligence as an explicit machine, a long-term memory of production rules, a working memory of current state, and a cycle that matched rules against state and fired the best one. Those systems were brittle and hand-built, and the deep learning wave largely swept them aside. But they had spent decades thinking rigorously about exactly the questions language agents are now rediscovering. How do you analyze different kinds of memory? How do you decide what to do next? How does new knowledge get written down? CoALA’s insight was that language models had quietly solved the part the old systems were worst at while reintroducing the parts the old systems had carefully worked out in an ad hoc, reinvented-every-paper form. So the move is take the hard-won structure of cognitive architectures and drop a language model in the old skeleton, the new muscle. What CoALA gave the field was a shared coordinate system. You could now look at any agent and ask precise questions. Where does this system keep episodic traces? How does it move something from working memory into long-term semantic memory? What are the internal actions that read and write each store? The paper used its own framework to survey the existing work and the grid, the things nobody had built yet. That is what a good taxonomy does. It does not just describe, it reveals the gaps. A taxonomy tells you the parts. It does not tell you the story of how the field is moving. For that, jump forward to 2026 and a survey by Jinghao Luo and colleagues with a title that is itself a thesis, From Storage to Experience A Survey on the Evolution of LLM Agent Memory Mechanisms. This is a survey translating between two cultures that barely talk to each other. One culture treats memory as an operating systems problem. Paging, caching, eviction, context windows as RAM, external stores as disk. This is the MemGPT lineage, memory as systems engineering. The other culture treats memory as a cognitive science problem. Consolidation, forgetting curves, the hippocampus, how human remembering actually works. Because each camp keeps reinventing the other’s ideas under different names. So they propose a single evolutionary arc. Three stages. And it is genuinely useful for thinking about where any given system sits. Stage one is storage. Trajectory preservation. You just keep the record of what happened. Raw logs, full transcripts, the agent’s history written down somewhere it can be retrieved. Stage two is reflection. Trajectory refinement. The agent does not just store the raw trace, processes it, summarizes it, extracts what mattered, critiques its own past behavior. Stage three, the frontier, is experience. Trajectory abstraction. The agent generalizes across many past trajectories into reusable, transferable knowledge that changes how it acts in genuinely new situations. Storage to reflection to experience. And the survey names three forces driving systems up that ladder. The need for long-range consistency so the agent does not contradict itself across a long interaction. The challenge of dynamic environments where the world changes and yesterday’s fact is today’s error. And the ultimate goal of continual learning, an agent that actually gets better the longer it runs, rather than just accumulating a bigger pile of logs. Make each stage concrete because the difference is easy to blur. Stage one, storage, is a chatbot that saves your past conversations and can quote them back. The information is preserved, and the data is shared. Stage two, reflection, is an agent that, after a session, writes itself a note. The user prefers terse answers and dislikes when I over-explain, distilling the raw trace into something more useful than the trace itself. Stage three, experience, is an agent that, having handled fifty support tickets, induces a general procedure for a whole class of problem and applies it to a ticket unlike any it has seen. The survey singles out two mechanisms as the frontier of that experience stage, and they’re worth naming because they recur through this series. The first is proactive exploration, an agent that doesn’t just passively record what happens to it, but deliberately seeks out experiences that will make its memory more useful, the way Voyager, which we’ll meet in episode three, sets its own curriculum. The second is cross-trajectory abstraction, pulling a reusable pattern out of many separate episodes, rather than readapting a single remembered episode each time. That second one is subtle, and it is the crux of the hardest debates in the field because, as we’ll see in episode three, abstracting across trajectories is exactly where systems both gain the most and lose the most. What I like about this framing is that it gives you a diagnostic. Most production systems today are honestly still at stage one or stage two. Maybe they reflect. The experience stage, real cross-trajectory abstraction, is where the research excitement is and where the hard, unsolved problems live. When you hear a vendor claim their agent learns from experience, the useful question is, which stage are you actually at? Are you abstracting across trajectories or are you just keeping good logs and calling it learning? Here is the uncomfortable third leg of the foundations. This is a revolutionary story and I still have no idea whether any of it works because evaluation is genuinely hard. The third paper on our reading path is the 2025 Survey on Evaluation of LLM-Based Agents by Asaf Yehudai and colleagues, the first comprehensive survey of how the field measures agents at all. They organize agent evaluation along four dimensions. First, fundamental capabilities. Planning, tool use, self-reflection, and crucially for us, we need to know what is the best way to evaluate an agent. Second, application-specific benchmarks for web agents, software engineering agents, scientific agents, conversational agents. Third, benchmarks for generalist agents that have to do a bit of everything. And fourth, the frameworks and tooling for running evaluations in the first place. And their read on where evaluation is heading is one of the most important threads in this whole series. So let me state it plainly. The trend is toward more realistic, updated benchmarks, and away from the static, single-number leaderboard. Why continuously updated? Because static benchmarks rot. They leak into training data, they saturate, and a frozen benchmark slowly stops measuring capability and starts measuring contamination. We will see exactly this happen to the dominant memory benchmark in a later episode. Ground those four dimensions under application-specific, web agents are measured on WebArena and Mind2Web, which we’ll dig into in episode 3, software engineering agents on SWE-bench, where the oracle is whether the code actually passes the tests, conversational and memory agents on LoCoMo and LongMemEval, which become central in episodes 2 and 4. Under fundamental capabilities sits memory itself, and the survey’s point is that memory is consistently the under-evaluated leg in tool use, precisely because it’s the hardest to isolate. You can check whether a tool call succeeded. Checking whether the agent remembered the right thing for the right reason at the right time is genuinely harder. The survey is also blunt about the gaps, and the gaps are telling. The field undermeasures cost efficiency. It’s not just about the benchmark’s tidy setup, and it lacks fine-grained, scalable evaluation methods. The ability to say not just did the agent get the right answer, but where in its reasoning did it go wrong. That last gap, fine-grained failure attribution, is the seed of the entire measurement crisis we will spend a full episode on. For now, just plant the flag. It provides more than it reveals. Now step back and look at the meta-signal, because it tells you something about the moment we are in. In just the last few months, the research community has produced a small flood of agent memory survey papers. From storage to experience, which we just covered. Another titled, Memory in the Age of AI Agents, a sprawling multi-author effort. Another, Memory for Autonomous LLM Agents, more are landing on the pre-print servers every few weeks. When a field produces multiple large surveys in a single quarter, that is not a coincidence. It is the field reaching a level of fragmentation where no single researcher can hold it in their head anymore, and several teams independently decide the most valuable thing they can do is impose order. The surveys themselves say this out loud. They describe a field where the same words mean different things, where every system invents its own evaluation protocol. Where results cannot be compared across papers because nothing is held constant. Make the fragmentation concrete, because it is not abstract hand-wringing. Take the word memory across three systems we’ll meet next episode. In Zep, memory is a temporal knowledge graph with typed entities and time-stamped edges. In A-MEM, memory is a self-organizing web of notes that rewrite each other. In Mem0, memory is a complex log of facts optimized to minimize tokens. Same word. Three incompatible data models, three different retrieval strategies, three different evaluation setups, and no way to move your data from one to another. Or take evaluation. One paper scores whether the final answer was right, another scores whether the correct memory was retrieved, a third scores both and finds they disagree. When the surveys say the field is fragmented, this is what they mean. Not that there are many ideas, in identical vocabulary while being fundamentally different underneath, which makes honest comparison nearly impossible. This is the central tension of the foundations, and it will echo through every remaining episode. The conceptual vocabulary converged early, thanks to CoALA, but the implementations diverged wildly. We agreed on the words episodic, semantic, procedural, retrieval, consolidation, and then everyone built something different underneath those words. So you get the strange situation where two products both claim long-term memory with knowledge graphs and share almost no actual design decisions. For anyone building on this stuff, the practical takeaway from the foundations is to start from a survey taxonomy before you pick a tool. The CoALA grid and the storage reflection experience ladder are not academic decoration.

They are the cheapest way to make the design space legible before you commit to a vendor whose vocabulary is hiding a very specific, very opinionated set of choices. Pick the abstraction first, then go shopping.

Before we tally up what the foundations settle, sit with the strangest recurring feature of this field, its obsession with the human brain. CoALA reached back to cognitive architectures from the 1980s. The storage-to-experience survey keeps invoking consolidation and the hippocampus. And as we’ll see in the final episode, the 2026 forgetting literature is a full-on neuroscience gold rush. Why does a field built on transformers keep reaching for neuroscience? The honest answer is that human memory is the only existence proof we have. It is the one system, anywhere, that remembers across a lifetime, forgets gracefully without catastrophic loss, generalizes from a handful of examples, stays coherent for decades, and runs on a power budget of more than $1 billion. The CoALA grid is the only system that remembers across a lifetime, and runs on a power budget smaller than a light bulb.

Every architecture in this series is, at bottom, a wager about which features of human memory are worth copying, and which are accidents of wet biology you should ignore. The features the field has bet on copying are clear. The multi-store model, the idea that short-term working memory and several distinct long-term stores are different systems with different dynamics, that’s the CoALA split. And it traces straight back to the Atkinson-Shiffrin model from 1990. Consolidation. The idea that memories are not written once, but reprocessed and stabilized over time, often offline. That’s the inspiration behind the reflection stage, and the sleep mechanisms we’ll meet later. And the episodic semantic distinction between remembering a specific event and knowing a general fact comes from the psychologist Endel Tulving in the 1970s, and it is now load-bearing in production systems like Zep.

But there’s a real risk. And the careful papers flag it. The brain is not a transformer. Borrowing a mechanism because it sounds biologically plausible is not the same as showing it works. And a beautiful neuroscience metaphor can paper over the absence of an actual measured result. This tension, biological inspiration racing ahead of engineering evidence, is going to be the central drama of the final episode. For now, hold both halves. The cognitive science framing is genuinely general. It has produced most of the field’s best ideas, and it is also where a lot of hand-waving hides.

The job, across this whole series, is to keep asking which biological metaphor actually earns its keep with a number behind it. So what do we actually know, standing on the foundations, before we go deeper? We know the parts. Working, episodic, semantic, procedural memory, plus the internal and external actions that read and write them, plus a decision loop. That is CoALA.

That is the lingua franca. We know the trajectory. Systems evolve from storing raw experience to reflecting on it, to abstracting it into transferable knowledge. That is the storage to experience arc. And most of what ships today is still climbing the first two rungs.

We know the central anxiety. Evaluation is immature, single numbers mislead, benchmarks rot, and the field cannot yet attribute failures to the right stage of the memory pipeline. And we know the meta-fact. The field is fragmented enough that imposing order has become a research contribution in its own right. Notice what is not settled. Nobody has agreed on the right data structure for memory. That fight is the next episode. Nobody has agreed on how to evaluate procedural skill reuse. That is two episodes away. And the entire question of forgetting, of when an agent should let go of a memory, is so underdeveloped that it gets the final episode mostly to itself. The foundations give us the map. They do not give us the data. The field is fragmented enough that imposing order is not a good idea. We know the central anxiety. Evaluation is immature, single numbers mislead, benchmarks rot, and the field cannot yet attribute failures to the right stage of the memory pipeline. And we know the central anxiety. The field is fragmented enough that imposing order is not the only one. Nobody has agreed on how to evaluate procedural skill reuse. That is two episodes away. And the entire question of forgetting, of when an agent should let go of a memory pipeline. That is two episodes away. And the entire question of forgetting, of when an agent should let go of a memory pipeline. And the entire question of forgetting, of when an agent should let go of a memory pipeline. The reason cognitive science keeps showing up here, the reason CoALA reached back to the 80s, and the storage to experience survey keeps invoking the hippocampus, is that human memory is the one existence proof we have of a system that remembers across a lifetime, forgets gracefully, generalizes from a handful of examples, and stays coherent for decades. Every architecture in this series is, in some sense, a hypothesis about which parts of human memory are worth copying and which are accidents of biology. Keep that question live. It is the through line under all the engineering. That is the foundation. CoALA gave us the vocabulary. From storage to experience, gave us the trajectory. The evaluation survey gave us the central anxiety. And the wave of new surveys tells us the field knows it has outgrown its own coherence. Next episode, we get concrete. We open up three real systems that people actually deploy, Zep with its temporal knowledge graph, A-MEM with its self-organizing notes, and Mem0 with its production focus. And we look at the build versus buy decision and the vendor landscape that formed around them. We go from the map to to the machines. I will see you there.

The agentic memory reading path, 2 of 5. Here is a number that should make you suspicious.

On the benchmark that the MemGPT team built to prove their memory system worked, a plain, dumb baseline, just stuffing the entire conversation into the context window, scored 94.4%. The fancy memory system scored 94.8. Four-tenths of a point, for all that machinery. That number is not an embarrassment. It is a clue. It tells you that the benchmark was too easy, that the real problem lives somewhere the benchmark wasn’t looking, and that to build memory that earns its keep, you have to be ruthless about what you are actually measuring. This episode is about the systems people deploy to give agents a memory,

the three architectures on our reading path, and the industry that has grown up around them. Welcome back to the agentic memory deep dive. This is episode 2, the memory stack. Last episode, we built the scaffolding, the CoALA vocabulary, the storage-to-experience arc, the evaluation anxiety.

Today we get our hands dirty with three real systems, in roughly the order our reading path presents them. Zep, a temporal knowledge graph from a commercial vendor. A-MEM, a research system built on an unlikely inspiration, a German note-taking method from the 20th century. And Mem0, a system built explicitly for production deployment at scale. Then we widened out the scope of the system, and we went out to the vendor landscape and the build versus buy decision that every team building agent now has to make.

The through line for this episode is a tension you will feel in all three systems and in the market around them. On one axis, how much structure should memory have? Flat text on one end, rich knowledge graphs on the other. On the other axis, how much should you spend to maintain it?

Because every bit of structure you add, every entity you extract, every graph edge you resolve, costs a model call, adds latency, and creates a new way to be wrong. Let us watch three teams make that trade differently.

Start with Zep, from a paper by Preston Rasmussen and colleagues at the company of the same name, built around an open source engine they call Graphiti.

Zep’s bet is that the missing ingredient in agent memory is time, and the way you capture time is a temporally aware knowledge graph. The architecture has three tiers, and the structure is worth understanding because it is a complex structure. The structure is a clean realization of the CoALA split from last episode.

At the bottom, an episode subgraph, the raw input data, messages, text, JSON, stored losslessly. This is the immutable record, the ground truth. On top of that, a semantic entity subgraph, the entities and the relationships between them, extracted from the episodes by a language model.

And at the top, a community subgraph, clusters of strongly connected entities, each with a high level summary, giving the system a global view of the system, giving the system a global view of the domain. Raw episodes at the bottom, extracted semantic facts in the middle, summarized communities at the top. The authors explicitly note that this dual storage, raw episodic data alongside derived semantic structure, mirrors the psychological distinction between episodic and semantic memory. CoALA in production. But the real innovation, the thing Zep is actually selling, is what they call bitemporal modeling. Every fact in the graph carries two timelines, Timeline T is the chronological order of events in the world. When did this thing actually become true? Timeline T prime is the transactional order. When did the system learn about it? Keep both, and you can do something vector stores famously cannot. You can handle a fact that changes. When new information contradicts an existing edge, Zep uses a model to detect the conflict and invalidates the old edge by stamping it with an expiry time, rather than deleting it, or letting both end up. Zep uses a model to detect the conflict and invalidates the old edge by stamping it with an expiry time, rather than deleting it, or letting both end up. Zep uses a model to detect the conflict and validates the old edge by stamping it with an expiry time, rather than deleting it, or letting both end up. When both versions sit there equally valid, the old fact is still there, marked as having been true from this date to that date. The agent stops being confused about what is currently true. The construction side has details worth knowing, because they’re where the cost and the failure modes live. When Zep ingests a message, it extracts entities, then runs an entity resolution step, embedding each name, and doing both a similarity search and a full text search against existing entities. existing entities to decide whether this is a new entity or a duplicate of one already in the graph. It uses a reflection technique borrowed from the reflection work to cut hallucinations during extraction. It builds communities not with the heavy Leiden algorithm but with label propagation, specifically because label propagation can be updated incrementally as new data arrives instead of recomputing the whole community structure every time. Every one of those steps is a language model call, which is the hidden tax of the graph approach, and Zep’s engineering is largely about paying that tax as rarely as possible. The retrieval side is a useful template, too. Zep runs three search methods in parallel cosine semantic similarity for meaning, Okapi BM25 full text for exact words, and breadth-first graph search for contextual neighbors. Each targets a different kind of similarity, semantic, lexical, and structural nodes that sit closely together in the graph. Then it re-ranks, and the menu of re-rankers is itself instructive. Reciprocal rank fusion, maximal marginal relevance, a graph distance re-ranker that favors facts near a chosen node, an episode mentions re-ranker that boosts frequently referenced facts, and at the top of the cost curve, a cross-encoder that scores every candidate against the query with full attention. This multi-channel then re-rank pattern is, as we will keep seeing, the production default. And the deeper design point. Zep stores raw episodes and derived semantic facts side by side, which the authors explicitly say mirrors how human memory keeps distinct events and general associations as separate but linked systems. Keep the raw, derive the structure, link them. That phrase will be the moral of the whole series. The results.

On the deep memory retrieval benchmark, Zep posts 94.8% against MemGPT’s 93.4. Marginal. And the authors are refreshingly honest that the benchmark is the problem. Each conversation is only 60 messages, easily fitting in a modern context window, so a full context baseline nearly ties it. The real story is the harder benchmark, LongMemEval, with conversations averaging 115,000 tokens. There, Zep improves accuracy by up to 18.5%, while cutting response latency by… around 90% because instead of feeding 115,000 tokens to the model every turn it retrieves about 1,600. That is the actual pitch, not more accurate on a toy task but comparable or better accuracy at a fraction of the tokens and latency on a realistic one. The second system takes a completely different inspiration. A-mem by Woojong Shu and colleagues builds its memory on the Zettelkasten method, the slip box note taking system associated with the Zettelkasten method. with the sociologist Niklas Luhmann, who used it to write an absurd number of books. The core idea of a Zettelkasten is that the value is not in the individual notes. It is in the links between them, and that the network reorganizes itself as it grows. A-MEM applies that to agent memory. When a new memory is added, the system does not just file it. It generates a structured note with contextual descriptions, keywords, and tags. Then it analyzes the existing memories, finds ones with meaningful similarity, and establishes links.

So the memory store is an interconnected network, not a flat list, and not a rigid, predefined schema. The part that makes it genuinely agentic, and the part worth dwelling on, is memory evolution. When a new memory comes in and links to older ones, it can trigger updates to those older memories, revising their contextual descriptions and attributes in light of the new information.

The network refines its own understanding over time. Picture it. You tell the agent in March you’re learning guitar, and in May you mention you’ve joined a band.

A flat store just appends the band fact. A-MEM, in principle, goes back and enriches the guitar memory with the new context, the two notes now linked and mutually informed.

This is the storage-to-experience arc from last episode, made concrete. A-MEM is reaching for the reflection and experience stages, where memory is not a static archive, but something that reorganizes, as the memory store is. The authors tested across six foundation models, and reported consistent improvement over prior state-of-the-art memory systems, and notably the gains held across both small and large models, suggesting the benefit comes from the organization scheme itself, rather than from a single capable model carrying it. There is a cost to the freedom, though, and it’s the mirror image of Zep’s. Zep’s structure is rigid, but predictable.

A-MEM structure is flexible, but immeasurable. Zep’s structure is emergent, which means its behavior is harder to audit, and its self-rewriting carries exactly the useful memories become faulty risk will keep circling. Every time the agent revises an old note, it can also corrupt it. Flexibility and trustworthiness are intention, and A-MEM sits firmly on the flexibility side.

Now, hold A-MEM next to Zep’s, and you can see the philosophical split in the whole field. Zep’s imposes structure, a defined three-tier graph, explicit entity and edge types, a formal bitemporal model. A-MEM grows structure, emergent links, self-organizing notes, evolution driven by the agent rather than a fixed schema. Both are knowledge graphs, in some loose sense. They are almost opposite design philosophies. And here is the dissent worth flagging, the one we’ll return to in episode 3.

There is a growing argument in the field that the whole industry took a wrong turn by converging on entity-relationship graphs and atomic facts at all. That extracting clean little facts from messy conversation is lossy adds a hallucination-prone model step, and that some agents would be better served keeping the raw narrative.

A-MEMs keep evolving the notes, and the contrarian just keep the raw trace are both reactions to the same worry, that aggressive structure throws away something you needed. The third system is the most explicitly commercial, and that is the point.

Mem0 by Pratik Chakara and colleagues puts the word, production-ready and scalable, right in the title. Its pipeline is the one most teams will recognize. Dynamically extract salient information from the ongoing conversation, consolidate it, and retrieve it on demand. There is a base version and a graph-enhanced variant that adds relational structure. What makes Mem0 worth studying is not a novel data structure, it is the relentless focus on the production metrics that research papers usually ignore. They evaluate on the LoCoMotivity of the data structure, and they evaluate on the LoCoMotivity of the data structure. They evaluate on the LoCoMotivity of the data structure. They evaluate on the LoCoMotivity of the data structure. They evaluate on the LoCoMotivity of the data structure. They evaluate on the LoCoMotivity of the data structure. They evaluate on the LoCoMotivity of the data structure. They evaluate on the LoCoMotivity of the data structure. They evaluate on the LoCoMotivity of the data structure. And the headline numbers are about cost, as much as accuracy. Mem0 reports a 26% relative improvement over OpenAI’s memory on a language model as judge metric. But then, a 91% lower p95 latency, and more than 90% token cost savings versus the full context approach. Sit with why those numbers are the real product. At 100 users, you can afford to stuff the whole history into context. At 100,000 users, each paying you nothing or close to it, a 90% token reduction is the difference between a viable business and a bonfire of API credits. Mem0’s contribution is to take memory seriously as a systems problem with a cost model, not just an accuracy problem with a leaderboard. The graph variant, notably, adds only about 2% overall accuracy over the base, which is itself an honest data point about how much the heavy structure actually buys you on this benchmark. So across our three systems, you have three answers to the structure versus cost question.

Zep, maximal structure, justified by temporal reasoning. A-MEM, emergent, self-evolving structure, justified by adaptability.

Mem0, lean structure, justified by cost at scale. None is the universal right answer. They are points on a trade-off curve, and which one fits depends on whether your problem is dominated by changing facts, by open-ended learning, or by the bill. Before the market, let’s get systematic, because there’s a field companion to all this research, a survey built from engineering write-ups and product launches rather than papers, and it organizes the whole space by design decision. 11 of them. You don’t need all 11, but a handful are the ones every team actually trips over, and they map cleanly onto the three systems we just covered.

Retrieval and ranking. The decision, one vector index or multiple parallel channels fused together. The emerging production answer, the one Zep implements and Cloudflare shipped, is multi-channel with reciprocal rank fusion, not a single cosine lookup. And the sharp warning underneath it, semantic closeness, is not relevance. Cosine similarity will cheerfully hand you something near your query in embedding space that is stale, or about the wrong user, or topically adjacent but useless, while missing the fact that actually mattered because it wasn’t phrased the way the query was.

Consolidation and distillation. The decision, do you run a model on every turn to extract memory or batch it lazily? Eager per-turn extraction is the single biggest cost driver in these systems. Lazy. Lazy consolidation cuts the bill, but adds staleness. And the hard-won rule, reported independently by Slack’s engineers, and by a research paper bluntly titled Useful Memories Become Faulty. When a model continuously rewrites its own memory, the memory degrades, drift, context collapse, detail sanded off.

So keep the raw trace as ground truth, and treat the distilled version as a fallible, rebuildable layer. Exactly the lesson Zep’s dual storage encodes, and exactly the lesson that will detonate in the future. In episode 3, when we find raw trajectories beating distilled skills.

Temporality. The decision. When a fact changes, do you supersede version or silently overwrite? This is the number one field complaint about plain vector stores. They have no notion of supersession, so the old and new facts sit there equally retrievable, and the agent gets confused about what’s true now. Bitemporal modeling, Zep’s whole identity, is the answer builders switch backends to get, substrate. The decision, do you even need a vector database? The contrarian, deliberately boring answer from working engineers is often no. That SQLite with full text search over a transcript store goes remarkably far, and that Git plus object storage as the memory layer gives you audit friendliness for free. Justify the heavy store before you reach for it. And working memory and context. The reminder that long term memory is just one of roughly seven things competing for the context window every step. So you cannot design memory in isolation from the broader context budget. Those five, retrieval, consolidation, temporality, substrate and context, are the decisions that separate a memory system that survives contact with production from one that quietly rots.

Step out of the papers and into the market, because this is where state of industry actually lives. The managed memory market formed astonishingly fast across 2025 and 2026, almost in parallel with the surveys that we’ve seen in the last decade and a half. So you cannot design memory in isolation from the broader context budget. Those five, retrieval, consolidation, temporality, substrate and context, are the decisions that we’ve seen in the last decade and a half. So you cannot design memory in isolation from the broader context budget. Those five, retrieval, consolidation, temporality, substrate and context, are the decisions that we’ve seen in the last decade and a half. The field companion to this research, a survey built from engineering write ups and product launches, lays out the landscape. Mem0, Letta, which grew out of the MemGPT work, Cognee, Zep, with Graphiti, MemoryOS, and more arriving constantly. Cloudflare shipped agent memory with exactly the multi channel plus reciprocal rank fusion retrieval pattern we saw in Zep. And shared team memory profiles became a headline feature. And here you see that M exercised 이게 он Viking المค versão escorting, Nano e involucrando a kemik that мы جمعا here is the catch that should shape any build versus buy decision. Every one of these frameworks ships its own bespoke storage and its own vocabulary. There is no shared wire format, which means migrating your memory from one framework to another today essentially means rebuilding from scratch. You are not choosing a library. You are choosing a representation, a retrieval strategy, and a set of governance choices, and you are marrying them. The principle the practitioners keep arriving at, memory quality equals schema quality, and if you can’t see or move the schema, you can’t really own it. There is also a quieter contrarian movement in the industry that deserves airtime because the vendor pitch can make it sound like you must adopt a heavy memory service. The counter position voiced by working engineers is that many agents do not need a vector database at all. SQLite with full text search over a stored transcript goes remarkably far. Git plus object storage as the memory layer is a real pattern. Keep the immutable transcripts cheaply, derive memory on demand, and get audit friendliness for free.

And a related warning, some frameworks advertised as local still phone home to a cloud model for the extraction step, so local and private is a claim to verify, not assume, especially if privacy was the whole reason you reached for it. There is one more production lesson the field reports keep repeating, and it is blunt. Just add a vector database breaks once the agent runs for a while. The store accumulates, retrieval gets polluted, the agent starts repeating mistakes, and drifting. Which is a perfect setup for the rest of the series, because every failure on that list, drift, staleness, repeated mistakes, is a memory problem. The three systems we covered are each trying in their own way to solve. So how should you read the memory stack, having opened up three systems and the market around them? First, the structure question is the load-bearing one, and it has no default answer. Graph, vector, atomic facts, evolving notes, raw transcript. Each buys you something and costs you something.

Zep’s graph buys temporal reasoning at the cost of an extraction step. Mem0’s leaner approach buys cost savings at the cost of relational richness.

Ask what your actual failure mode is before you pick. Second, time is the feature builder’s most consistently underrate and most consistently switch backends to get. Zep made bitemporal modeling its whole identity for a reason. If your domain has facts that change, and almost every real domain does, a memory with no notion of supersession will quietly poison itself. Third, measure the system, not the demo. Mem0’s contribution is mostly that it reported P95 latency and token cost, the numbers that decide whether you can actually ship. A memory system that looks great on a five-message demo, and falls over the top of the list, is a memory system. It’s not just a five-message demo, it’s a five-message system. It’s a five-message system. A five-message demo, and falls over at 100,000 users, has told you nothing useful.

And fourth, plan for the exit before you enter. No shared wire format means the framework you pick today is one you may be stuck rebuilding out of later. Keep your raw transcripts in something portable and boring, so that whatever clever memory layer you put on top is a derived, rebuildable thing rather than your only copy of the truth.

That last point, keep the raw, treat the clever, layer as fallible, is going to come back with a vengeance in episode three, because it turns out the same lesson governs not just facts, but skills. Three systems, three philosophies. Zep bets on time and structure. A-MEM bets on emergent, self-organizing networks. Mem0 bets on lean memory and the production cost model. And the market around them is fast, fragmented, and locked in by the lack of any shared format.

Next episode, we move from remembering facts, to remembering how to do things. Procedural memory and skill libraries, from Voyager building a library of executable skills in Minecraft, to agent workflow memory inducing reusable routines for the web, to a brand new benchmark that delivers the most uncomfortable finding in the field. That raw experience often beats the polished skill you distilled from it. That one reshapes how you should think about every coding agent you use. See you there.

The Agentic Memory Reading Path, 3 of 5.

In 2023, an agent named Voyager taught itself to play Minecraft by writing its own skills, storing them in a library, and reusing them. It unlocked the game’s tech tree up to 15 times faster than anything before it, and when you dropped it into a brand new world, it carried its skills with it and kept going while other agents froze. It looked like the future of how machines learn. Do something once, distill it into a reusable skill, never relearn it. Three years later, a benchmark called SkillEvalBench tested that dream rigorously and found something that should unsettle anyone building on it. The distilled skills often performed worse than just keeping the raw transcript of what the agent did. The polished skill library, the thing everyone is building, frequently lost to the messy log it was supposed to replace.

This episode is about proceduralization. Procedural memory, how agents remember not facts, but how to do things, and about why the obvious way to do it might be wrong.

Welcome back. This is Epi3. We have done facts. Episodes 1 and 2 were about semantic and episodic memory, what happened and what’s true. This episode is the third leg of the cognitive triad from CoALA, procedural memory, skills, routines, the agent’s growing repertoire of how-to. Our reading path gives us three papers that form a perfect arc. Voyager. Voyager, the origin, where the skill library dream was born. Agent workflow memory, the maturation, where the idea got disciplined and proven on real web tasks.

And SkillEvalBench, the reckoning, a 2026 benchmark built specifically to test whether skill distillation actually works, with results that are going to change how you think about every coding agent you use. And because this is the part of the field closest to the tools we all use daily, we will spend real time on what it means to be a coding agent. Voyager, from Guanzhi Wang and colleagues, is one of the most cited agent papers of its era, north of 700 citations, and for good reason. It was the first language model-powered agent that did open-ended lifelong learning in Minecraft, with no human in the loop, and it had three parts worth remembering.

One, an automatic curriculum that proposed increasingly hard tasks to maximize exploration, so the agent set its own goals. Two, an ever-growing skill library of executable code, where each skill is a program the agent wrote to accomplish something, stored and indexed by a description of what it does, so it can be retrieved by meaning and composed. Three, an iterative prompting loop that fed back environment feedback, execution errors, and self-verification, so the agent ran its code, saw it fail, read the error, and rewrote it until it worked, only then committing the skill to the library. That self-verification gate matters. It means the library fills with skills that actually ran, not skills that merely look plausible.

Critically, Voyager did all this through black-box calls to GPT-4. No fine-tuning, no model weights touched. The learning lived entirely in the skill library, in the harness, not in the model. That is a profound design statement, and it’s the one the rest of this episode interrogates. It says capability can be accumulated outside the model, in an editable store of skills, which is exactly the premise behind every self-improving agent and every coding agent that saves reusable commands today. If it’s true, you can make a frozen model smarter just by giving it a better library.

Whether that premise actually holds, under honest measurement, is the question that dates by the end of this episode. The results were striking.

3.3 times more unique items collected, 2.3 times longer distances traveled, tech tree milestones up to 15.3 times faster than the prior state-of-the-art, and the headline capability, the skill library, transferred. Drop Voyager into a fresh Minecraft world, and it reused its learned skills to solve new tasks from scratch, while other methods struggled to generalize. And here is the line from the Voyager paper that planted a flag for the whole field. The authors argued that because the skills are temporally extended, interpretable, and compositional, they compound the agent’s abilities and, in their words, alleviate catastrophic forgetting. That is the dream in one sentence. A library is a library. A library of code skills as a form of memory that never degrades, only grows, and carries from world to world. Everything in this episode is a stress test of that sentence.

Before we get to the disciplined version of the skill library idea, draw a distinction the field has settled into, because it determines how procedural memory fails.

There are two species of stored skill, and they are genuinely different animals. The first species is the executable code skill, the Voyager kind. A skill is a memory. It runs a program. It either runs or it doesn’t. When it fails, it fails loudly, a compilation error, an exception, a wrong result you can verify against the environment. That’s a feature. You can put a self-verification gate in front of the library and only admit skills that demonstrably worked. But code skills are brittle in their own way. They fail at composition when you try to snap two of them together, and the interfaces don’t quite match. And they’re tied to the specific tool. The second species is the natural language workflow, the kind we’re about to see in agent workflow memory. Here a skill is not code, it’s a described routine, a remembered procedure in words, to book travel, first search flights, then compare against the calendar, then confirm before paying. These are flexible. They transfer across surface changes. They read like instructions a human could follow. But they fail differently and more quietly. They fail through ambiguity and instruction drift. The agent reads the workflow, interprets it a little loosely and wanders off the procedure without any error firing. Nothing crashes. The result is just subtly wrong. Why does this matter for a benchmark and for you? Because the two species need different evaluation and different guardrails. Code skills need execution grounded verification. Run it. Check it. Workflow skills need process checking. And they fail. Did the agent actually follow the steps, not just did the answer look right? A benchmark that only handles one species misses half the field, and a coding agent that mixes both, saved code snippets plus remembered conventions and prose, has both failure modes at once. Hold this distinction. It’s the lens for everything that follows.

Voyager was a proof of concept in a game. The next paper, Agent Workflow Memory by Zhiruo Wang and colleagues, took the skill library idea and made it work on something messier and more real, web navigation. The reframing is subtle but important. Instead of a library of executable code, Agent Workflow Memory induces workflows, reusable routines, commonly repeated patterns of action, extracted from past experience and selectively fed back to guide future behavior.

So there are now two flavors of procedural memory in play, and they fail differently. Voyager-style executable code skills fail with compilation and composition errors. Natural language workflows and routines fail with ambiguity and instruction drift. A benchmark has to handle both, because the field is split between them. What makes Agent Workflow Memory rigorous is the offline and online distinction.

Offline, the agent induces workflows from training examples ahead of time. Online, and this is the clever part, it induces workflows on the fly, from its own test time experience, with no training set at all. They tested on two big web benchmarks, Mind2Web and WebArena. Collectively, over a thousand tasks across 200 plus domains, travel, shopping, social media.

The numbers, a 24.6% relative improvement on Mind2Web, and a 51.1% relative improvement on WebArena, while also reducing the number of steps to finish a task. But the most important result is about generalization, and it is the one to hold on to. Online agent workflows, and this is a standard in our typical form of child development. Read that again. The more novel the situation, the more the accumulated Workflow Memory helped. That is exactly the property you want from memory, and exactly the property the next paper says is harder to achieve than it looks. Now the reckoning, SkillEvalBench by Ying-Ti Lei and colleagues, and it is a classic before this little ruckus VTB it is. In the last few days, the best I’ve seen work with us is the VTB. We are constantly trying to break this barrier and make it easy to run even harder against specific expectations. This is the first time we’ve done this kind of work. We’re not only trying to hack into the statistics, but we’re actually trying to break them down into three different categories. We don’t want to work with our employees, Now the reckoning. SkillEvalBench by Ying-Ti Lei and colleagues, 2026, is a diagnostic benchmark built to answer one precise question. When an agent accumulates rich episodic experience, can that actually be distilled into reusable procedural skills? Not, does the score go up, but did real durable skill formation happen? The design is the most careful in the whole series, so let me lay it out, because the design is the contribution. 180 tasks across six real-world agent environments, organized into role-conditioned task families that share a hidden, latent procedure. Meaning each family is a set of tasks that all require the same underlying how-to, dressed in different surface details, so the benchmark can ask whether the agent learned the procedure or just memorized the surface. Within a family, there’s a deliberate progression.

During acquisition, the skill-forming phase, the agent sees variants designed to teach the procedure, a canonical version that presents it plainly, an enriched version that exposes a missing sub-step, a variant that changes the surface but keeps the procedure. The agent updates an external skill library using compacted trajectories and verifier feedback. Then, and this is the crucial move, the library is frozen and the agent faces deployment tasks it cannot adapt to. Those deployment tasks come in three flavors, each probing a different kind of robustness. Context shift, where the skill is needed in an unfamiliar setting. Adversarial shortcuts, where a shallow wrong answer is tempting and only a process check catches it. And composition, where the agent must combine skills it learned separately. Acquisition, then frozen deployment. This is the freeze-then-evaluate discipline we flagged back in episode one, made into a benchmark.

There are ten model configurations and three different agent harnesses, so the findings aren’t an artifact of one setup. And then the controls, which are what make the findings trustworthy. SkillEvalBench compares the agent’s self-generated skills against four baselines, a no-skill control, a raw trajectory control, a curated start condition, and self-generated evolution. By holding the answering model fixed and varying only the skill condition, it can separate genuine procedural abstraction from three confessions. The base model’s raw capability, prior curated knowledge, and mere reuse of episodic traces.

The findings, across ten model configurations and three agent harnesses. First, current agents often adapt locally, but rarely form robust, reusable skills. Skill conditions can help during acquisition or replay, but the gains are unstable once the library is frozen for deployment. Second, the gut punch. Raw trajectory reuse frequently outperforms distilled skills. The base model’s raw capability, prior curated knowledge, can help during acquisition or replay, but the gains are unstable once the library is frozen for deployment. Third, the gut punch. Raw trajectory reuse frequently outperforms distilled skills. Keeping the messy transcript of what you did beats the clean skill you extracted from it. The author’s interpretation is precise. Distillation discards contextual and procedural cues that turn out to be useful later. Abstraction is lossy, and it throws away exactly the details that would have helped in the novel case. And third, the capacity finding. Writing more skills, or building bigger skill libraries, is not the answer. More updates can improve coverage while introducing episodes of the novel. Third, the capacity finding. Writing more skills, or building bigger skills, is not the answer. More updates can improve coverage while introducing episodes of the novel. Third, the capacity finding. Writing more skills, or building bigger skills, is not the answer. More updates can improve coverage while introducing episodes of the novel. The library fills up with junk that fit one situation and pollutes the rest. Put Voyager, agent workflow memory, and SkillEvalBench in a line, and you get the field’s actual trajectory.

The dream, skills as perfect, compounding, transferable memory. The disciplined version, yes, induced workflows really do help, especially as tasks get novel. The reckoning, but only if you measure honestly, with a frozen library and a raw trajectory control, Because a lot of what looks like skill formation is just local adaptation, or the base model being good, and the polished abstraction often loses to the raw trace.

Sit a moment longer with SkillEvalBench’s third finding, the capacity result, because it overturns the most intuitive thing you’d assume about a skill library, that more is better. The benchmark found that writing more skills, or provisioning a larger resource library, is not sufficient, and can actively hurt. Additional updates improve coverage, the library can handle more cases, but they also introduce episode-specific drift and procedural clutter.

The library fills with skills that fit one peculiar situation, that overlap and conflict with each other, that the retriever now has to wade through. Coverage goes up, quality and findability go down.

This reframes the skill library from an asset you accumulate into an organism you have to keep healthy, and the field is starting to treat library haphazardly. The library is now able to measure library health as a measured quantity in its own right.

The metrics that matter, the raw size of the library, its growth rate, how much of it is redundant or near duplicate, and what fraction of retrievals actually hit a high-value, frequently reused skill versus pulling up clutter.

A library that grows without bound, where most skills are never reused, is not a richer agent. It’s a polluted index that gets slower and less accurate over time. Some research systems address this directly. By co-managing three things at once, which skills to select, which to actually use, and which to distill or merge, on the theory that without active maintenance, the library accrues drift until it saturates and caps performance. The parallel to ordinary software is exact and worth stating, because it makes the discipline obvious. An ever-growing skill library with no curation is technical debt. It is a code base nobody refactors, a utils folder where every function was added, and half are near duplicates, and none have tests for whether they’re still used. You would never let your actual code base grow that way.

The finding here is that an agent’s procedural memory needs the same hygiene, dead-skill elimination, deduplication, periodic consolidation that you’d apply to any code you intend to maintain. Accumulation is not learning. Curated accumulation, maybe.

This is the episode where the research touches your daily tools directly, because a coding agent’s skill library is exactly this problem. When your agent writes a reusable helper, saves a skill or a command, or distills a past session into a reusable instruction file, it is doing procedural memory, and SkillEvalBench’s warning applies to it directly. The industry has been converging on context engineering as the discipline here.

Martin Fowler published a substantial piece this year on context engineering for coding agents, framing long-term memory. He has one of roughly seven things competing for the context window every step, which means you cannot design skill memory in isolation from the rest of the budget.

And a paper from this spring, Codified Context, Infrastructure for AI Agents in a Complex Code Base, names the failure mode in plain language.

Agentic coding assistants lack persistent memory, so they lose coherence across sessions, forget project conventions, and repeat mistakes they were already corrected on. Every one of those is a procedural memory failure.

Now layer SkillEvalBench’s findings on top, because they are quietly subversive for how we build coding agents. If raw trajectory reuse often beats distilled skills, then the instinct to aggressively summarize a successful session into a tidy reusable rule may be actively counterproductive.

The messy transcript of how the agent actually fixed the bug, with all its false starts and environment-specific details, may transfer better than the clean three-line lesson you extracted.

And if bigger skill libraries accrue drift and clutter, then an ever-growing folder of saved skills and commands is not a free win, it is a maintenance liability that pollutes retrieval over time.

Library health, its size, its growth rate, how often each skill actually gets used, becomes a thing you have to measure and prune, not just accumulate. There is research pushing on this directly.

A system called MemSkill, reframes memory operations themselves as learnable rather than hand-coded, on the theory that fixed, human-designed extraction rules are too rigid across diverse interaction patterns. That is the same instinct as A-MEM from last episode, stop hard-coding what to store and how. But the honest state of things per SkillEvalBench is that we do not yet have a reliable recipe for turning one-off coding experience into durable, transferable skill.

The practical advice that falls out, keep your raw transcripts, be skeptical of aggressive distillation, treat your skill library like a code base that needs weeding, and measure whether a saved skill actually gets reused before you trust that it is helping. So where does the procedural memory story leave us?

The dream is real, but conditional. Voyager and agent workflow memory prove that procedural memory can compound an agent’s abilities and can generalize to novel tasks. That is not in doubt.

What is in doubt is whether your particular skill distillation pipeline is actually capturing durable skill or just writing the base model and local adaptation.

The measurement is the whole game. SkillEvalBench’s contribution is not a system, it is a method. Freeze the library, add a raw trajectory control, add a no-skill control, test on context shift and adversarial composition.

Without those controls, you will over-claim. You will credit your skill memory for gains that came from somewhere else. Raw often beats refined. The single most actionable finding in this episode is that distillation is lossy in a way that hurts exactly when you need help most on novel tasks. Retain the raw experience. Treat the distilled skill as a fallible, rebuildable layer on top, never as a replacement for the trace. This is the same lesson as facts from episode 2, now proven for skills. And library health is a measurable quantity. Size, growth rate, drift, clutter, high-frequency skill coverage, a skill library is not a junk drawer you keep adding to. It is a living store that degrades without curation. The deepest open problem and the bridge to the next two episodes is attribution. How do you know your gain came from the skill and not the base model? How do you know the right skill was retrieved for the right reason? Those questions turn out to be a crisis in their own right. And that crisis is episode 4. Procedural memory is where the gap between the demo, and the science is widest. Voyager dazzled. Agent workflow memory delivered, rigorously. And SkillEvalBench held the whole idea to the fire, and found that raw experience often beats the skill we distill from it, and that bigger libraries can make things worse, not better. Next episode is the one underneath all the others. The measurement crisis. Three 2026 papers, each exposing a different way our benchmarks quietly lie to us. How the choice of what counts as the best, as the right answer, can flip your rankings. How answer level scores hide retrieval failures. And how updating your agent’s harness gets confused with actually benefiting from it. If you build or buy memory systems, this is the episode that will change how you read every number you are shown. See you there.

The agentic memory reading path, four of five. Imagine two memory systems. You run them on the same benchmark, with the same retrieval, the same queries, everything identical, and depending on a single choice you make in the scoring script, a choice most papers don’t even mention, system A wins or system B wins. Not a small wobble.

The ranking flips on up to 94% of the queries. That is a real result from a 2026 paper, and it means something uncomfortable. A large fraction of the memory leaderboards you have seen could be reversed by a decision the authors made silently and never reported.

This episode is about the measurement crisis, not as a complaint, but as a craft, because the same researchers exposing how the numbers lie are also telling you exactly how to measure honestly. Welcome back to the agentic memory deep dive. This is episode four. Every episode so far has ended by pointing here. The foundations flagged that single success to the agentic memory reading path numbers hide failures. The systems episode showed a benchmark so easy a dumb baseline nearly won it.

The procedural episode showed that what looks like skill formation is often just the base model in disguise. All of those are the same disease. We are bad at measuring memory, and the badness is not random. It systematically flatters whatever we built. Today, three 2026 papers, each exposing a different failure of measurement and each prescribing the fix. First, a paper called Same Ranking, Different Winner on how the choice of scoring target silently flips conclusions. Second, MemConflict on how answer level scores hide retrieval failures.

Third, harness updating is not harness benefit on how we confuse changing an agent with improving it. And we will ground all of it in two industry efforts to put agent reliability on a scientific footing. This is the most important episode in the series for anyone who has to trust a number.

Start with the paper that opened the episode by Sugam Panthi and Rabab Abdel-Fattah titled Same Ranking, Different Winner How Scoring Targets Shape LLM Memory Benchmarks. The setup is a situation we built up over the last two episodes. Modern memory systems transform a single conversation turned into multiple descendants. The raw turn, a summary, an extracted atomic fact, a timeline entry. All of those can live in the retrieval index at once. So when you score retrieval, you have to answer a question almost nobody answers out loud. Which stored form counts as the correct thing to retrieve? The authors define three possible scoring targets. Raw, credit the system for retrieving the original turn. Source, credit it for retrieving anything source-linked to the answer.

Canonical, credit it for retrieving the clean, distilled canonical fact. And they built a tool called TyApp that takes already saved ranked outputs and rescores the original turn. And it rescores them under each of the three targets without re-running retrieval at all. Same retrieval behavior, three different definitions of correct, and you watch what happens to the rankings. What happens is carnage for anyone who trusts leaderboards.

On the two standard benchmarks, LoCoMo and LongMemEval, switching only the credited target changes the NDCG score on between 83 and 94% of shared queries. It flips the ordering between systems on real transfer runs, so that the NDCG and the NDCG are the same. It even reverses design recommendations. The advice about how dense your memory parser should be inverts depending on the scoring target. And then they did a careful semantic audit of 1900 plus cases and found that the relaxed, generous, source-linked credit was actually fully justified only about 29% of the time, even though the scoring rubric itself was highly reliable. There’s a subtler trap the same paper surfaces, and it’s one to watch for everywhere in evaluation. The coverage confound. Different scoring targets don’t just change scores, they change which queries are even answerable. And comparing systems over different query populations confounds the result with how hard those particular queries were.

The authors found that queries which have a clean canonical target are intrinsically easier under the raw scoring, so if you don’t restrict the comparison to a shared, coverage-matched score, you can credit a system for being good when it was just being graded on easier questions. The discipline that fixes it. Only compare on the queries all systems actually had a fair shot at, and justify your retrieval depth, the K in top K, against where recall actually plateaus rather than picking it to flatter your numbers. They call this target non-invariance, and the phrase is worth keeping. It means your conclusion about which memory architecture is better is not invariant to a benchmark design choice that is usually left implicit.

The fix is almost embarrassingly simple, and almost never done. Define your scoring target explicitly, and report it. And note how they earned the right to make that claim, because it models good practice. They validated their scoring rubric against human labels on a stratified subset, reaching strong inter-rater agreement, before running a five-model majority vote at temperature zero, across all 1,900 cases. They calibrated the judge before trusting it. If a paper or a vendor shows you a memory benchmark, and cannot tell you what counted as a correct retrieval, the number is not interpretable. Full stop.

The second paper attacks a different illusion, that getting the right answer means the memory worked. MemConflict by Zhen Tao and colleagues treats memory validity not as a static property, but as what they call a query-conditioned fitness-for-use problem. MemConflict by Zhen Tao and colleagues treats memory validity not as a static property, but as what they call a query-conditioned fitness-for-use problem. MemConflict by Zhen Tao and colleagues treats memory validity not as a static property, but as what they call a query-conditioned fitness-for-use problem. A memory isn’t just true or false, it’s fit or unfit for this particular question, right now. To test that, MemConflict deliberately manufactures conflict. It simulates long-horizon histories from structured user profiles, injects cross-session conflicts where a later fact contradicts an earlier one, and seeds in semantically similar distractors plausible-looking wrong memories that compete for retrieval. The distractor design is the clever part. The distractor design is the clever part. It is a structure about a closely related entity, similar enough to fool a cosine search but wrong, so that a system relying purely on embedding similarity gets pulled toward it. It formalizes three kinds of conflict, and each is a real production failure. Dynamic conflicts are about temporal validity. The fact was true, then it changed, which is true now. Static conflicts are about plain factual correctness among competing claims. Conditional conflicts are about contextual applicability. Conditional conflicts are about contextual applicability. The memory is true, but does not apply to this particular question. Then it evaluates two ways at once. Black box, did the final answer come out right? White box, did the system actually retrieve and rank the correct supporting memory, separately scored from whether the answer happened to be right? And the central finding is the one to internalize. Across six representative long-term memory systems, answer correctness often diverges from memory retrieval and ranking. A system can produce the right answer while having retrieved the wrong evidence, or ranked the correct memory far down the list. It got lucky, or it pattern matched, or the base model filled the gap. If you only looked at the answer, you would conclude the memory worked. The white box view shows it didn’t. The diagnostics pin the failures down. Sometimes the supporting memory is missing entirely. Sometimes it’s retrieved but used ineffectively. And the sensitivity analysis is a list of everything, that makes real deployments hard. Longer histories, distractors, implicit queries, and larger conflict distances, all degrade performance. Put TyApp and MemConflict together, and you have the two halves of the white box argument. TyApp says, be explicit about what counts as the right memory. MemConflict says, check whether you actually retrieved it, separately from whether the answer was right. Both are reactions to the same bad habit, scoring only the final answer, which is the memory equivalent of grading a student only on the final number, and never checking whether they understood the problem, or just copied the back of the book. The third paper, by Min-Hua Lin and colleagues, has the bluntest title in the series, Harness Updating is Not Harness Benefit. And it goes after the most seductive illusion of all, the one underneath the entire self-improving agent narrative. Here is the setup.

Self-improving agents are built around an editable harness. The prompts, the skills, the memories, the tools, everything outside the model waits that shapes how it behaves. Self-evolving agents update that harness from their own execution history, and the field cheers when the score goes up after an update. But the authors ask a question almost nobody separates out. There are two completely different capabilities hiding in self-evolution. One, harness updating, the ability to produce useful, persistent updates to the harness, Two, harness benefit, the ability to actually benefit from an updated harness when solving a task. Those are not the same skill, and conflating them is everywhere. Their findings are genuinely surprising. First, harness updating is flat across model capability. Models from wildly different capability tiers produce harness updates that yield surprisingly similar gains. In their striking example, updates produced by a small 9 billion parameter model yielded gains comparable to updates produced by a frontier model like Claude Opus. The cheap model writes about as useful a skill or memory as the expensive one. Second, harness benefit is non-monotonic. Weak models benefit little from a good harness, mid-tier models benefit the most, and strong models benefit less than mid-tier. They trace the weak-tier failure to two causes. Weak models either fail to activate the relevant harness artifact at all, or they activate it, but fail to follow it faithfully. The two weak-tier failure modes deserve a beat each, because they’re diagnosable in your own system. The first is failure to activate. The relevant skill or memory is sitting right there in the harness, and the agent never retrieves it, never brings it into play. The second is failure to follow. The agent does activate the artifact, pulls the right note into context, and then doesn’t actually adhere to it, drifts, ignores it, does its own thing. Those are different bugs with different fixes. One is a retrieval problem, the other an instruction following problem. And lumping them together as, the memory didn’t help, hides which one you have. The implication reframes how you should spend. If updating the harness is easy, and roughly capability independent, but benefiting from it requires a capable task solver, then you should invest your capability budget in the agent that does the work, not the agent that does the evolving. You can use a cheap model to write the skills, and a strong model to use them. And you should train specifically for harness invocation and long horizon instruction following, the exact things weak models fail at. But the measurement lesson is the one for this episode. When your self-evolving agent’s score goes up, you do not know why. Maybe the harness update was good, maybe the base model was always going to do that, maybe the agent just did more stuff. Without disentangling updating from benefit, my agent learned is a claim you have not earned. These three papers are academic, but the exact same reckoning is happening in industry right now. And two efforts are worth knowing by name, because they are dragging agent evaluation towards something deserving the word science. The first is a paper called Towards a Science of AI Agent Reliability, from a group including Sayash Kapoor and Arvind Narayanan, who built their reputation puncturing AI hype with careful measurement. Their argument is the thesis of this whole episode, stated for production. Rising accuracy on standard benchmarks suggests rapid progress. Yet agents keep failing in practice. And that gap exists because compressing agent behavior into a single success metric obscures the operational details that actually break. Same disease, bigger stakes. The single number flatters the system, and hides the failure. The second is an empirical study called Measuring Agents in Production, and it is exactly the grounded evidence the field has been missing. The authors ran 20 in-depth case studies with real agent developers and surveyed 306 practitioners across 26 domains to find out what technical methods actually correlate with successful deployment, not what should work in theory, what real teams found works. That kind of study, practitioner-grounded multi-domain, is what turns folklore into knowledge. And the meta-point connecting the academic and the industrial. The fix for the measurement crisis is never find the one true benchmark. It is methodological discipline. Ground evaluation in execution rather than in how plausible the output looks. Build a small golden set of your own real tasks and replay at every release. Measure across repeated runs because reliability is a distribution, not a single lucky pass. Calibrate your language model judge against human labels before you trust it and report the agreement. And never treat a pass rate as proof of correctness. These are probabilistic systems. Evaluation reduces risk. It does not prove the thing right. If there’s one transferable skill from this whole episode, it’s the control set. The baselines you run alongside your system so that a gain actually means something. Every paper we’ve covered across this episode and the last is really an argument for a specific control. Let me assemble the toolkit because this is the part you can apply Monday. The no-skill control. Run the exact same task with the memory or skill system turned off. If the system on number isn’t meaningfully above system off, your memory did nothing and skill evil bench showed that gap is often smaller than people assume. The raw trajectory control. Compare your distilled memory against just replaying the raw transcript. This is the brutal one from episode 3. Raw often wins. And if you never run it, you’ll credit your distillation for gains a dumb log would have given you. The full context control. Compare your clever retrieval against simply stuffing everything into the context window. On the easy benchmarks, full context nearly ties the fancy system, which is how you discover the benchmark is too easy to be telling you anything. The coverage-matched query set. Only compare systems on the queries they all had a fair shot at. So you’re not secretly grading one system on easier questions. The confound TyApp surfaced. The frozen deployment split. Separate the phase where the system learns from the phase where it’s tested. And freeze the memory before testing so gains can’t sneak in through test-time adaptation. And the calibrated judge. Before you trust a language model to score thousands of answers, validate it against human labels on a sample and report the agreement because judges carry position, verbosity, and self-preference biases. And an uncalibrated judge is just silent drift in your metric. None of these is exotic. They’re the agent memory equivalent of a control group and a placebo. The reason they matter so much here is that memory systems are unusually good at looking like they work. The answer comes out right, the demo is impressive, while the underlying memory did little or nothing. Controls are how you tell the difference between a system that remembers and a system that got lucky in front of you. So you have seen the three ways memory benchmarks lie. How should you read a number now without becoming a nihilist about all of them? First, ask for the scoring target. After same ranking, different winner, any memory result without an explicit definition of what counted as a correct retrieval is uninterpretable. Not wrong, uninterpretable. You literally cannot tell what was measured. Second, demand the white box view. After MemConflict, an answer level accuracy number is necessary but not sufficient. Ask whether the right memory was actually retrieved and ranked, separately from whether the answer was right. If a system only reports final answer accuracy, assume it is hiding retrieval failures until proven otherwise. Third, disentangle change from improvement. Harness updating is not harness benefit. Be deeply skeptical of any self-improvement claim that does not separate the quality of the update from the capability to use it and that does not control for the base model. A score that went up after you changed something is not evidence the change helped. Fourth, control your baselines. The connective tissue across this whole episode and the last one is the control set. A no-skill baseline. A raw trajectory baseline. A full context baseline. And a memory subset. Held out frozen deployment. These are not academic niceties. They are the difference between knowing your system works and hoping it does. And the deeper point, the one I would attach to all of it, these are not reasons to despair about agent memory. They are the field growing up. A discipline becomes a science precisely when it learns the ways its own measurements deceive it and builds the controls to defeat them. Astronomy had to learn about distortion. Medicine had to invent the randomized controlled trial. Agent memory is, right now in 2026, inventing its equivalent. The papers in this episode are not the field failing. They are the field becoming trustworthy. The measurement crisis is real and it is also the most hopeful story in the series because the same people exposing the lies are handing you the controls. Define the scoring target. Open the black box. Separate updating from benefit. Control your baselines. Do those four things and you can actually trust what you build. One episode left and it is the frontier. Forgetting the single least measured part of the entire stack. We will look at stale. A benchmark where the best frontier model scores barely better than a coin flip at noticing its own memories have gone stale. We will look at the strange flood of brain inspired forgetting designs and the gap between their ambition and evidence. And we will map the open opportunities, what the field builds next, and where memory and reliability finally merge into one problem. The finale, next time.

The agentic memory reading path, five of five. A user tells their assistant in January that they’re training for a marathon. In June, they mention offhand that they tore their ACL and had surgery. Then they ask, what should I do this weekend? A good assistant does not suggest a 20-mile run. But to get that right, it has to notice that one memory silently invalidated another.

Nobody said, forget the marathon. The new fact just quietly killed the old one. That is called an implicit conflict. And when researchers built a benchmark to test it, the best frontier model on the market got it right only about 55% of the time. Barely better than a coin flip at knowing when its own memories have gone stale.

This is the finale of our agentic memory series. And it is about the part of the stack almost nobody measures, forgetting.

When a memory should die, whether the system notices and why this is the frontier the whole field is about to run into. Welcome back. This is episode five. We have climbed the whole reading path, foundations in the vocabulary, the systems people deploy, procedural skills and the raw beats distilled twist, the measurement crisis and how to read a number honestly. All of it has been about remembering.

This episode is about the opposite and the field’s blind spot. Across all the surveys, one finding repeats. Forgetting is the least measured part of agent memory.

Everyone builds systems that accumulate. Almost nobody measures whether the system correctly removes what is stale, wrong or superseded. So today, the stale benchmark, our reading path’s capstone which tries to measure exactly this.

Then the strange flood of brain-inspired forgetting designs and the gap between their ambition and their evidence. Then forgetting as a safety requirement, not just a cost saving. And finally, the open opportunities, what gets built next and the place where this entire series converges. Where memory and reliability turn out to be one problem.

The capstone paper by Hanxiang Chao and colleagues has a title that is also the question, stale, can LLM agents know when their memories are no longer valid?

And it isolates a failure mode the field had mostly ignored, which they call implicit conflict. That is the marathon and the torn ACL case. A later observation invalidates an earlier memory without any explicit negation.

No one says this is no longer true. It remains to be seen. It remains to be seen. It requires contextual inference and common sense reasoning to even notice the contradiction.

The benchmark is serious. 400 expert validated conflict scenarios, 1,200 evaluation queries, spanning over 100 everyday topics with context up to 150,000 tokens.

And it probes three distinct abilities, which is the part worth memorizing because they are three different ways a system can fail at forgetting. State resolution. Can the agent detect that a prior belief is now outdated?

Premise resistance. Can it reject a question that falsely presupposes the stale state? The user who asks, since I still work at Acme when they told you last month they quit?

An implicit policy adaptation. Can it proactively apply the updated state in its downstream behavior? Not just acknowledge the change when asked, but actually act differently because of it?

Make the three dimensions vivid because each is a distinct way to fail. State resolution is the baseline. You tell the agent the marathon is off and later it correctly reports that you are not, in fact, training. Many systems can do at least this when asked directly. Premise resistance is harder.

You ask, what pace should I target for my long run this weekend? A question that smuggles in the false premise that you’re still training and a good agent has to refuse the premise rather than helpfully answer it. Models are bad at this. They tend to accept whatever the question presupposes. An implicit policy adaptation is hardest of all.

Without being asked anything about the marathon, the agent proactively stops suggesting running-related plans because it has internalized that the state changed. That’s not recall. It’s behavioral updating. And it’s where systems fall apart. The results are sobering.

Across frontier models and specialized memory frameworks, there is a pervasive gap between retrieving updated evidence, and acting on it. The best evaluated model reaches only 55.2% overall accuracy across a benchmark of 400 expert-validated scenarios.

Models routinely accept outdated assumptions baked into the user’s query. That’s the premise resistance failure. And they struggle to recognize when a change in one part of the user’s state should invalidate related memories.

The torn ACL should invalidate not just his training for a marathon, but a whole cluster of downstream assumptions, the race registration, the training plan, the new running shoes, and models don’t propagate that.

They treat each memory as an island, when in reality, memories form a web where invalidating one node should ripple to its neighbors.

That propagation problem, one change should cascade to everything it implies, is the deep technical challenge STALE exposes. And it’s exactly what its prototype fix targets. The authors also offer a prototype fix called CUP2. There are a lot of other things you can think about, but I just want to give you a quick overview of what we’re looking at right now, but you can actually find them on the web. This is an experiment I ran in 2012 using a single word, and it’s just a very simple, multi-line task with a single question. If you try to understand the answer, you can get a random solution. I wrote a helix function, and you can actually see it in this equation. The middle line, the low line, is an array of membicals. In the middle line, you can see this space-time, Now, the cultural phenomenon, because the way the field is responding to forgetting, is itself a story. The 2026 wave of forgetting research is overwhelmingly neuroscience-flavored, to a degree that is almost a fashion. Sleep phase consolidation, synaptic tagging and capture, Ingram maturation, reconsolidation upon retrieval, hippocampal cortical architectures. The metaphors are everywhere. Two examples we pulled fresh off the mirror this month. One paper, Human-Inspired Memory Architecture for LLM Agents, proposes six cognitive mechanisms at once. Sleep phase consolidation, interference-based forgetting, Ingram maturation, reconsolidation upon retrieval, entity knowledge graphs, and more. Another, Superlocal Memory, the living brain, implements biologically inspired forgetting with multi-channel retrieval, and notably, zero language model calls in its core loop. A bet that you can get cognitive-style memory dynamics. There’s a real intellectual idea under the metaphors, and it’s worth stating fairly, the stability-plasticity dilemma.

A memory system has to be plastic enough to absorb new information, and stable enough not to overwrite what it already knows.

Lean too plastic, and you get catastrophic forgetting, the new washes out the old. Lean too stable, and you can’t learn anything new. The brain manages this balance with mechanisms like consolidation. Consolidation during sleep, moving memories from a fast, plastic store to a slow, stable one. And synaptic tagging, marking which memories are worth keeping. Borrowing that balance is a legitimate goal. The continual learning literature even has metrics for it. Forward transfer, how much old learning helps new tasks, and a forgetting rate, how much old competence you lose, and a few agent memory papers are starting to import them. I want to be even-handed here, because the instinct to forget matters, the approval of immerse one’s energy, and one’s focus is struggle. is good and the execution is exciting. Human memory is the one system we know of that forgets gracefully, and copying its mechanisms is a reasonable research bet. But here is the gap the surveys keep flagging, and it is the central tension of this episode. The architectural ambition is racing far ahead of the measurement. Beautiful brain-inspired designs are multiplying, and almost none of them report a hard-forgetting number. There is no shared retention curve. The way machine learning has standard learning curves. There is no standard, did we delete the right thing, precision and recall metric for forgetting. No agreed way to score whether a pruning policy removed the genuinely stale memories or threw out something rare and important. So you get systems that assert their consolidation mechanism works, without ever ablating it against a no-consolidation control to show the mechanism is what’s doing the work. Which is exactly the methodological sin from episode four, now in a new costume. The handful of papers that do report hard numbers on catastrophic forgetting reduction, on forward transfer, are mostly in reinforcement learning settings, not in the text memory systems most people are actually deploying. The text side has the ambition and not yet the scorekeeping. This is the field’s biggest opportunity, stated as a gap. Stale is one of a tiny handful of benchmarks that put a real number on any of this, and even if it’s not a real number, it’s a real opportunity. So, if you’re going to do this, even if it focuses on staleness detection rather than the full life cycle. A standardized forgetting metric suite, retention curves, obsolescence precision and recall, negative transfer measurement, would do for this corner of the field what the measurement crisis papers are doing for retrieval. The designs are ready. The scorekeeping is not. There is a reframing of forgetting that changes it from a nice-to-have into a requirement, and it is the bridge from this whole series into the reliability. Forgetting is not only about cost and clutter. Sometimes forgetting is a safety obligation.

Think it through. If your agent durably remembers sensitive facts about a user, that persistence is a liability. A memory that survives across sessions is a memory that can leak across sessions, that can be subpoenaed, that can be stolen, that can surface in a context where it shouldn’t. The right to be forgotten is not a metaphor here. It is a design constraint. An early benchmark called PersistBench starts probing exactly this. When should an agent forget? Not to save tokens, but because remembering is the wrong thing to do. And persistence is a security surface too, which connects directly to the reliability themes that run alongside this series. In a stateless model, a malicious instruction injected through a document evaporates after one turn. In a persistent memory, it can lodge, linger, and even propagate. That is memory poisoning.

And the most cited attack in the literature plants a backdoor in an agent’s memory through an optimized trigger with no model fine-tuning at all. The defenses the field is consolidating around, provenance and lineage on every memory entry, an audit trail of where each belief came from, are the same defenses that good forgetting requires. You cannot safely forget what you cannot trace. So the unglamorous work of tagging every memory with its origin turns out to serve both goals at once. It lets you delete the right things, and it lets you detect the poisoned ones. This is why forgetting is the right place to end. It is where memory stops being purely an engineering optimization and becomes a question of governance, safety, and trust. An agent that cannot forget is not just inefficient. It is, eventually, unsafe. So if forgetting is undermeasured and over-metaphored, what does a principled version actually look like? The research points at a few distinct mechanisms that can help us forget. One is the ability to forget. The other is the ability to accept. The importance of loss, and the ability to see. This is why we are all important. And they’re worth separating, because the agent-forgets can mean very different things.

The crudest is time-based decay. Memories lose weight as they age, and old ones eventually fall below a retrieval threshold. Simple, but dumb, because age is a terrible proxy for importance. Your home address is old, and you want to keep it. Yesterday’s parking spot is fresh, and you don’t. Better is salience-based retention. Keep what matters, drop what doesn’t. Judged by some signal of importance, you can forget. And you can forget. But you can’t keep what matters. And you can forget. But you can’t keep what matters. And you can’t keep what matters. And you can’t keep what matters. And you can’t keep what matters. And you can’t keep what matters. And you can’t keep what of importance rather than recency the hard part is defining importance without a model call on every memory which is why the zero language model designs we mentioned are interesting they try to compute salience cheaply and structurally more sophisticated still is interference-based forgetting borrowed straight from cognitive psychology a memory fades not just with time but when newer similar memories crowded out this is appealing because it naturally handles redundancy the tenth time you learn the same fact the older near duplicates can yield and the most promising direction the one stales prototype points at is right time adjudication with propagation instead of passively letting old memories decay you actively decide at the moment you write a new memory what it invalidates and you propagate that decision across related memories forgetting becomes a deliberate right operation not a passive leak the torn ACL fact is that memory is not a passive leak the torn ACL fact is that memory is not a passive leak doesn’t wait to be out competed it actively retires the marathon plan and everything downstream of it notice the through line with the rest of the series the good approaches are the ones that treat forgetting as an explicit auditable action the same way episode 1 reframed remembering as a deliberate action rather than a passive store and the honest status again is that almost none of these mechanisms have been compared head-to-head on a shared benchmark we can list the options we mostly cannot yet tell you which one wins on what kind of memory at what cost that is not a closed problem it is an open field which is the perfect note to end the series on so where does the field go from here the agentic memory map ends not with answers but with a set of unusually well defined open problems and they are worth naming because they are the next few years of work unified multi-type white box harness nothing today evaluates semantic epistolic visual and astrophysical episodic and procedural memory together, with stage-attributed diagnostics, explicit scoring targets, a fixed answering model, and confidence intervals. The whole series has been a tour of partial benchmarks. The flagship contribution would be one that spans all three memory types and tells you not just whether the answer was right, but at which stage it broke, a canonical procedural memory benchmark. Skill Evil Bench from Episode 3 is days old and not yet consolidated. The field needs a standard for skill reuse, built around the freeze-then-deploy arc and the no-skill-and-raw-trajectory controls, so that my agent-learned-a-skill becomes a checkable claim. A forgetting-and-obsolescence metric suite. The thinnest area, as we just covered. Retention curves, obsolescence precision and recall, a standard protocol so the brain-inspired designs can finally be compared on evidence rather than ambition. A synthetic data realism, a metric. Most of these benchmarks are generated by language models, and there is good evidence the simulators homogenize, that they converge toward a bland average user and lose the long tail of real behavior. We need a way to measure whether synthetic memory data actually resembles the real distribution, plus principled injection of conflicts and distractors. A shared memory security harness. Poisoning success rate, induced over-refusal, cross-user leakage, provenance violation of the data, and the ability to use the data in a way that is not necessarily a good thing. A multi-user memory isolation, all measured against a common adaptive attack suite, and crucially covering episodic and procedural stores, not just the semantic retrieval that today’s attacks target. And the unbenchmarked production axes. Multi-user memory isolation, so one user’s memory never contaminates another’s. Proactive memory use, knowing when to surface a remembered fact unprompted, and the cost of getting that wrong. And multimodal long-horizon memory, keyed on images and perception. Not just text logs. That list is the state of the frontier. Notice that almost every item is a measurement gap, not an architecture gap. The field has no shortage of clever designs. What it lacks, still, is the scorekeeping to know which ones actually work. Let me close the series by pulling the five episodes into one shape, because there is a single idea underneath all of it. We started with CoALA’s vocabulary and the storage-to-experience arc. We toured the systems, Zep, A-MEM, Mem0, and the structure-versus-cost trade. We watched procedural memory deliver, and then humble itself, raw beats distilled. We confronted the measurement crisis and learned the controls that make a number trustworthy. And we end on forgetting the least-measured frontier, where memory becomes a matter of safety. The idea under all of it is this. Durable, inspectable, governable substrate. The winning lesson, repeated in every episode, is keep the raw, immutable, record as ground truth, and treat every clever layer on top, the distilled facts, the extracted skills, the consolidated summaries as derived and fallible, something you can rebuild and must audit. That is the lesson from Mem0’s transcript retention, from SkillEvilBench’s raw trajectory control, from CUP-MEM’s right-time adjudication, from the provenance defenses against poisoning. Same instinct, five times over. And this is exactly where agentic memory merges with the larger project of agent, reliability. The reliability world, running multi-agent systems in production, arrives at the identical principle from the other direction. Thin control over thick state, pass durable references, not chat summaries, trace everything, recover from a durable log.

Memory researchers and reliability engineers are building the same foundation and calling it different names. Memory is a reliability surface. A persistent store is a place where drift accumulates. Where poison lodges, where one user leaks into another. You cannot make an agent reliable without governing its memory, and you cannot govern its memory without the substrate.

So the mindset I would leave you with, after five episodes, is a shift in the question. Stop asking how much your agent can remember. Start asking what it remembers that changes its behavior, and whether you can see it, trust it, correct it, and forget it when you have to.

Utility over capacity. Governability over… Cleverness. The field that began by drawing a map of memory is ending by realizing that the hard part was never storage. It was knowing what to keep, what to let go, and how to prove you got it right. That is the series. Five episodes, 13 papers, one reading path, from the founding taxonomy to the forgetting frontier. CoALA gave us the words. The systems gave us the trade-offs. Procedural memory gave us humility. The measurement crisis gave us discipline. And forgetting gave us the frontier. And the reason all of this matters. An agent that cannot forget is in the end an agent you cannot trust. Thank you for walking the whole path. If this series did its job, the next time someone shows you a memory system, you will know which questions to ask. What’s the scoring target? Where’s the white box view? What’s the control? And what happens when a memory needs to die?

Keep your transcripts. Audit your schemas. And measure the thing everyone forgets to measure. Until next time. Until next time.

The agentic memory research frontier, one of five. Picture an assistant that has talked to one user for three months.

Every conversation, it dutifully writes down what happened. A hundred episodes about cooking. The user burned the rice on Monday, undercooked it on Wednesday, finally nailed it on Friday by adding less water and waiting longer. A hundred separate little memories, each true, each isolated. Now the user asks a question that none of those hundred episodes answers directly. What’s my problem with rice?

The honest answer is a rule the user never stated and no single memory contains. You consistently use too much water and rush the rest. That rule lives in the pattern across the hundred episodes, not in any one of them. Here’s the strange part. Almost every memory system we build extracts knowledge at the moment a memory is written, when it can only see that one new item. It can never look back across the whole period and notice the rule.

This episode is about a different idea, borrowed straight from how brains handle exactly this. You wait, you sleep on it. Welcome to episode six.

This is the first episode of a new sub-series, The Research Frontier, where each installment takes one cutting-edge research direction and follows it down to the mechanism. Today’s direction comes from neuroscience and the science of systems consolidation, and the question it answers is one our earlier episodes circled but never resolved. When should an agent do the expensive work of turning raw experience into general knowledge? The answer almost everyone ships is right now, at right time, or right now, at read time. The answer from neuroscience is later, offline, during downtime, all at once. We’ll cover the core idea and its metaphor, the actual four-step mechanism, how it differs structurally from the systems you already know, the interdisciplinary lineage that runs from hippocampus

to the storage engine, how you would actually measure it without fooling yourself, and the open risks, the things that go wrong, and what gets built next. And there’s a tight crosscut to a later episode on log-structured merge trees that I’ll keep flagging because they turn out to be the same operation. Start with the biology, because the whole proposal is a port of one specific fact about brains.

A memory is not finished the moment it’s formed. During the day, the hippocampus records experiences quickly and cheaply. Then later, during slow-wave sleep, those traces get reactivated in compressed bursts called sharp-wave ripples, and slowly integrated into the neocortex, where they stop being raw episodes and become generalized knowledge. That two-speed account, a fast, cheap learner feeding a slow, general one, is the complementary learning systems theory from McClelland, McNaughton, and O’Reilly in 1995. It is the architectural route of everything in this episode. The proposal is to copy that two-speed split into agent memory.

Split the agent’s memory into a cheap online wake phase that does nothing but append raw traces, and a periodic offline sleep phase that replays the period’s traces, recombines them, and extracts schemas. The key word is when. Consolidation happens during downtime. Not at write time, not at read time. Off the hot path entirely. Now the contrast, because this is the first time I’ve done this, is that it’s not always the case. Now the contrast, because this is the first time I’ve done this, is that it’s not always the case. Now the contrast, because this is the first time I’ve done this, is that it’s not always the case. Now the contrast, because this is the first time I’ve done this, is that it’s not always the case. This isn’t just a pretty metaphor. It makes a falsifiable claim.

The competing view says you should curate memory as it arrives, the moment each item lands. The sleep view says the most valuable memory, the rule across the hundred Rice episodes, is precisely the memory that no online per-item step can ever produce, because producing it requires seeing the whole period at once. That’s the thesis. Off path, whole period recombination produces new generalized memory that incremental curation structurally cannot. The deepest existing instantiation of the mechanism is deep generative replay, from Shin and colleagues in 2017. It’s a generator and solver pair, where the generator re-synthesizes past experiences and interleaves them during offline training, and the paper grounds this explicitly in hippocampal reactivation during sleep and in complementary learning systems.

Re-synthesizes, not copies, that distinction matters, and we’ll come back to it. The concrete takeaway, if the most useful thing in your memory is a pattern that spans many items, you cannot extract it at write time, because at write time, you’ve only ever seen one item. You have to sleep on the whole period. Let’s get concrete about how it actually runs, because the elegance is in the asymmetry between the two phases. The wake phase is online, cheap, and append-only. Every interaction writes a raw trace to an append log. No model curation. No details. No dedupe. No merge. The write path is constant time and never calls a language model. Each trace just carries a little cheap salience metadata for later, a surprise signal and an embedding for neighbor search. The surprise signal comes from prioritized experience replay. Schall and colleagues in 2015, which established that you can weight replay by temporal difference error, how surprising an outcome was, so that surprising traces get replayed more often than boring ones. That’s the prior art that lets later replays. The sleep phase is offline, scheduled, and batched. On a downtime trigger, an idle detector, a cron job, or a log size threshold, a generative replay pass runs in four steps. First, prioritized sampling. Pick which traces to replay by salience, not uniformly. Both Gee and colleagues with automatic recall machines, and Kaplanis and colleagues with multi-time scale replay, both from 2020, argue that which traces you replay, and over what retention horizon, is the real lever, not raw rehearsal volume. Second, clustering of the replayed traces. Third, one language model call per cluster to extract a schema, a generalized deduplicated semantic memory, and to emit recombined episodic summaries. Fourth, tombstone or downweight the raw traces the schema subsumed, while keeping provenance pointers back to them. Two refinements come straight from the continual learning literature. And both fix problems a real agent will actually hit. Ketz and colleagues in 2019 generate internal episodes of past experience without task labels and without segmentation, which is essential here, because a real agent stream has no clean task boundaries, so the sleep phase has to self-segment. And Rostami and colleagues, also 2019, give the explicit dual-memory blueprint, a hippocampal episodic buffer, plus a neocortical generative consolidation that learns a distribution, over past experience. That maps one-to-one onto wake-append log, plus offline schema extraction. One more, and it’s the cost saver. Remind, from Hayes and colleagues in 2019, shows you can replay compressed latent representations, rather than raw samples. That both amortizes the cost of offline replay, and bridges the cognitive view to the storage view. Consolidation runs over densified traces, not raw ones. The takeaway? Keep the right path done. It’s dumb and free, and put all the intelligence in a scheduled batch job, that you only pay for during downtime. This is the segment where we line the idea up against the systems you already know from earlier episodes, because on the surface they look similar, and structurally, they’re very different. Versus Generative Agents Reflection, from Park and colleagues in 2023. Generative Agents run a reflection step, but it’s synchronous, read-triggered, and per-query. It fires when a query needs context.

Consolidation is asynchronous, downtime-triggered, and whole-period. The difference isn’t cosmetic. Sleep sees cross-trace structure that a per-query reflection cannot, because it replays the entire period together, rather than whatever’s relevant to one question. Versus Mem0, from Chikara and colleagues in 2025, which extracts and consolidates at write-time. Write-time extraction is local to the one new item. It cannot revise an earlier conclusion in light of a later trace. Sleep recombines across the whole wake period, so a Friday success can rewrite a Monday failure into a single rule. Versus Simple Decay, like Memory Bank, from Zhang and colleagues in 2023, which forgets by an Ebbinghaus Decay formula. Decay deletes information without transforming it. It can never turn 100 episodes into one rule. It can only let them fade. And this is the central claim, made sharpest by Roskow and colleagues in 2021. Offline Recall. Offline Replay performs credit reassignment and recombination, not mere rehearsal. That’s the cognitive justification for the slogan recombination, not dedupe. Sleep produces a new schema row that existed in no single trace. Versus the Read Model Systems, the Knowledge Graph Memories, like Zep, from Rasmussen and colleagues, and HippoRAG, from Jiménez-Gutierrez and colleagues.

Those define how you read memory. Offline Consolidation is a right-path maintenance discipline that keeps the read model from bloating. They’re orthogonal and composable, not competitors. And versus CoALA, the cognitive architecture scaffold from Sumers and colleagues in 2023.

CoALA names the memory types working, episodic, semantic, procedural, but it leaves the control discipline, the when and how of consolidation, to the model. Sleep consolidation is exactly that missing control discipline.

Here’s the dissent I want to plant, because it’s the honest objection. Maybe this is all just dedupe, with a fancier name. The answer is the recombination versus dedupe ablation, which we’ll get to in the measurement segment, and it’s the whole ballgame. The takeaway for now, the difference between sleep and everything else, is timing and scope. Off-path and whole period. Those two words carry the entire claim. This is the interdisciplinary lineage segment, and the lineage is unusually clean. It runs primarily through neuroscience and the psychology of medicine. It’s a combination of memory, with one striking cross-cut into computer storage. The neuroscience route we’ve already named, complementary learning systems, McClellan, McNaughton, and O’Reilly, 1995, the fast and slow split. Layered on that is sleep-dependent memory consolidation, the stick, gold, and walker line of work. The empirical basis that sleep, not waking rehearsal, is when consolidation actually happens. That’s the load-bearing claim for moving consolidation off the hot path in the first place. Then, Tolving’s distinction between episodic and semantic memory, which is exactly the transition the schema extraction step formalizes, raw episodes becoming generalized rules.

These three are classics, not in our corpus, so I’m citing them by author and year. The engineering lineage is the continual learning thread, and it’s a tidy genealogy. Deep generative replay, Shin 2017, the foundational mechanism.

Then, Van de Ven and colleagues in 2018. Who scaled brain-inspired replay beyond small toy tasks, and framed generative replay as the general remedy for catastrophic forgetting. Not a trick. Then, Ketz 2019, world-model pseudo-rehearsal without segmentation. Then, Rostami 2019, the complementary dual-memory generative consolidation.

And capping it, Hayes and Kahnan in 2021, which taxonomizes replay into veridical versus generative. And enumerates which biological properties, prioritization, and generation, are the most important. Sleep staging, schema abstraction, content gating, are missing from deep learning replay.

That paper is the single best map of the gap this idea targets, and it doubles as a ready-made ablation menu. Now the cross-cut, and it’s the reason this episode pairs with our later episode on log-structured merge trees.

Sleep consolidation and LSM tree compaction are the same off-path batch operation viewed from two disciplines. The LSM memtable is the hippocampal wake phase appendix. The background compaction levels are successive consolidation passes, the sleep stages. The compaction scheduler is the sleep trigger. There’s even a staging analog. Successive passes of increasing coarseness mirror the move from non-REM to REM sleep, and they map directly onto LSM compaction levels. Recent traces consolidated at a fine grain, older ones at progressively coarser semantic grain. LSM contributes the mechanism and a principled cost model. Sharp wave ripple. Generative replay contributes the cognitive justification and the recombination policy.

Reminds latent replay is the bridge between them. Because both views agree, consolidation runs over densified traces. The takeaway, when two fields independently arrive at a pen now, merge later, that convergence is a signal you’re looking at a real invariant, not a metaphor. Steal the cost model from storage. Steal the recombination policy from neuroscience.

Here’s where the field usually goes wrong. And where episode four’s measurement crisis comes roaring back in a new costume.

A brain-inspired design that asserts its consolidation works without ever testing it against a no-consolidation control has proven nothing.

So let’s talk about how you’d actually measure this. Start with the tasks. You want long-horizon multi-session settings where facts evolve and must be generalized. The S-Eval benchmark, Jiang and colleagues, 2026, built for episodic, episodic amnesia and durability. Locomo-style long-conversation question-answering. And crucially, a synthetic schema induction set. You generate n episodes that each instantiate a latent rule, and the test asks whether the rule is recalled, not whether the episodes are. That synthetic generator is what makes the headline metric falsifiable at all. Because real benchmarks don’t ship with ground-truth latent rules. And the whole claim is about inducing rules nobody stated. Then the metrics. Five of them. One, schema induction accuracy. Can the agent answer rule-level questions it was never told verbatim? That isolates the generative consolidation win over dedupe only, and it operationalizes Roskow’s recombination claim.

Two, hot-path latency and cost. Wake phase write cost. Target constant time with no model call against online baselines that pay model cost on every interaction. Three, and this is the subtle one, consolidation cost-cost amortization reported as an amortization cost. Three, and this is the subtle one, consolidation cost-cost amortization reported as an amortization cost. Four, amplification triad. Write, read, and space, split into hot-path versus background. That split is the cost-moves-doesn’t-shrink test, and we’ll come back to it as a risk. Four, the forgetting curve. Recall of period t-facts at t plus caesians, reported as a curve, not a single number, and you have to de-correlate recency from importance so that recency alone can’t masquerade as recall. Five, confabulation rate. The fraction of schema claims not entailed by any source trace, judged offline. That’s the named failure mode in its next segment. The baselines write themselves from the contrast segment. Generative agents reflection, mem0 online extraction, raw retrieval with no consolidation, and decay-only memory bank. And the ablations are where the truth lives. Uniform versus salience prioritized replay, straight off Hayes and Kanin’s missing elements list, testing the prioritized experience replay premise. Single stage versus multistage sleep. The non-REM and REM analyzes. The LSM levels analog. Veridical versus compressed latent replay, the remind question, cost versus fidelity. But the decisive one is replay with recombination versus without, that is dedupe-only. That single ablation isolates the generative claim from mere compression. If your fancy sleep mechanism doesn’t beat dedupe-only on scheme induction accuracy, it’s dedupe wearing a lab coat. One discipline note, the eval judge must not be the same model family making the memory decisions. Use independent or local judges and report human spot check agreement, not judge-only scores. The takeaway, the recombination versus dedupe ablation is the experiment that makes or breaks the entire idea, so run it first. Let’s end where the research project pre-mortem ends, on the risks, because the most powerful failure mode here is also the most dangerous, and it comes from the same mechanism that makes the idea work. The top program risk rated critical, is confabulated schemas. Offline language model recombination can invent facts present in no trace. And here’s the trap. If you hard delete the raw traces during sleep, the hallucination becomes the durable memory, and it’s unauditable because the source it should have come from no longer exists. This is not a hypothetical. It’s the same risk Shin and colleagues named back in 2017 when their generative replay paper cites the creation of a false memory in the hippocampus. Work like Ramirez and colleagues in 2013. Generative replay can fabricate. That’s a feature of how it works, not a bug you can patch away. The mitigation is structural. Never hard delete subsumed traces during sleep, tombstone them and keep them under a retention policy, give every schema row provenance pointers back to the traces it was induced from, and measure the confabulation rate directly. The second risk, rated high, sleep never runs. A busy agent is never idle, so the downtime trigger never fires. The wake log grows unbounded and read performance collapses. And notice this is identical to the LSM compaction debt and right stall failure from the storage cross cut, which means it gets fixed once in both disciplines with the same move. Use a dual trigger idle or log size threshold or max staleness and treat the consolidation backlog as a service level objective with back pressure. Third, also high, and it’s the skeptic’s strongest point, cost just moves. It doesn’t shrink. Deferring consolidation to sleep hides the same model token bill. And on a busy agent, that bill never gets paid until reads degrade. The mitigation is that amplification triad ledger from the last segment, which forces a hot path versus background split. So deferral can’t disguise the total. Deferral is a real win for latency, but you have to prove it isn’t just an accounting trick. And fourth, lossy merge destroys a needed detail. Aggressive recombination at a core stage can discard the one detail a later query needed. The mitigation, again, is provenance reversible until archived, plus treating consolidation aggressiveness as an evaluated knob, not a guess. There’s one design rule the premortem extracts that neutralizes most of this cluster at once. Every forgetting or merging operation is reversible until archived and carries provenance, plus the policy that triggered it. The takeaway. A sleep system without provenance is not a memory system. It’s a confabulation engine with good intentions. Build the provenance first, then build the dreaming. So to recap, biological memory consolidates offline during sleep, not at the moment of experience, and that two speed split, fast, cheap hippocampus and slow general neocortex ports cleanly into agent memory. A dumb append-only wake log plus a scheduled batch sleep pass that replays, recombines, and extracts rules no single trace contained. It’s not reflection. It’s not dedupe. It’s not decay. The difference is off path and whole period. And it’s structurally the same operation as storage engine compaction. The one thing to watch, whether anyone runs the recombination versus dedupe ablation honestly, because that’s the experiment that tells you if the dream is real or just compression in a costume. The one concrete action. If you’re building memory today, separate your right path from your consolidation path now. You can put provenance on every merge, even if you never build the sleep phase. That single split is what makes dreaming safe later. Next time on the Research Frontier, another direction. This was episode six.

The Agentic Memory Research Frontier, two of five.

Picture a government records office, the kind with rows of filing cabinets and a clerk who has been there for 30 years. Nobody in that office keeps a folder because it got opened a lot last week. Nobody throws one out because it has gone quiet. There is a printed schedule on the wall. It says, tax records, keep seven years, then destroy. Personnel files, transfer to the archive after the employee leaves. Board minutes, keep forever.

And stamped across one drawer in red is the phrase that overrides everything else, legal hold. Those files are under litigation. They do not move. They do not get shredded. They do not age out, no matter what the schedule says, until a lawyer signs off. That clerk is doing something every agent memory system in the field today cannot do. She is deciding what to keep by the kind of record it is on a clock against a published policy. Thank you. Not by how often it gets read. Not by how recently it was touched. Not by a judgment call made fresh each time. This episode is about stealing her playbook. Welcome back to the Research Frontier sub-series. Last time we looked at one cutting-edge direction. Today we take another. And this one comes from a discipline most machine learning people have never opened a textbook on. Library and archival science. Records management. Here is the setup. Every forgetting mechanism in the agent memory system. Every memory stack right now decides what to keep on one of three axes. Cache systems keep by access frequency. Forgetting curve systems keep by recency. And the current frontier keeps by an LLM looking at each item and making a judgment call. The claim of this episode is that all three are measuring the wrong variable and that a 70 year old idea from archival appraisal theory gives you a fourth axis that none of them can express.

Over six segments, we will cover the core idea. And its metaphor, the actual mechanism, how it differs from everything that came before it, the interdisciplinary lineage it descends from, how you would evaluate it without fooling yourself, and the open risks of building it. Let us get into it.

Start with the core idea because the metaphor does most of the work. Archivists have a concept called a records retention schedule. It is a published versioned policy that maps each class of record to a disposition. Destroy. After. Some number of years, transfer to a cold archive, send for review or retain permanently. And it has one more piece, an override called a legal hold, which freezes any record under litigation or audit, regardless of its age or its class. Now apply that to agent memory. The proposal is to give every stored memory what you would call a records disposition authority. You classify each memory into a record class at the moment it is written, then a content type keyed schedule decides when that memory is destroyed, archived, or pinned. Not access frequency, not recency, not an LLM’s per-item judgment. The schedule runs on a clock, against the class, exactly the way a government agency dispositions paper. Here’s the contrast that makes it click. A cache keeps the hot tool call log because it gets read constantly and drops the cold approved decision because nobody touches it.

A record schedule does the opposite, on purpose. It says destroy all transient data. It says destroy all transient tool call logs after 30 days, even if they are read constantly, and keep that approved decision forever, even if it is never read again. Those two sentences are trivial to state in a retention schedule and literally impossible to state in any frequency or recency scheme. That is the tell that you are working on a genuinely different axis. There is a second payoff that matters just as much. The schedule itself becomes a durable, shared, multi-session governance substrate. It is a single artifact that every agent and every session reads, living outside any one agent’s evolving private state.

Compare that to the dominant pattern, where each agent quietly evolves its own memory on its own terms. The schedule is the opposite of that, shared, published, external, the same for everyone.

The takeaway for this segment, retention should be a property of the kind of record, decided by a published policy, not a property of how the record happens to get used. Once you see retention that way, you cannot unsee how much of the field has the variable wrong. Let us get concrete about what you would actually build, because the idea only earns its keep if the machinery is buildable.

First, record classes. Every memory gets typed at write time into a class. Decision, observation, tool call log, derived schema, user asserted fact, and so on. Crucially, classification prefers cheap mechanical signals, the structural source it came from, the channel it arrived on, the schema it matches. You invoke an LLM only for genuinely ambiguous content. This is a deliberate design boundary. The policy is plain mechanism, and the model is restricted to the narrow act of classifying ambiguous membership. The class schema is the layer everything else keys on, and it is directly analogous to what Mark Musen and colleagues built with SITR, machine actionable templates for metadata, the work that makes data findable and reusable in the fair space. A record class is just that kind of machine actionable template, applied to memory. Second, the schedule itself. It is a version table keyed by class, mapping each class to a retention period, a disposition action, and an archive target. The disposition actions are the archival science set, destroy, transfer to archive into a cold, cheap, rarely read tier, review, and permanent. And the disposition gets evaluated on a schedule, a periodic sweep, never on access. That is the explicit inversion of cache eviction, restated as a running process.

Third, the legal hold, or PIN. It is an orthogonal override. A pinned record is never destroyed or archived, regardless of class or age, until the hold is lifted. This is the one mechanism with no analog anywhere in a frequency, recency, or LLM scheme. There is simply no way to say freeze this indefinitely against all other policy in a decay model.

Fourth, the substrate is shared, versioned, and shared. This means that the disk is versioned and auditable. The schedule is one durable artifact all sessions read, and it is versioned so disposition is reproducible. Think of the versioned object work like HR and colleagues got-git-but-for-objects. Every disposition emits a provenance record, naming the policy version and the class that decided it, so the question, why was record X destroyed or kept is actually answerable. That rides on coarse-grained provenance of the kind Fotis, Seletis, and colleagues from system logs in one provenance, built for observability and auditing. And the durable store itself is well-trodden ground. Carl Legault’s and colleagues’ Fedora architecture for complex objects and their relationships is the incorpus instantiation of exactly this kind of store. The fifth piece is the safety valve. Disposition is reversible until archived. The default ordering is soft delete, then a grace window, then transfer to archive, and only then a hard destroy. Borrowing the machine-unlearning community’s framing, the final destroy should be able to prove the record is gone, but you only reach it after the reversible stages, so a misclassification is recoverable rather than fatal. The takeaway? This is not a research toy. Class schema, version table, periodic sweep, pin override, provenance log, reversible until archived ordering. Every piece maps to a known, buildable component. Now the part that earns the episode, how this differs structurally from everything else in the forgetting literature. Because at a glance someone will say, isn’t this just eviction with extra words? It is not, and the differences are precise.

Against cache eviction, the work of Pengcheng Li and colleagues on learning forward reuse distance, or Sami Alibed and colleagues R.L. Cash. Eviction retains by access and reuse, and it drops on a miss. A record schedule retains by class policy and dispositions on a clock. A frequently read record can be scheduled for destruction. A never read one can be permanent. It is the opposite control variable.

Against decay and forgetting curves, Wan Junjong and colleagues, memory bank with its Ebbinghaus decay. Decay forgets by a recency formula, and it cannot express keep forever even if never read, nor destroy on schedule even if popular. Retention here is policy on class, not a function of time since last touch. Against LLM judge consolidation, this is the end of the story. This is the headline. Wang and colleagues sage with its add merge ignore novelty gate, and Kang and colleagues Memreader with its value, ambiguity, and completeness appraisal. Those systems re-judge or reappraise every item with a model. A record schedule applies the same class rule every cycle. The keep or destroy decision becomes governance, not per item model judgment, which means it is reproducible, explainable, and this is the crucial word, stable across model upgrades. Swap the underlying rules. The key to this is to make sure that the system is stable across model upgrades. Swap the underlying rules. The key to this is to make sure that the system is stable across model upgrades. The key to this is to make sure that the system is stable across model upgrades. The underlying model and sage and Memreader can change their minds. The schedule does not.

Against per-agent evolving memory, Jang and colleagues to Tsubasa, Cheng and colleagues Memsquared evolve. Retention authority here is shared and external. No single agent can unilaterally destroy a shared record, and it is worth contrasting with Wang and colleagues PSI, shared state as the missing layer. PSI shares state per person. A record schedule shares disposition policy per record class. Different and broader access of sharing. And against the whole RAG and Knowledge Graph memory family, Park and colleagues, Generative Agents Memory Stream, Zep and HippoRAG graphs, Mem0’s extraction pipeline, the CoALA scaffold. Here is the key move. A retention schedule is orthogonal and composable. Those are read models and capture pipelines. A schedule is the disposition layer that sits over whatever read model you already have. CoALA names the memory types, records management, supply, and control of the data. It is the very piece CoALA leaves to the model. Now the dissent, because there is a real one. Someone will argue a per-item LLM judge is strictly more expressive than a fixed schedule. It can catch the special case the policy author never anticipated. True. But that expressiveness is exactly the instability the schedule is trading away on purpose.

The takeaway. When you want to keep or destroy decision, you can audit, reproduce, and defend. After a model upgrade, you want governance, and you accept that it is less clever than a fresh judgment each time. That is a feature.

Where does this come from? Almost none of this lineage is in the arcs of corpus, which is precisely why it is worth an episode. It comes from archival science and records management. Start with the intellectual root, Theodore Schellenberg, whose 1956 book, The Appraisal of Modern Public Records, drew the foundational distinction in the field. Primary value, the value of a record to the activity that created it, versus secondary value, its evidential and informational value to later users. Appraisal, in Schellenberg’s sense, is the act of deciding what is worth keeping by class and by value, not by use. That is the deep root of class-keyed retention. And here is the sharp irony for our field. The closest in-corpus analog to appraisal is exactly the per-item LLM gating of MemReader, which is the thing class-keyed readers need to be able to use. which is the thing class-keyed readers need to be able to use. which is the thing class-keyed readers need to be able to use. The field reinvented appraisal as a model call, when archivists had already turned it into a published schedule. Then the standards. ISO 15489 is the records management standard. DoD 5015.2 is where retention schedules, disposition, and legal hold in eDiscovery are defined as concrete operational artifacts. These are not theory papers, they are specifications a real records office implements, which is why the mechanism in Segment 2 feels so buildable. Somebody already specified it. Then the metadata and bibliographic side, and this is where Library Science Proper comes in. FRBR, the Functional Requirements for Bibliographic Records, Dublin Core, and RDA. These define record classes and the descriptive metadata a schedule keys on. The Incorpus Cousin, again, is FAIR and SETR, Musin’s Machine Actionable Metadata Templates, which are the record class schema layer in modern form. Then Digital Preservation Architecture, the OAIS Reference Model, ISO 14721, plus Persistent Identifier and Write-Once-Read-Many Archive Practice. That literature supplies the Transfer to Archive tier and the Durable Store Contract. Fedora, again, is the Incorpus Instantiation. And finally, Knowledge Management gives you the organizational framing.

James Walsh and Gerardo Ungson’s work on organizational memory and Daniel Wegner’s Transactive Memory, both describe the importance of organizational framing. They also describe memory as a shared institutional asset with retention norms.

That is exactly the durable shared substrate reading. Memory is not a private thing each agent grows. It is an institutional asset governed by published policy. The through-line across all of it, retention is a published, class-keyed, externally governed policy decided by appraisal of kind and value, not by an individual reader’s moment-to-moment judgment. The takeaway for this segment, the agent memory field, has a habit of reinventing library science as a neural network. Read the librarians first. Now the measurement trap, because a good idea dies on a bad benchmark.

How would you actually test a record’s disposition authority? And where is the trap? The task suite is a governance and compliance scenario. You inject records of mixed classes over a long horizon, and you annotate each one with a ground-truth disposition oracle, the correct destroy, keep, or archive outcome at every timestamp. Then you layer in the adversarial cases the schedule has to survive. A legal hold applied mid-life, a reclassification event, and a schedule version change that should, or sometimes should not, retroactively alter outcomes. Now, no public benchmark carries disposition ground truth. So this has to be a synthetic generator. And that is the trap. Synthetic data is easy to overfit to. The defense is to pair it with a real longitudinal venue. Zhu and colleagues, aging benchers, are the experts in the field of aging benching. The aging bench is the natural fit, because it studies how an agent’s effective state drifts over its lifespan, even with frozen weights, as it compresses history, retrieves from a growing store, revises facts, and undergoes routine maintenance. Disposition is exactly a repair and maintenance discipline. So aging bench gives you a place to test it that you did not build to make yourself look good. Now the metrics, five of them. First, disposition correctness against the oracle. This is what we call on destroy and on retain under hold. And here’s the rule that matters most. A single wrongful destruction of a held record is a hard failure, reported separately, never averaged away. You do not get to hide one shredded litigation file behind 99% accuracy. Second, and this is the headline metric, stability under model upgrade. Rerun the same horizon with a different underlying LLM. The disposition decisions must not change. Decay baselines and LLM judged baselines, drift here. Governance does not. That is the whole pitch, made measurable. Third, auditability as a binary. For every disposition, can the system name the policy version and the class that decided it, yes or no? Fourth, verifiable destruction. Borrowing the machine unlearning framing, can the system prove a destroyed record is actually gone? Fifth, storage footprint over time versus decay and LRU baselines. The baselines to beat are the obvious three. LRU style, cash eviction, Ebbinghaus decay, and an LLM judged keep forget gate. And the decisive experiment, the one that settles it, is simple to describe. Replay the same stream under a model swap and show the baselines move while the schedule holds. Run the ablations two, mechanical classifier versus LLM assisted, with and without legal hold, version schedule versus latest only, soft delete then archive versus immediate hard delete, to isolate where the value actually lives. The takeaway, the benchmark that proves this idea is not an accuracy number. It is a stability number under a model swap. Last segment, the pre-mortem, because every clean idea has a failure mode, and this one’s is sharp. The critical risk is misclassification, destroying a high value record. A decision mislabeled as a tool log gets destroyed on schedule. And now you have shredded something irreplaceable on a clerical error. The mitigations are layered. Destruction is soft first, transfer to R2, and then you’re done. The use of the circumstances is critical. Once again, the default to the belongs to No one owns. The policy itself, rotting into cruft, nobody owns. The defense is discipline. Keep the schedule versioned and small, and default denied. fault deny. An unknown class gets the longest retention plus review, so omissions fail safe, a record kept too long, rather than destructively, a record wrongly destroyed. Now zoom out because this connects to the whole research program. The program’s premortem identifies wrongful destruction as one face of a single root cause it shares with two other failures, offline consolidation confabulation, where a merge invents something false, and cost deferral failures. And the synthesized highest leverage rule for the entire program governs this sub-thread directly. Every forgetting, merging, or superposing operation is reversible until archived and carries provenance plus the policy that triggered it. Records management is where that rule is native. Soft delete, grace windows, archive tiers, legal holds, policy version provenance, those are the discipline’s own primitives, not bolt-ons. That is why retention scheduling is the program’s primary goal. That is why retention scheduling is the program’s canonical answer to the durable shared governance crosscut. And there is one composition risk worth naming for whoever builds next.

There is usually a consolidation engine in these systems, the sleep cycle or log-structured compaction that merges and prunes memory. That engine must consult the schedule before it merges or destroys anything. Compaction may tombstone an archive, but it must not hard delete a record that is under legal hold or still inside its grace. And that is why we are in a state of loss. And we are in a state of loss because we are in a state of loss because we are in a state of loss. And we are in a state of loss because we are in a state of loss because we are in a state of loss. Get that ordering wrong and you reintroduce the critical risk through the back door.

Records management is the policy input to consolidation, not a competitor to it. A clarifying contrast on the way out. The machine unlearning literature, the right to be forgotten work of Tam Nguyen and colleagues, Graves and colleagues amnesiac machine learning, Gennart and colleagues making AI forget you, fights to delete data from model weights, which is hard and only verifiable by attack. A record schedule governs an external durable store where deletion is tractable. Soft delete, archive, destroy. Same compliance goal, far easier and more auditable locus. The takeaway, build the disposition layer over your external store first because it is the strictly easier and more reproducible win and wire it into consolidation before consolidation can race it. So, the recap. Records management gives agent memory a fourth retention axis. The field is missing. Keep by the kind of record, on a clock, against a published version shared policy with a legal hold override and a reversible until archived safety valve. It is governance, not a fresh judgment call, which is why it survives a model upgrade when decay and LLM judges drift. The one thing to watch is the stability under model swap benchmark. That is the experiment that will either prove this or sink it. And the one concrete action. If you are building a memory system. Go read Schellenberg and ISO 15489 before you write another eviction heuristic. The librarian solved your problem in 1956. That is The Research Frontier, episode seven. See you next time.

The Agentic Memory Research Frontier, 3 of 5. Picture a database engine in the quiet hours. All day it has been taking writes, dumping each one into a small in-memory buffer, and immediately saying, yes, done, next. No sorting, no cleanup, no thinking. Then, in the background, off the path of any user request, it starts a sweep. It takes the recent writes and merges them down into bigger, sorted, older layers. As it merges, it throws away the versions that newer writes have already replaced. It deduplicates, it compacts, the store gets denser, reads get faster, and nothing the user did had to wait for any of it. Now, picture an AI agent at the end of a long day of conversations. Same shape exactly. The fast buffer is the agent’s wake log, the background sweep that merges, deduplicates, and generalizes the day’s traces into something compact and durable. Storage engineers call that compaction. Cognitive scientists call it consolidation. This episode argues they are… almost literally the same operation.

Welcome back. This is episode eight. This is the third episode in our Research Frontier sub-series, where each episode takes one cutting-edge research direction and follows it down to the mechanism. Today’s direction sits squarely at the hardware-software storage interface, and it makes a claim that is provocative because it is so literal. An agent’s memory should be built like a log-structured merge tree, an LSM tree, and the thing we keep calling it is a memory. What we keep calling memory-consolidation is exactly the thing storage systems have been calling compaction for 30 years.

Here is the route. First, the core idea and the metaphor. Why compaction is consolidation. Then the mechanism in detail, the levels, the triggers, the dial. Then how it differs structurally from everything the agent memory field is doing today. Then the interdisciplinary lineage, storage classics on one side, cognitive science and records management on the other. Then how you evaluate it, and the measurement trap waiting inside. And finally, the open risks and what gets built next. Let’s go. Start with the claim, because it is bolder than it sounds. The proposal is to model an agent’s memory as a log-structured merge tree. Every interaction is written cheaply and immediately into a fast in-memory append structure called the memtable, and the expensive work, deduplicating near-identical traces, merging them, summarizing, extracting schemas, etc. All of that happens later in the background as a storage engine operation called compaction. The claim is structural and almost defiantly literal. Compaction is memory consolidation. Not a metaphor for it. The same operation. Walk the mapping because it is uncannily clean. When a database engine sweeps recently written records down through sorted levels of exponentially increasing capacity, merging and discarding obsolete versions as it goes, it is doing the same off-path batch transformation. That’s what compaction is. Now there’s a couple more things to look at. While we’re away from control, let’s look at a couple more things. The agents wake log is the level 0 memtable. Recent, fine-grained, episodic traces live in the low levels. Older, coarse, generalized semantic memory lives in the high levels. The agents wake log is the level 0 memtable. The agents wake log is the level 0 memtable. The agents wake log is the level 0 memtable. Transfer out to a cold archive is the highest level of all.

The whole episodic to semantic coarsening gradient that memory researchers draw by hand falls out of the level structure of a storage engine for free.

Now the contrast. the part that makes this more than a cute analogy. In the agent memory field today, consolidation is a judgment call. A language model decides at write time or read time what to keep and what to merge, one item at a time, and you tune it with a cron schedule and a prayer. In an LSM tree, the cost of consolidation is not a mystery. It is the read, write, and space amplification triad, three numbers that storage systems have measured and traded against each other for three decades. The canonical survey by Chen Luo and Michael Carey, LSM-based storage techniques, lays out the standard memtable-to-leveled or tiered-to-levels model, and that model maps directly onto the episodic-to-semantic gradient. The point is not that the storage version is fancier. It is that the storage version has a cost model, and the language model version has a vibe. The takeaway, when you find yourself reasoning about agent consolidation as if it were a brand-new agent, is that it is a cost model. If you have a brand-new design problem, stop and ask whether you are re-deriving compaction. Because if you are, there is 30 years of measured cost model engineering you can simply pick up instead of guessing. Now the machinery, because the whole argument lives in the details.

Four moving parts. First, the level zero memtable is the wake log. Writes hit a fast-in-memory append structure. No model curation, no deduplication, no merging on the hot path. It is order one cheap, and crucially, it spends zero language model tokens at write time. Each trace just carries some cheap salience metadata, a surprise or novelty proxy, and embedding, so later stages have something to prioritize on. Second, background compaction is consolidation. A leveled scheduler merges level zero into level one, into level two, on down. And here is the most useful single result in this whole direction. Subhadeep Sarkar and colleagues, in constructing and analyzing the LSM compaction design space, decompose compaction into roughly five primitives. The trigger, when to compact, the data layout, leveled versus tiered, the granularity, how much to merge at once, the data movement, which runs participate, and the eligibility, which entries survive. Every one of those choices trades write amplification against lookup cost against space amplification against delete performance. That is the payoff in one sentence. The consolidation policy is a point in a measured design space, not a language model judgment call. Third, the central knob is the leveling versus tiering dial. Both Luo and Carey’s survey and Sarkar’s design space paper formalize the classic contrast. Leveling gives you lower read and space amplification at the cost of higher write amplification. Tiering inverts it. Translate that into agent terms, and it reads as, how aggressively do we rewrite memory to keep reads cheap? That is precisely a leveling versus tiering decision.

And it is exactly the ablation an agent memory consolidation engine should be sweeping. And here is where the real consolidation happens at each merge, near-identical traces get deduplicated. Igor Nunes and colleagues .hash gives you a cheap set similarity gate to decide what counts as a near-duplicate. Survivors get bundled by key, and at the higher levels they get passed to schema extraction, one language model call per cluster deferred and amortized rather than paid on lightweight copies. rather than paid on every single write. Lower levels stay fine and episodic. Higher levels become coarse and semantic. The contrast worth holding on to. Heng Thakkar and colleagues, ElmoTune V2 uses a language model to auto-tune the compaction, flush, and cache configuration of a real storage engine. That demonstrates the exact split this whole program wants. The model picks the knob offline. The engine turns it deterministically. The takeaway, let a model choose the policy, but never let it execute the merge by hand, one item at a time, on the hot path. Let me line this up against the prior art, because the contrasts are sharp and each one teaches something.

Versus online extraction, the Mem0 and A-MEM family. Prakhar Chikara and colleagues, Mem0 runs language model extraction and consolidation right on the write path. Wujiang Xu and colleagues, A-MEM dynamically links and evolves Zettelkasten-style notes through model curation. Again, both are doing by hand and per item the merge and link operations an LSM compaction scheduler does deterministically in the background. The difference is that compaction is a scheduled background sweep with a tunable policy.

The trigger and the level shape are explicit knobs that language model pipeline memory simply does not expose. A-MEM’s per-note link becomes a background level merge. Versus cache eviction, ARC and Beledi’s optimal replacement, both external systems classics. This is the sharpest contrast in the episode, so sit with it. Eviction discards on a miss. Compaction merges and densifies. Nothing gets dropped. It gets rewritten more compactly.

Eviction loses information to recover space. Compaction recovers space by consolidating. Cache theory optimizes what to throw away. LSM theory optimizes how to rewrite what you keep.

That is the whole philosophical split, and it is why this direction frames consolidation as the storage discipline that chose to densify instead of evict. Versus retrieval augmented generation and semi-parametric memory. Patrick Lewis and colleagues, original RAG bolts a growing non-parametric store onto the model with no right path maintenance at all. Compaction is exactly the missing maintenance discipline RAG never had. Versus knowledge graph memory like Zep and HippoRAG, the graph is the read model. Compaction is the right path maintenance that keeps it from bloating. Compaction is the right path maintenance that keeps it from bloating. Compaction is the right path maintenance that keeps it from bloating. Compaction is the right path maintenance that keeps it from bloating. Compaction transforms raw episodic into generalized semantic, and only then lets the subsumed raw fade. Decay is the fallback for what compaction never selected. There is one existing bridge in the corpus that nails this, and it is worth naming on its own. Liu and colleagues’ cooperative memory paging turns evicted context segments into roughly eight to 24 token keyword bookmarks, plus a recall tool, and it beats both truncation and BM25 on the Locomo benchmark. That is, read amplification reduction realized directly in agent memory, a cheap probe before you pay to fetch a full level. The takeaway, the LSM amplification metrics are not borrowed jargon. Someone already showed read amp is a meaningful, measurable quantity for agent memory. This direction has a genuinely three cornered lineage, and naming all three is what keeps it honest. The storage corner starts with the original. O’Neill, Cheng, Golick, and O’Neill published the log structured merge tree in Acta Informatica in 1996, and its whole trick was trading random writes for sequential append plus a background merge. That idea runs straight through Cheng and colleagues’ Bigtable at the 2006 OSDI conference and through Facebook’s RocksDB, the production substrate that made LSM the default storage layer of modern NoSQL systems. The read write space tradeoff was made navigable by Niv Dayan, Manos Athanasoulis, and Stratos Idreos in two papers, Monkey at SIGMOD 2017, which optimally allocates Bloomfilter memory across levels, and Dostoevsky at SIGMOD 2018, which introduces lazy leveling to open up a navigable frontier. Those are external systems classics, not in the science corpus, but they are the bedrock. The reason this is even thinkable as a continuum is Stratos Idreos and colleagues’ learning key value store design, which shows that B-trees, LSM trees, and LSH indexes are not separate inventions. They are points on one continuum, auto navigable by a cost model. That is the result that lets you place vector stores, holographic memories, and an LSM memory side by side as comparable points rather than incomparable systems. The cache replacement corner is the contrast we already drew. Megiddo and Madha’s arc and Beledi’s optimal offline replacement. Cache theory optimizes what to discard. LSM theory optimizes how to rewrite what you keep. Naming both lineages is what lets you say, precisely, that consolidation chose to densify instead of evict. And the cognitive corner is the reason we get to call this consolidation and not merely garbage collection. The complementary learning systems work by McClellan, McNaughton, and O’Reilly, plus the sharp wave ripple replay during slow wave sleep that was the subject of episode six, give the justification. The mem table is the hippocampal wake phase append log. The level gradient is episodic to semantic coarsening. The compaction scheduler is the sleep trigger. Storage supplies the mechanism and the cost model. Neuroscience supplies the justification and the recombination policy. There is a third leg people forget, records management. ISO 15489. And the DoD 5015.2 record schedules. The highest compaction level is records management transfer to archive. And a compaction pass should consult a retention schedule before it merges or destroys anything. The takeaway, this is not one field borrowing a metaphor from another. It is three disciplines that independently converged on levels merging and bounded transfer, which is exactly when porting a mechanism is most defensible. Now, the measurement, the direction this clean is also a direction that is easy to fool yourself about. Start with the tasks. You want long horizon, multi-session agent corpora, but instrumented for storage dynamics under sustained write load. Jiang and colleagues’ SEA eval was built for exactly this, durability and episodic amnesia testing. Add Locomo style long conversation question answering and then add something the real benchmarks lack, a synthetic high write trace generator that gives you ground truth control over the write load profile and the latent schemas because real benchmarks have no disposition oracle and no schema oracle. And the metrics here need both. Then instrument the literal amplification triad. Write amplification bytes and language model tokens rewritten per logical trace written. Read amplification levels touched per query plus tail read latency and cooperative memory paging gives you a concrete instrument here, the cheap bookmark probe before the fetch. Space amplification, store size versus the minimal representation. And a fourth recall quality after compaction does densifying actually hurt answer accuracy. Here is the headline falsifiable test, and it has two clauses. Can compaction hold read latency in space flat under sustained agent write load without a recall quality regression versus an uncompacted rag store? That is the first clause. The second clause is the honesty check. And it is the whole trap. Does the deferred background language model token bill stay below online Mem0 or A-MEM extraction? Because a system that defers cost to the background must still pay it. Deferral is not a discount. This is where Luo and Carey’s other paper on performance stability in LSM based storage systems earns its place. It studies write stalls and merge scheduler SLO design. And it is the evidence base for proving the deferred cost gets paid rather than simulating as backlog before any benchmarking. You can even predict the numbers. Giorgos Batsaras and colleagues Vyat supplies an analytic cost framework for multilevel key value designs so you can derive expected read, write and space amplification before you implement anything, which decorrelates the structural claim from implementation noise. And the ablations are obvious once you have the dial leveled versus tiered compaction, the read write amp dial straight from Sarkar. And from Luo and Carey. Ddup only versus Ddup plus schema extract at the high levels, which isolates the generative consolidation contribution from mere deduplication and respect versus ignore the retention schedule during compaction, which ties straight into governance. The takeaway the trap is not whether compaction makes reads fast. Of course it does. The trap is whether the bill got paid or just moved. Measure the hot path versus background cost split or you have measured nothing. Three risks, and they share a root cause, which is the most important thing in this segment. The first is compaction debt and write stall, and it is rated high. Compaction can’t keep up with the write rate level zero bloats read slow down. This is the documented LSM production failure mode. Luo and Carey attribute write stalls precisely to the mismatch between fast in memory writes and slow background IO, and they study merge scheduler design to bound it. For an agent, the translation is brutal and exact. On a busy agent, the sleep trigger never fires. The consolidation bill accumulates as backlog and reads eventually collapse. The fix is a single compaction backlog SLO with a dual trigger idle or log size threshold or max staleness plus back pressure, and you report the hot path versus background cost split so deferral can’t hide cost. And note, this is the same fix as the sleep directions. Sleep never runs risk. Solving. It once the second is lossy merge, destroying a needed detail also high. You do duplicate or summarize at a low level and discard a detail a later query needed. And because the source may already be tombstoned, the loss is silent. The mitigation is provenance pointers from every compacted row back to its source traces and soft delete, then archive, then destroy instead of hard delete. And this is where deletion being genuinely hard actually helps you in a standard way. In the LSM tree, a delete is just a tombstone that only truly persists when compaction eventually rewrites past it with no bound on how long that takes. Subhadeep Sarkar and colleagues Leith, a tunable delete aware LSM engine adds persistence, latency and space guarantees on deletes for agent memory. That is the native mechanism for tombstone don’t hard delete a deletion becomes scheduled and bounded, which is exactly legal hold and grace window semantics. The third is rated critical. And it is shared with the sleep direction. Confabulated schemas becoming durable memory. High level schema extraction invents a fact that is in no trace. And once the raw is subsumed, that hallucination is the durable, unauditable memory. The mitigation is never hard delete on consolidation, provenance on every schema row and a confabulation rate metric. The share of schema claims not entailed by any source trace. And here is the crosscutting root cause the one rule to take away. All three failures, the right stall, the lossy merge, the confabulated schema stem from irreversible, unaudited memory transformation. So the single highest leverage rule is this. Every merge forget and superpose operation is reversible until archived and carries provenance plus the policy that triggered it. The LSM tombstone leads bounded delete and the archive tier give you that natively. What gets built next is the engine that enforces it with the policy chosen by a model line and the mechanism executed deterministically. The way Thakkar’s ELMOTUNE V2 already showed for real storage. The takeaway deferral is not a discount and transformation without provenance is not consolidation. It is data loss with extra steps. So that is LSM compaction as consolidation. Write cheap to a fast log, merge in the background, course an episodic into semantic as you descend the levels and tear the oldest out to a cold archive, all governed by a measured read write space cost model instead of a cron job and a guess. Storage systems, cognitive science and records management converged on the same shape, which is exactly when borrowing the mechanism is defensible. The one thing to watch the honesty clause. Anyone who claims compaction made memory cheap has to show the deferred background token bill, not just the fast reads. Deferral moves cost. It doesn’t erase it. And the one concrete action. If you are building agent consolidation today, instrument the amplification triad and the hot path versus background split before you tune a single thing. Measure where the bill is paid until next time.

The Agentic Memory Research Frontier, 4 of 5. Picture a pool of water. You drop in a hundred recorded songs, all at once, all on top of each other, until the surface is just one churning blur. No track listing. No folders. One pool. Now somebody hums you a few bars, and you reach into that single blur and pull back the song they were thinking of. Noisy, a little distorted, but recognizable. Then you snap it to the nearest clean recording you already know, and there it is. That is not a metaphor for some far-off brain. That is, almost literally, how a class of memory systems from the 1990s actually works. You fold many memories into one fixed-size vector, and you recover any one of them by probing that single vector with a cue. The storage never grows. It just gets fuzzier as you add more. And right now, the agentic memory field is rediscovering it, the hard way, one LLM at a time. This is Episode 9. Welcome back to the Research Frontier. We have spent this sub-series on cutting-edge directions for agent memory, one idea per episode. Today’s idea is the strangest and, arguably, the oldest. It is called vector-symbolic holographic superposition, and it sits right at the join of two worlds that usually do not talk, connectionist neural representation and symbolic structure. Here’s the shape of the episode. First, the core idea and the metaphor that makes it click. Then the actual mechanism, the two algebraic operations that make it work. Then how it differs, structurally, from the one-row-per-item vector stores everyone deploys today. Then the interdisciplinary lineage, because this is genuinely a neuro-symbolic idea with a hardware payoff attached. Then how you would evaluate it without fooling yourself. And finally, the open risks, including one that is the single-highest leverage-failure cluster in our whole program. Let us get into it. Start with the claim, because it is audacious. Instead of storing each and every one of them in one place, you can store them in one place. Instead of storing each memory as its own row in a database, you fold many memories into one fixed-size high-dimensional vector. The jargon for that vector is a hypervector, and the whole point is in the word fixed. The slot does not grow when you add memories. Its footprint is constant in the number of items you pour into it. The intellectual roots here are external to our scientific corpus, so let me name them in prose. The direct ancestor is Tony Plate, who in the 1990s introduced holographic reduced representations, HRR for short. Plate gave us the core trio, circular convolution as a way to bind two concepts together, superposition as a way to pile many of them into one vector, and a cleanup memory to recover them. Alongside Plate sits Pentti Kanerva, whose sparse distributed memory from 1988, and later his hyperdimensional computing work, made the case that high-dimensional random vectors are a robust, brain-plausible computing substrate.

And behind both of them is Paul Smolensky, whose tensor product representations from 1990 were the earlier, bigger binding scheme that HRR cleverly compresses. Now why does folding everything into one vector even work? Because of a fact about high dimensions that feels like a trick. If you pick random vectors in a space with, say, 10,000 dimensions, any two of them are almost certainly nearly perpendicular. Quasi-orthogonal, the field says. They barely interfere, so you can add a lot of them together, and still tell them apart afterward, the way you can overlay many faint, nearly independent signals and still fish one back out. Here’s the honest contrast, and it is the heart of the whole episode. A normal vector store is exact, but linear. Every memory is its own row, recall is precise, but the index grows forever. Holographic superposition is the opposite corner of the design space. Approximate, but constant. You give up exactness, you accept some crosstalk noise, and in exchange, you get a memory whose size is bounded by its dimensionality, not by its history. Nothing crashes when the pool fills up. It just gets blurrier. The takeaway for this segment, holographic memory is not a better database. It is a different trade. Constant size, paid for in exactness. Hold on to that sentence, because everything else is a consequence of it. Now the mechanism, because the magic is just two operations in a dictionary. Let me build it piece by piece. First, the dictionary, which the field calls a codebook, or item memory, or cleanup memory. Every primitive concept, every entity, every role, every relation, gets assigned one random hypervector. Curie gets a vector. The role subject gets a vector. The relation discovered gets a vector. Because of that quasi-orthogonality we just talked about, all these atoms start out barely overlapping. Operation one is binding, and plate’s classic choice for it, is circular convolution. Binding takes two hypervectors, and ties them into a third, that is dissimilar to both, but is invertible, and preserves distances. So you can compute subject bound to Curie, and that product is a brand new vector, that means, roughly, this filler plays this role. There are other binding schemes. Kanerva’s map family, multiply add permute, uses plain element-wise multiplication. Frequency domain HRR, multiplies complex phases. And there is newer work I will name. Mahmudul Alam and colleagues derived a Walsh-Hadamard based linear binding operator that lives in real space, is associative, commutative, and has a clean inverse, which matters a lot when you want differentiability and numerical stability. Operation two is bundling, and it is just addition. You superpose many bound pairs by adding them up, usually with a normalization step. Subject bound to Curie, plus relation bound to discovered, plus object bound to radium, and so on. The sum is similar to each of its parts. That is what lets one single vector genuinely contain many memories at once. So how do you read it back? Recall is unbind, then clean up. To ask who is the subject, you convolve the bundle with the inverse of the subject role. Out comes approximately Curie, plus a sum of crosstalk from every other binding in the pile. That noisy estimate is not clean enough to use directly, so you run a nearest-neighbor match against the codebook, and snap it to the closest real atom, and you read off a confidence from the signal-to-noise ratio. And here is a lovely connection. That clean-up step is literally a k-nearest-neighbor search against a dictionary. Which means holographic memory composes naturally with the kNN composite memory work of Angela Phan and colleagues. The codebook just is the clean-up memory. They are not rivals. One is the substrate, the other is the snap-to-clean step. The takeaway? There is no model call anywhere in that loop. Binding, bundling, unbinding, and a nearest-neighbor snap. It is deterministic algebra. That property is going to matter enormously in two segments’ time. Let me make the structural difference concrete, because this is where you decide whether to care. Against the dominant shape of agent memory today, the one row per item store, holographic superposition changes two costs at once. Today’s systems, the original rag of Patrick Lewis and colleagues, the kNN composite memory of Phan and colleagues, the production pipelines built on top, all share a shape. Storage grows linearly with the number of items. And recall is a retrieve-then-read step, a top-k approximate nearest-neighbor search over an index that keeps getting bigger. Better retrieval helps. Hybrid lexical plus semantic matching, the work of Sarkozy and colleagues, and late interaction indexing, like ColBERT from Omar Khattab and Matei Zaharia, both make that step sharper. But they do not change its shape. More memory still means a bigger index and more candidates to score. Holographic memory attacks the shape itself. A slot’s footprint is constant in the number of items bundled into it. Recall is an algebraic unbinding, not a search over rows. For an agent piling up thousands of small associative facts per entity or per session, that is the whole promise. A memory bounded by dimensionality, not by history. There is also a quieter difference against knowledge graph memory. In a graph store, a relation is an explicit edge. In a bundle, the relation is bound algebraically into the vector, and you can compose relations on the fly with vector operations, at the cost of edge-level exactness. But now the contrast that keeps this honest, and it is a genuine dissent. Do not assume a one-row store is the dumb, high-capacity, poor option. Modern, continuous Hopfield networks store an exponential number of patterns and retrieve in a single step. And famously, their update rule is mathematically equal to transformer attention. That is the result from Hubert Ramsauer and colleagues, the paper titled, Hopfield Networks is All You Need, and from the large associative memory work of Dmitri Krotov and John Hopfield. So a vector store plus attention is already an associative memory, and a near-exact, capacity-rich one at that. Which means holographic superposition is not unambiguously better. It occupies the opposite corner. Dense Hopfield bounds one edge. Exact, one shot, capacity-rich. Vector symbolic memory bounds the other. Constant size, capacity graceful, lossy. An agent memory architect is choosing a point between those two corners. The takeaway, and write this one down, the exactness gap is the quantity you must measure, not assert. If you cannot put a number on how much accuracy you traded away for constant size, you have not actually evaluated this idea. You have just admired it. This segment is about lineage, because where an idea comes from tells you what it is actually for. And this idea is squarely neuro-symbolic. It sits at the join of connectionist representation, vectors, gradients, distributed codes, and symbolic structure, roles, fillers, relations. The deep justification is something cognitive science calls the binding problem. How does a connectionist system represent role-filler structure? Who did what to whom without a combinatorial explosion? The modern statement of why that matters is the paper by Klaus Greff and colleagues on the binding problem in artificial neural networks. Their argument is the conceptual warrant for this whole approach. If you want a network to generalize compositionally, you need real role-filler binding. Not just opaque embeddings that smear everything together. Holographic memory is, in a sense, an answer to Greff’s challenge. It stores memories as bound structures you can take apart, rather than as flat vectors you can only compare. And the surveys that map this whole territory are worth naming, because they are your entry points. Denis Kleyko and colleagues wrote a two-part survey of vector symbolic architectures and hyperdimensional computing. Part one lays out the operation set and the model zoo. Part two covers applications, cognitive models, and the open challenges, including exactly the capacity and crosstalk problems we have been circling. If you read one thing after this episode, read part one. Now, the crosscut, the part that makes this more than a math curiosity. There is a hardware lineage here that a row-based vector database simply cannot access. Distributed holographic codes map naturally onto in-memory and neuromorphic hardware. Abbas Karunaratne and colleagues demonstrated hyperdimensional computing running inside memristor arrays in analog memory, robust to device noise, with real winds in energy and area. And Kleyko and colleagues, in a separate paper, frame vector symbolic architectures explicitly as a computing framework for emerging hardware. Why does that matter? Because it substantiates the claim instead of leaving it as a vibe. Neurosymbolic representation buys hardware efficiency. The same property that makes these codes robust to crosstalk, distributedness, also makes them robust to noisy analog devices and lets the binding and bundling run as cheap parallel operations on substrates where a conventional ANN index would be miserable. The takeaway. This is not just a clever data structure. It is a representation whose physics line up with where efficient hardware is going. If you only evaluate it on a CPU against a vector index, you are missing out. You are measuring it on the one substrate it was never optimized for. So how do you test this thing honestly? Our program scopes it as the exploratory substrate lane and it is gated on a pre-registered capacity result. That phrase, pre-registered, is doing a lot of work and I will come back to why. Start with the tasks. Three of them. First, a capacity stress recall task. Load k structured memories and measure recall as k grows. That is the canonical vector symbolic capacity curve and it is the whole point of the exercise. Second, a cleanup recall task on real agent facts, entity attributes, simple relations drawn both from our synthetic oracle generator and from a long horizon benchmark such as SEA EVAL, the self-evolving agents benchmark from Zhang and colleagues. Third, a hybrid routing task on quantities and dates with gist and associative records. Now the metrics and notice that every one of them is designed to make the cost falsifiable. Recall at one versus bundle load k at fixed dimension. That is the graceful degradation curve. Bytes per memory against a one row store at matched accuracy. Recall latency, vector operations versus an approximate nearest neighbor search. Then the one that matters most, the exactness gap, the accuracy delta of the setup queries. That is the cost the program has to quantify out loud. And a hardware cost axis, operations per byte and an energy proxy citing that in-memory hyperdimensional work so the efficiency claim is measured and not merely asserted. The baselines have to be fair and there is a subtlety here. You compare against an exact one row vector store but at two different budgets, matched bytes and matched items. The interesting regime is same bytes, but you are hunting for the crossover k, the point where holographic storage starts winning on bytes per memory while still clearing a recall threshold. That crossover is the constant size payoff point and if it does not exist within any plausible operating range the idea loses. The theory tells you roughly where to look. Bundling k items into a fixed dimension vector produces interference that grows with k and past a threshold the signal for any one item drops below the crosstalk floor just fails. The capacity theory for how much you can reliably bind comes from Frady and colleagues on variable binding for sparse distributed representations. And the catalog of how encoding choices move that capacity curve comes from the hypervector encoding survey of Eigen and colleagues. So ablate the codec frequency domain HRR versus MAP versus that Walsh Hadamard linear scheme. Ablate salience weighted versus uniform bundling. Does importance weighting actually protect the memories you care about under pressure? Ablate with and without the codebook cleanup and report the exactness gap per record class so the nish, gist yes, IDs no, is honestly bounded rather than oversold. The takeaway. Pre-register the capacity curve threshold before you run it. The failure mode this idea invites is exactly the one our measurement crisis episode warned about admiring a mechanism without ever pinning its cost. Decide the number that counts as success first, then go measure. Last segment, the risks drawn straight from the program pre-mortem. There are four, and the third one is the one that should keep you up at night. Risk one, rated high. The exactness gap is too large to be useful. Superposition crosstalk makes point recall unreliable but agents need exact facts, dates, identifiers, IDs. If that gap is wide, holographic memory is a curiosity. The mitigation is hybrid routing. Use the holographic substrate for associative and gist recall, and a plain exact store for the record classes that must be exact. The record class typing routes the choice, and the evaluation reports the gap explicitly so the niche is bounded, not sold past its limits. Risk two, rated medium. Engineering immaturity. HRR codecs, cleanup memories, capacity tuning. These are research grade, not turnkey. And differentiable HRR was historically plagued by numerical instability. The mitigation is to keep this in the exploratory lane and adopt the stabilized versions. The differentiable, numerically stable HRR of Ganesan and colleagues, the learning with holographic reduced representations work, and the Walsh-Hadamard linear codec from Alam and colleagues. Then gate further investment on that pre-registered capacity result. Now the third risk, and this is the highest leverage failure cluster in the entire program. Bundling is lossy, and it is not cleanly reversible. Once a binding has faded below the crosstalk floor, it cannot be recovered, and a superposed slot carries no per-item provenance by default. You poured everything into one pool, and the pool does not remember which drops came from where. That collides head-on with the program’s governing rule. Every forgetting, merging, or superposing operation must be reversible until archived, and must carry provenance plus the policy that triggered it. You keep the source traces under a retention schedule, soft delete, never hard delete, so a bundle can always be re-derived from its provenance. And you treat the hypervector as a cache of consolidated schemas, not as the system of record. That single move changes the whole proposal. Holographic superposition becomes a densification layer sitting on top of an auditable trace store, not a replacement for it. The pool is fast and small and lossy, the trace store underneath is slow and complete and forever. The fourth risk is quieter but real. Capacity miscalibration. Set the dimension or the bundle ceiling by guesswork, and you risk silent recall collapse the moment a slot quietly exceeds capacity, with nobody noticing. The mitigation is to monitor per-slot signal-to-noise ratio as a first-class telemetry signal, and trigger a spill or a re-slotting before you breach the crosstalk floor. The takeaway? Holographic memory is safe to build only as a layer, never as the bottom. Cache the schemas, keep the trace, watch the SNR. Build it that way and it densifies your memory. Build it as the source of record and it quietly eats your provenance. So to recap. Holographic superposition folds many memories into one fixed-size vector using two operations, binding and bundling, and reads them back by unbinding and snapping to a codebook. It trades exactness for constant size, it descends from Plate and Kanerva and Smolensky, and its distributed codes pay off on neuromorphic hardware. But it is lossy, it is not natively reversible, and it must be evaluated against a pre-registered capacity curve with the exactness gap reported out loud. One thing to watch. Whether anyone publishes that crossover K, the bundle load where constant size storage actually starts to win. That number turns a beautiful idea into a usable one. One concrete action. Start by reading Kleyko’s survey, part one, and design the capacity stress task before you write a line of codec.

The agentic memory research frontier, five of five. Picture a bird in a meadow full of berry bushes. It lands on the first bush, eats the easy berries near the outside, and then the picking gets slower. Every new berry takes longer to find than the last. At some point, the bird faces a question it answers without a single conscious thought. Keep stripping this bush or fly to the next one? Behavioral ecologists have a precise rule for what that bird should do, and it turns out to be the same rule your retrieval system should follow when it reads memory.

Most agent memory today does not follow it. It does the equivalent of telling the bird, eat exactly 10 berries from every bush, no matter how full or how empty. 10 berries on the lush bush, 10 on the bare one.

That is fixed top K retrieval, and it is blind to whether the patch is rich or depleted. This episode is about replacing that blindness with a forager that knows when to leave. Welcome to episode 10. This is the last stop on the Research Frontier sub-series, and it is the one that comes from the furthest outside the language model world. The previous Frontier episodes stayed mostly inside the corpus of agent memory papers. Today, we leave it almost entirely.

The lineage here runs through behavioral ecology, through information science, through classical information retrieval, and through optimal stopping theory. And only at the very end does it touch a language. The idea is to treat recall not as a database query you run once, but as foraging across a landscape of food patches. An agent reads memory until a patch is depleted, then decides, dig deeper, move on, or go home. The decision is made from cheap, non-language model signals, never a model call per step. Over the next six segments, we will cover the core metaphor, the mechanism, how it differs from both fixed K retrieval and the expensive model-judged loops, the four-discipline lineage behind it, how you would actually evaluate it without fooling yourself, and the open risks.

Let us forage. Start with the claim, because it reframes the whole problem. The claim is that an agent’s memory is not a table you select from once. It is a landscape of patches, and retrieval is an animal moving through that landscape, eating until a patch stops paying off, and then deciding what to do next. A patch can be a semantic cluster, a storage team, a frontier, a slot in a structured store, an archive level, anything that already partitions memory. Inside a patch, the items come back ranked, and the forager reads down that ranked stream one hit at a time. The metaphor is not loose. It is borrowed wholesale from information foraging theory, which Peter Pirolli and Stuart Card laid out in Psychological Review in 1999, and which Pirolli expanded in his 2007 book. Pirolli and Card took a model of how animals hunt for food, and applied it to how humans hunt for information, on the web, in documents, across a search interface. They gave us the vocabulary of information sent, of patch leaving, of diminishing returns inside a patch. That is the direct intellectual parent of treating recall as foraging. And underneath their work sits an even older result we will come back to, Eric Charnov’s marginal value theorem from 1976, the actual rule the berry-eating bird is following. Now the contrast, because the metaphor only matters if it changes behavior. The dominant alternative is fixed top K retrieval. The original retrieval augmented generation recipe from Patrick Lewis and colleagues in 2020, and the realm work from Kelvin Gu and colleagues the same year. Both retrieve a constant number of items regardless of the query. A trivial single fact lookup and a hard multi-hop synthesis get the same K. That is blind in both directions at once. On the easy query, fixed K over-retrieves and wastes context on berries you did not need. On the hard query, it under-retrieves and stops before the one crucial item buried three patches over. The forager metaphor says K should never be a constant. It should be whatever the landscape pays for on this particular query. The concrete takeaway, stop thinking of recall as a single query with a fixed result size, and start thinking of it as a walkthrough patches that ends when the walking stops, being worth it. The size of the result is an output of that walk, not an input you set in advance. The metaphor is only useful if you can compute the leaving decision cheaply. This segment is the mechanism, and the heart of it is one estimate. After you read item I, what is the marginal expected gain of reading item I plus one, and is that gain still above the cost of continuing? The rule for when to leave comes straight from Charnov’s marginal value theorem.

Charnov, writing in Theoretical Population Biology in 1976, proved that an optimal forager should leave a patch at the exact moment its instantaneous intake rate drops to the long-run average rate of the whole habitat. Leave when this bush is paying out no better than an average bush would, once you account for the travel time to reach the next one. The controller here applies that literally. It maintains a running marginal value estimate, and when that estimate falls below the switching cost, the modeled token and latency cost of opening another patch, it leaves. If some other patch’s expected opening gain beats the switching cost, it switches. Otherwise, it stops. What makes this practical is that the marginal value estimate is built from three families of cheap, non-language model signals. The first is similarity score decay. In a well-ordered patch, the relevant scores of successive hits only go down, and the slope of that decline is a direct proxy for diminishing returns. That is the foraging curve made literal, the gain rate falling toward the environment average. The second is novelty against the working set, how much genuinely new information each hit adds versus what you already hold. This uses classical diversity machinery, determinantal point processes from Alex Kulesza and Ben Taskar, the near-duplicate-aware summarization work of Sangwoo Cho and colleagues, the submodular coverage of Jacob Schreiber’s apricot library, and cheap set similarity dedupe, like the DotHash method of Igor Nunes and colleagues. A patch returning near-duplicates is depleted even when its raw similarity is still high. The third family is information gain proxies, mutual information scores of the kind Mario Baraha and colleagues use for feature selection, and the surprise and curiosity menu surveyed by Arboret and colleagues and pioneered by Deepak Pathak and colleagues, which estimate how much an item reduces uncertainty about the answer, regardless of surface similarity. The contrast worth drawing, none of these three signals is a model call. They are arithmetic over scores, sets, and distributions. The whole controller is a scalar comparison run after each hit. The takeaway, the leaving decision is a closed-form arithmetic question, not a judgment call. You combine three cheap signals into one number and compare it to a cost. That is the entire control loop. Here is the structural argument, the reason this is a genuine third option and not a tweak on what exists. Retrieval control today sits at two unsatisfying polls, and this controller refuses both. The first poll we already named fixed top K, adaptive at nothing but dead cheap. The second poll is the language model-judged iterative loop, the self-rag and adaptive-rag family, where after each retrieval step you ask a model, do I have enough context to do this? No, not yet. Those loops adapt beautifully. They genuinely tune retrieval depth to query difficulty, but they pay a full model call per step to do it, and that cost compounds across the loop. Worse, the stopping policy is implicitly re-specified every time you upgrade the underlying model, because the judgment lives inside the model, not in the system. So you can have adaptive, or you can have cheap, but the two polls make you choose. The optimal stopping literature says you do not have to choose, and the in-corpus evidence is unusually strong. Chris Goel, Christoph Dan, and Emma Brunskill, in their work on sample-efficient policy search for optimal stopping domains, frame deciding when to stop an observation-generating process exactly as the secretary problem family, and they prove sample complexity bounds with logarithmic dependence on the horizon. Logarithmic, not linear, not exponential. That is the strongest anchor that a stopping controller can be learned cheaply and with provable guarantees, and notably their lineage runs straight back through the Pirolli foraging tradition. And the adaptivity is not hypothetical in retrieval either. Ping Nei and colleagues built an any-hop iterative document re-ranker that, in their words, adaptively determines when to stop the retrieval process, dropping the fixed single-hop versus multi-hop assumption, and matching or beating the state-of-the-art on natural questions, SQuAD-Open, and HotpotQA.

But here is the dissent, and it is honest. Nei’s stopping rule is a learned graph re-ranker score. It is adaptive, it is cheap, but it is opaque. You cannot say why it stopped. The midpoint case is Vendi RAG from Mohammad Reza Rezaei and Adji Bousso Dieng, which adaptively trades retrieval diversity against quality, beats adaptive rag on multi-hop questions, and crucially shows the gains grow as the document count rises, strong evidence that a cheap diversity signal is the right marginal gain proxy. But Vendi RAG still calls a model judge each iteration to set its diversity weight. The takeaway. This controller keeps the diversity signal that Vendi RAG proved valuable and removes the per-iteration model judge, and it replaces Nei’s opaque learned stop with a transparent rule. You stop because similarity decay times redundancy drop below switch cost, and you can say exactly that. The reason this idea feels solid is that it is not one bet.

It is the confluence of four separate research traditions, three of them entirely outside the language model corpus, that happen to point at the same mechanism. Let me walk the lineage, because the credibility comes from the convergence. First, behavioral ecology, which gives the stopping rule itself. Charnov’s marginal value theorem is the literal source of leave when intake drops to the habitat average. The patch model around it comes from David Stephens and John Krebs and their 1986 book on foraging theory. This is the oldest layer and the most rigorous. Decades of field-tested mathematics about when an animal should abandon a depleting resource. Second, information science and human-computer interaction, which give the metaphor for search. This is the Pirolli and Card information foraging line we opened with, the move that took Charnov’s animal and turned it into a person hunting through information. Information sent, patch leaving on the web, diminishing within-patch returns, these are their contributions, and they are why we can talk about a database query as a foraging walk at all. Third, classical information retrieval and summarization, which give the redundancy signal. The canonical ancestor is Jaime Carbonell and Jade Goldstein’s maximal marginal relevance, from SIGIR in 1998, the original relevance minus redundancy objective. That idea, that the value of the next item is its relevance discounted by how much it duplicates what you already have, is exactly the patch depletion signal, and it is the direct conceptual ancestor of the diversity machinery. The determinantal point processes and the submodular selection methods that the modern controller uses. Fourth, optimal stopping and sequential decision theory, which give the formal guarantees. The secretary problem, surveyed in Thomas Ferguson’s 1989 paper, made learnable with bounds by Goel, Dan, and Brunskill. Sven Schmidt, Virag Shah, and Ramesh Johari add what they call the paradox of power, that high-powered exhaustive search is actually inefficient when candidate patches are abundant, a clean theoretical argument for leaving early. And Daniel Jarrett and Mihaela van der Schaar’s inverse active sensing models timely decisions as costly sequential evidence gathering with an explicit decision to commit, which is exactly a stop. The dissent here is just a caution. Convergence is suggestive, not proof. Four traditions agreeing on a mechanism does not mean the mechanism transfers cleanly to language model memory, where the patches are messier than berry bushes. The takeaway is that the burden this lineage carries is to make the metaphor operational and measured, which is the next segment, not to rest on its pedigree. A cheap adaptive controller is easy to claim and hard to prove, so the evaluation design matters more than usual. The trap is specific, and it has a name in the program pre-mortem. The evaluation cannot isolate the structural win. Start with the task design. You need variable difficulty retrieval, where the optimal number of items to read genuinely varies per query, a deliberate mix of single-fact and multi-hop questions over a long horizon corpus. And, this is the critical part, results reported per difficulty structure. The answer is stratum, never pooled. Pooling lets an easy query win hide a hard query loss. Use the multi-hop benchmarks the closest prior art already uses, HotpotQA, MuCQ, and 2WikiMultiHopQA from the Vendi RAG work, and natural questions, SQuAD-Open, and HotpotQA from Nee and colleagues. Then add a synthetic generator that controls the per-query optimal k directly, so you can measure overforaging and underforaging against an actual ground truth. The headline metric is the answer quality versus retrieval cost Pareto frontier. Does the controller dominate both fixed k and the model stop loop on the cost quality curve? Jarrett’s accuracy speed acquisition cost framing gives you the explicit Pareto axes. Underneath that, three more. The distribution of items read per query, which measures adaptivity directly, since a good controller’s distribution should track query difficulty. The stop decision cost itself, which must be far less than the single model call, and should be reported as controller latency against one model call, drawing on Schmidt’s opportunity cost ledger, and the over and underforaging rate against the synthetic oracle k, the fraction of queries that stopped too early and missed the crucial item, or stopped too late and wasted reads. Baselines are fixed k at several values, the model judged loop, Nee’s learn stop re-ranker, and an oracle k upper bound. And ablate each signal alone, similarity decay only, diversity only, info gain only, to show what each one actually contributes. The descent is the methodology warning, and it is sharp. There are three ways this evaluation can lie to you. Synthetic over fit, where the controller learns the generator rather than the task. A recency confound, where long horizon benchmarks let recency alone explain recall, so you are not measuring foraging at all. And model judge bias if you use a model to score. The mitigations are concrete. Build the shared harness first, pair every synthetic result with a real benchmark replication, de-correlate recency from importance inside the generator, and use an independent local judge plus human spot checks. The takeaway, the believable result is a Pareto plot, reported per difficulty stratum, where the controller dominates both poles and its stop decision cost is provably a tiny fraction of a model call. Anything pooled or anything that cannot be pooled or cannot rule out recency does not count. Two risks dominate, and they are the honest reasons this is research and not a ship default. Both come straight from the project premortem. The first and highest is that cheap signals miss semantic salience. The controller stops early on a query whose answer hinges on a low similarity but crucial item that no surface signal flagged. The berry that does not look like a berry. This is the existential risk for any non-model salience scheme. And the mitigation is not to pretend it cannot happen. It is to calibrate the controller against Oracle K on a held-out set, and then to permit a bounded model fallback only when the controller’s own confidence is low. The common path stays fully non-model and cheap. The model is a capped insurance policy on the worst case, not a per-step cost. That preserves the cost win without betting everything on cheap signals. The second risk is that patch structure is ill-defined. If patches do not map cleanly onto the store, the switch rule becomes arbitrary. You are leaving and entering partitions that do not mean anything. The mitigation is a discipline. Define patches off structure that already exists, storage tiers, semantic clusters, structured slots, archive levels, and never invent a partition just to forage over it. The controller forages over the map that is already there. There is also a subtle program-level risk worth naming, because it is special. Because it is specific to this thread. Cost does not shrink, it just moves. If the signal computation itself, the determinantal point process eigendecompositions, the mutual information estimation, is expensive, then the cheap claim quietly collapses. The whole pitch was avoiding a model call, and you cannot replace it with an equally costly linear algebra call. The mitigation is to hold stop-decision cost far below one model call as a hard evaluation gate, and to prefer the cheapest adequate signal, DotHash over a full determinantal point process wherever the cheap dedupe suffices. What gets built next follows directly. A shared signal bank is the structural payoff. The very same cheap signals that decide when to stop reading also drive the right gate. Admit, if surprising or novel, the prioritized replay intuition from Tom Schaul and colleagues, and the curiosity signal from Pathak and colleagues, and they drive compaction priority during consolidation. One signal vocabulary, three control points. And the cross-patch ordering question, which patch to visit next under uncertainty, has its own theory ready to plug in. Marko Mitrovic and colleagues’ adaptive sequence submodularity gives an adaptive greedy policy with approximation guarantees for exactly that sequential selection under uncertainty problem. The takeaway. Build the controller as mechanism, not model judgment. Keep a capped model fallback for the low-confidence tail. And reuse the same signal bank for writing and compaction, so the cost of computing salience is amortized across the whole memory lifecycle. So that is forging recall, and that is the Research Frontier subseries. The one idea to carry out. Retrieval depth should be an output of the query, not a constant you set in advance. And you can decide when to stop using cheap signals that an animal in a meadow has been using for millions of years. No model call required. Charnov gave us the rule. Pirolli and Card gave us the metaphor. Carbonell and Goldstein gave us the redundancy signal. And the optimal stopping theorists gave us the guarantees. The one thing to watch. Whether anyone reports the Pareto plot honestly, per difficulty stratum, with stop decision cost proven to be a fraction of a model call. The one concrete action. Next time you see a memory system, ask what its k is, and whether it ever changes. If the answer is a constant, it is feeding every bush exactly 10 berries. Until next time.

Here is a number to start with. A team builds a memory benchmark called BEAM, stretches each test conversation out to ten million tokens, and asks the obvious question: now that the biggest models can hold a million tokens or more in context, do we even need a memory system? Can’t we just stuff the whole history into the window and let attention do the work? The answer the benchmark gives is brutal and clarifying. No memory architecture saturates it. The best systems land around sixty-four percent at the one-million-token track and drop into the high forties at ten million. And context stuffing doesn’t even compete, because at ten million tokens a frontier window holds maybe one percent of the history. So the field arrives at mid-2026 with its founding bet vindicated by force. Memory is not a temporary patch we tolerate until context windows grow. It is a permanent layer of the stack, and we are still bad at it.

That is the through-line for the next forty-five minutes. This is a state-of-the-field episode, a capstone to the reading path, so I’m going to assume you know the vocabulary and instead synthesize where the field actually is. And the summary is a split-screen. On one side, real systems ship, real numbers climb, real companies sell agent memory as a product. On the other side, we cannot reliably tell which of those systems is best, because the way we measure them is so fragile that changing one scoring decision flips the winner. So we’ll walk three movements. First, what exists: the memory stack and the systems that ship it. Second, how we measure them, and why that measurement is in crisis. Third, what’s still unsolved, the frontier the field hasn’t cracked. Building, evaluating, breaking. Let’s go.

Start with the stack, because every system we’ll name is an opinionated answer to the same architectural question. The vocabulary comes from CoALA, the 2023 cognitive-architectures paper from Sumers and colleagues at Princeton, now sitting north of one hundred fifty citations and functioning as the field’s periodic table. It gives you four memory types. Working memory is the live context window, the desk where the agent thinks right now. Episodic memory is the record of specific past experiences, what happened and in what order. Semantic memory is general knowledge and facts, decoupled from any single episode. And procedural memory is the skills and routines the agent knows how to execute, including, in a nice twist, its own prompts and code. When a vendor tells you their product has episodic and semantic memory, they are speaking CoALA whether they cite it or not. Hold those four words, because the entire systems landscape is a set of choices about which of them to make first-class, what data structure to store each in, and when to move information between them.

And there’s a second axis, from the 2026 survey by Jinghao Luo and colleagues, titled From Storage to Experience, which is itself the thesis. Memory systems climb a ladder. Stage one is storage: you keep the raw trace, the logs, the transcript. Stage two is reflection: the agent processes the trace, summarizes it, writes itself a note like “this user prefers terse answers.” Stage three, the frontier, is experience: the agent abstracts across many trajectories into reusable knowledge that changes how it acts in genuinely new situations. Storage, reflection, experience. The useful thing about that ladder is it’s a diagnostic. Most of what ships today lives on rungs one and two. When a vendor says their agent “learns from experience,” the sharp question is which rung they’re actually on. Are they abstracting across trajectories, or keeping good logs and calling it learning?

Now the systems. Let’s anchor on the three that the reading path treats as canonical, because they stake out the design space. Zep, from Preston Rasmussen and colleagues, builds memory as a temporal knowledge graph through an engine called Graphiti. Conversation and structured business data get fused into typed entities connected by time-stamped edges, and crucially, when a fact changes, the old edge isn’t deleted, it’s marked invalid as of a date. That temporal awareness is the whole point. Zep reported beating MemGPT on the deep-memory-retrieval benchmark, ninety-four point eight versus ninety-three point four, and improving LongMemEval accuracy by up to eighteen and a half percent while cutting latency by ninety percent. The number that matters there isn’t the accuracy, it’s the latency, because it tells you the graph is doing work the context window would otherwise do slowly. A-MEM, from Wujiang Xu and colleagues, takes the opposite philosophy: instead of a rigid graph, a self-organizing web of notes, Zettelkasten-style, where new memories link to and rewrite old ones as they arrive. It’s beautiful and it’s loose. And Mem0, from Prateek Chhikara and colleagues, is the production-pragmatist of the three: extract facts, consolidate them, keep the store small. Mem0 reported on LoCoMo a twenty-six percent relative improvement over OpenAI’s built-in memory, ninety-one percent lower p95 latency, and over ninety percent token savings versus dumping the full context. Same word, memory, three incompatible data models. That’s the field in miniature.

Now step outside the reading path, because the most important development since these papers is that agent memory became an infrastructure product, and the production systems make the build-versus-buy decision concrete. Letta, the company that grew out of the MemGPT paper, ships the clearest mental model: the load-bearing primitive is the memory block, a labeled, persistent string the agent edits with its own tool calls, like core_memory_append and core_memory_replace. There’s a “human” block for what the agent knows about you, a “persona” block for its self-description, and custom blocks for task state. The agent literally rewrites its own memory in the loop. And in 2026 Letta added what they call sleep-time compute, which is the single cleanest instantiation of the reflection stage I’ve seen ship. The insight is that in the original MemGPT design, memory management and conversation were bundled into one agent, so the agent was slow during chat because it had to stop and do bookkeeping, and the memories got messy because they were written incrementally under time pressure. Sleep-time compute offloads memory management to a separate sub-agent that runs asynchronously, often triggered when the context window gets compacted. It reads the raw trace and rewrites it into clean, concise, organized memory while the user isn’t waiting. That is reflection as a system primitive: storage on the hot path, reflection on a background clock. Remember that pattern, because it recurs everywhere now.

LangChain’s answer is LangMem, an SDK that bolts long-term memory onto LangGraph agents and is notable because it maps directly onto the CoALA triad in product form. Semantic memory: facts about you, stored either as an unbounded searchable collection or as a structured profile, a user card the agent keeps current. Episodic memory: records of specific past interactions. Procedural memory: internalized know-how, which LangMem is explicit lives across a combination of model weights, agent code, and the agent’s own prompt. And it offers the same two integration modes as Letta’s design: hot-path tools the agent calls mid-conversation, or a background memory manager that extracts and consolidates asynchronously, merging related facts and resolving contradictions on its own clock. Hot path versus background is becoming the standard fork in the road, and it’s the storage-versus-reflection split wearing an engineering hat.

Then there’s the operating-system camp, which has its most ambitious 2026 entry in MemOS. The pitch is right there in the name: treat memory as a first-class operating-system resource, the way an OS schedules RAM and disk. Its core abstraction is the MemCube, which wraps three kinds of memory under one scheduler: plaintext memory, activation memory meaning KV-cache states, and parameter memory meaning weights. The radical claim is that these are interconvertible, that a frequently-used plaintext memory could be promoted into activations or even distilled into parameters, and a cold parameter memory demoted back to plaintext, with the system migrating content between forms based on usage, importance, and recency, exactly like an OS swapping pages. Whether that promise holds up is open, but it’s the purest expression of the MemGPT lineage, the camp that thinks about memory in operating-system terms, paging and caching and eviction.

And then there’s the part of the landscape that almost never shows up in the academic papers but is where most real users will actually meet agent memory: the platform vendors. Cloudflare shipped agent memory built on Durable Objects with SQLite-backed storage now generally available, ten gigabytes per object, where each agent is a stateful object with its own embedded SQL database that persists across evictions. That’s memory as boring, durable infrastructure, no knowledge graph, no consolidation, just a place to put state that survives. And Twilio shipped Conversation Memory aimed at customer-facing agents, which is worth dwelling on because it solves a problem the academic benchmarks barely model: identity resolution across channels. Twilio’s system builds one canonical customer profile and recognizes the same person across phone, email, and WhatsApp, automatically resolved into a single memory. Then its Recall API retrieves with a combination of semantic and lexical search and returns a ranked set of observations, summaries, and recent communications.

That last detail opens the most important technique in production retrieval, and it deserves a proper beat, because it’s where the reading path’s information-retrieval thread reconnects to memory. The technique is Reciprocal Rank Fusion. The problem it solves is that no single retrieval channel is enough. Embedding similarity is great for paraphrase and fuzzy semantic match but blind to exact strings. Keyword search nails the exact term and misses the synonym. A knowledge-graph traversal finds multi-hop connections neither of the others can see. So mature memory systems run all of them and then have to merge several ranked lists into one. RRF does this with a formula almost insultingly simple: each candidate’s fused score is the sum, across channels, of one over a small constant k plus its rank in that channel, with k usually set to sixty. A memory that ranks high in multiple channels accumulates evidence and rises to the top; a memory that’s only strong in one stays modest. No score calibration, no tuning embeddings against keywords, just rank arithmetic. And the production refinement worth knowing is weighted RRF, where the query type sets channel weights: a temporal query boosts the time-aware channel, a multi-hop query boosts the entity-graph channel. So the system routes its trust by what’s being asked. If you build one thing from this episode, multi-channel retrieval fused with weighted RRF is the highest-leverage, lowest-glamour move you can make.

Let’s pull the building movement together before we leave it, because the spectrum tells you where the open design space is. The architectures are fanning out along an axis of structure: flat text, then typed semi-structured entries like Memanto, then pairwise knowledge graphs like Zep, then hypergraphs like HyperMem that capture multi-participant events a pairwise graph would fragment, then hierarchical trees like MemTree and LinkedIn’s production hiring-agent memory. A 2026 paper, T-Mem, argues that nearly all of these, the graphs and trees and OS kernels alike, share one recipe: similarity-based retrieval over descriptive memory, and that they all leave associative recall, the “this reminds me of that” channel, as a structural blind spot. And on the writing side, a clear consensus has formed: a storage path that’s fast and lossless and never blocks the user, and a reflection path that runs in the background to consolidate, deduplicate, and resolve conflicts. Letta’s sleep-time agents, LangMem’s background manager, MemOS’s scheduler, the bi-temporal Engram engine that keeps a sub-fifty-millisecond write path while a separate consolidation path builds the graph. Storage on the hot path, reflection on a clock. That is the load-bearing pattern of 2026 memory systems.

It’s worth being precise about what the experience rung actually requires, because it’s where the research is hottest and the marketing is loosest. Reflection, rung two, is within reach: the agent looks back at one trajectory and writes a better note. Experience, rung three, means abstracting across many trajectories into something reusable, and the field has discovered that the naive version, just retrieving a similar past episode, doesn’t get you there, because a retrieved raw episode forces the base model to re-adapt it on the fly, every time. So the 2026 work moves toward generated rather than retrieved experience. CLEAR, from Linbo Liu and colleagues and open-sourced by AWS, runs a reflection agent that does contrastive analysis over past trajectories to produce per-task summaries, then trains a context-augmentation model that generates task-tailored experience instead of looking it up, lifting AppWorld from the low seventies into the eighties. HiExp extracts hierarchical experience through multi-level clustering and uses it to regularize an agent’s otherwise random exploration. And the frontier systems couple memory to capability directly: SEARL jointly optimizes the agent’s policy and a tool-graph memory under verifiable-reward training, and Mem2Evolve co-evolves distilled experience with newly created tools and expert sub-agents, so the accumulated experience doesn’t just inform the agent, it expands what the agent can do. That’s the real meaning of the experience rung, memory that changes capability, not just memory that changes recall, and almost nothing in production is there yet.

There’s a design decision hiding inside that reflection path worth surfacing, because it’s the deepest architectural fork in the field and most builders make it without noticing. When the background agent consolidates experience, where does the consolidated memory go? Two answers. The non-parametric answer: it goes into text or a graph, an external store the model reads back through its context window at query time. Everything we’ve named so far, Zep, Mem0, A-MEM, Letta, lives here. Memory is data the model retrieves. The parametric answer is stranger and more ambitious: the consolidated experience goes into the weights, fine-tuned in, so the model just knows it without retrieving anything. A 2026 paper from Simon Dennis and colleagues runs the rare head-to-head, per-user weight-based consolidation against cascading context compaction, the two ways to retain experience under inference-only deployment. And TSUBASA, from Xinliang Frederick Zhang and colleagues, splits the difference with context distillation, internalizing user experience through a self-learning loop rather than re-reading the raw history every turn, benchmarked against Mem0 across the Qwen-3 model family with a quality-versus-token-budget framing. MemOS’s claim that plaintext, activations, and weights are interconvertible is the maximalist version of this idea: that the parametric and non-parametric stores aren’t different architectures, they’re different temperatures of the same memory, and the system should move content between them. Whether that holds is unproven. But the axis, memory-as-context versus memory-as-weights, is the one that will define the next generation of systems, and right now almost nobody benchmarks both under a matched compute budget.

And one more piece of the stack, because it’s the rung-three frontier in production form: procedural skill libraries. The lineage starts with Voyager, the 2023 embodied agent from Guanzhi Wang and colleagues that gave us the canonical move, an ever-growing library of executable code skills, written and verified and stored as compositional behaviors, with an automatic curriculum, that transferred to a fresh Minecraft world. Voyager turned procedural memory into a code library you grow. Agent Workflow Memory, from Zora Zhiruo Wang and colleagues, generalized that off the game board: induce reusable routines from agent trajectories, offline from training examples or online from the test queries themselves, and inject them as procedural memory, with explicit cross-task and cross-website generalization tests on WebArena and Mind2Web. And the 2026 work pushes into the hard maintenance problem: Skill1 trains a single reinforcement-learning policy to co-evolve the three coupled operations of a skill library, selecting, using, and distilling skills toward one task objective, and finds that distillation is the control knob for library quality and growth. Because the dirty secret of skill libraries is that they rot. Skills accumulate, overlap, drift, and clutter, and the library gets worse, not better, as it grows. SkillEvolBench, which we’ll come back to in the measurement movement, was built precisely to test whether the distilled skills actually beat just reusing the raw trajectories. Spoiler that should worry every builder: often they don’t.

Two things are worth knowing about how procedural memory actually ships, because they’re where the design choices bite. First, there are two competing representations, and they fail differently. One camp stores executable code skills, Voyager, SkillClaw, Skill1, SkillDroid, where a skill is a function you can compile and run; these fail with compilation errors and composition errors, two skills that don’t fit together. The other camp stores natural-language workflows or manuals, Agent Workflow Memory and AutoManual, where a skill is a written-down routine; these fail with ambiguous-instruction drift, where the model interprets its own note differently than it meant. A benchmark that covers procedural memory has to test both, because they break in incompatible ways. Second, efficiency has become a co-equal metric to accuracy here, and it’s the clearest place where memory pays for itself. SkillDroid, a 2026 mobile-GUI agent, compiles a successful task execution into a reusable skill so later invocations skip the per-step LLM inference entirely; the win isn’t a higher success rate, it’s that the same task runs without paying for the model again. When a skill is reused, the question stops being “did it work” and becomes “did it work and what did it cost.” That cost axis is where the procedural-memory literature is ahead of the conversational-memory literature, which still mostly reports accuracy and hides the token bill.

Which brings us to the second movement, and the genuine crisis of the field. We have all these systems. We have all these numbers. Mem0 reports ninety-two and a half on LoCoMo and ninety-four point four on LongMemEval at about sixty-nine hundred tokens a query. Zep reports its deltas. New systems post leaderboard wins weekly. And the uncomfortable truth, the thing the careful 2026 methodology papers are screaming about, is that those numbers do not mean what they appear to mean, and a striking number of them do not survive contact with a neutral re-run. So let’s take the measurement crisis seriously, because it’s the most intellectually alive part of the field right now.

Start with the benchmarks themselves, because the foundation is shakier than the leaderboards suggest. LoCoMo, from Adyasha Maharana and colleagues, is the de-facto reference: very long synthetic dialogues across up to thirty-five sessions, with a four-category question taxonomy, single-hop, multi-hop, temporal, open-domain. Almost every memory system reports on it. And LoCoMo has exactly ten conversations and one thousand eight hundred thirteen questions. Systems are now reporting above ninety-four percent on a benchmark of ten conversations, which raises two alarms at once: statistical power, because ten conversations is a tiny sample to rank systems on, and contamination, because a benchmark this small and this public leaks into training data and saturates. A 2026 paper, Synthius-Mem, reports ninety-four point four percent memory accuracy and ninety-nine point six percent adversarial robustness on LoCoMo, and the right reaction to a number that high isn’t celebration, it’s suspicion that the benchmark has stopped measuring capability and started measuring memorization. LongMemEval, from Di Wu and colleagues, is healthier: five named abilities, including knowledge-update and abstention as first-class tasks, with controllable histories so you can scale the memory load independently of the evidence. But it too is being saturated.

So the field is doing what a maturing field does: building harder benchmarks and, more importantly, questioning the measurement itself. BEAM, which opened this episode, pushes to ten million tokens precisely so nothing saturates. LongMemEval-V2, released May 2026, reframes the entire target: memory systems shouldn’t just recall chat facts, they should help an agent become an experienced operator of a specialized environment, like an experienced colleague. It draws four hundred fifty-one curated questions and over eighteen hundred task trajectories from WebArena-style and ServiceNow-style environments, with haystacks up to a hundred fifteen million tokens, and five abilities that are nothing like factual recall: static state recall of page layouts, dynamic state tracking, workflow knowledge for recurring tasks, recognizing environment gotchas, and premise awareness, knowing which assumptions valid elsewhere are wrong here. That’s a benchmark trying to measure procedural and episodic memory in a working context, not chat trivia.

But harder benchmarks don’t fix the deeper problem, which is that the scoring itself is unstable. This is the part that should genuinely unsettle you. There’s a 2026 audit called TIAP, whose title is the whole finding: Same Ranking, Different Winner. It isn’t a new benchmark. It takes already-saved retrieval traces and re-scores them under different but equally defensible definitions of what counts as a correct retrieval. The setup: when one conversation turn gets processed into several derived memories, a raw stored version, a canonical rewritten version, and so on, which of them is allowed to receive credit when a query needs that fact? Call that the scoring target. TIAP defines three reasonable targets, raw, source, and canonical, re-scores the exact same retrieval traces under each without re-running anything, and watches what happens. The rankings flip. The system that wins under one scoring target loses under another. Same data, same retrieval, same traces, different winner, purely because of a credit-assignment choice nobody was reporting. The methodological takeaway is severe: if a memory paper doesn’t explicitly state its scoring target, its leaderboard position is not interpretable. And almost none of them state it.

It gets worse, or more interesting, depending on your temperament. There’s a paper bluntly titled Harness Updating Is Not Harness Benefit, from Minhua Lin and colleagues, that names a confound at the heart of every self-evolving agent claim. These systems edit their own harness, their prompts, skills, memories, tools, and then report improved task outcomes. The paper’s point is that the act of updating is routinely conflated with benefiting from the update. The harness changed, the score moved, and everyone assumed the change caused the gain, when it might be activity masquerading as capability. To make a credible claim you need controls: a no-update baseline, a raw-trajectory baseline, the works. And SkillEvolBench, from Yingtie Lei and colleagues, the one hundred eighty-task procedural-memory benchmark with an explicit acquisition-then-frozen-deployment split, ran exactly those controls and found the result I flagged earlier, that reusing raw trajectories directly often beats the distilled skills you so carefully induced. Think about what that means for the entire skill-distillation enterprise. You built a clever pipeline to abstract reusable skills from experience, and a control condition that just keeps the raw logs around outperforms it. If you didn’t run that control, you’d have shipped the distillation and credited it with a gain it didn’t earn.

There’s a third confound underneath the scoring-target and harness-update problems, and it’s the one that quietly poisons the most leaderboards: how the answers get graded in the first place. Almost every memory benchmark scores free-text answers with an LLM judge, because checking whether “she lives in Boston now” matches “the user moved to Boston” can’t be done with string matching. But LLM judges carry biases, position bias, verbosity bias, self-preference, documented across the LLM-as-judge surveys from Jiawei Gu and Haitao Li and colleagues, and a 2024 study from Hui Huang and colleagues shows that fine-tuned judge models, the cheap option, fail to transfer across tasks and are not a drop-in substitute for a strong general judge. None of those surveys validate judges specifically for memory QA, which is the hardest case, because memory judging means adjudicating temporal grounding, multi-session attribution, and contradiction handling, exactly the question types where a judge is most likely to be wrong. So a memory leaderboard built on an unvalidated judge is reporting the judge’s opinion as much as the system’s capability. The Engram engine paper, a 2026 bi-temporal memory system, documents the consequence directly: it shows how truncation, home-grown judges, and full-history leaks let a single system report fifty-eight, sixty-six, and ninety-two percent across different sources, the same system, three numbers, depending on who graded and what leaked. Its response, which is becoming the reproducibility gold standard, is to ship one in-repo pipeline, use the official category judge, put the full-context baseline in every table, and publish raw logs with a reproduce command attached to every number.

And then there’s the most sobering measurement result of the year, which is a null. A 2026 paper called GitOfThoughts ran a pre-registered, controlled comparison: hold the agent fixed, swap only the memory substrate across five backends, none, markdown, vector, graph, and git, on GPQA-Diamond and MATH-500, with paired-bootstrap confidence intervals at two model scales. The headline is a robust null. No substrate reliably improved accuracy on novel problems. A promising fifteen-point bump for the git substrate at a sample of forty did not survive its own pre-registered replication, and the authors documented the retraction alongside the result. Read that against the weekly leaderboard wins. When you run the controls the leaderboards skip, hold the agent and compute fixed, report intervals, pre-register the replication, a lot of the memory advantage evaporates. That doesn’t mean memory is useless; BEAM and the long-horizon benchmarks show it clearly matters at scale. It means that on short novel-reasoning tasks, the gains people attribute to clever memory architectures are often noise, confound, or the base model doing the work. The discipline to find that out is the discipline the field is still building.

The constructive response to all of this is white-box, stage-attributed diagnostics, and this is where the methodology movement is most exciting. The old way scores the final answer: right or wrong. The problem is that a memory pipeline has stages, write, store, retrieve, generate, and a final wrong answer tells you nothing about which stage failed. Did the system never store the fact? Store it but fail to retrieve it? Retrieve it but the generator ignored it? Two 2026 papers, both called MemTrace by different teams, attack this. One traces failures back to the specific pipeline stage responsible, converting an opaque wrong answer into a per-stage diagnosis. The other reorganizes the entire unit of measurement: instead of scoring question rows, it scores knowledge points, single typed facts about the user, probing each fact repeatedly across three controlled axes, how old the memory is, what kind of question is asked, and whether the evidence is present, missing, or contradicted. Eight hundred thirty-five knowledge points expand into over two hundred thousand scored answers, and then the killer move: a diagnostic that separates “the evidence was unreachable” from “the evidence was retrievable but went unused.” That distinction is the whole ballgame. Unreachable means fix your retrieval. Unused means fix your generation or your context assembly. A single accuracy number can’t tell them apart; a stage-attributed harness can.

This same retrieval-versus-use split shows up in the conflict literature, which is where memory measurement gets genuinely subtle. MemConflict, a 2026 framework, treats memory validity not as a fixed property but as fitness-for-use conditioned on the query, and defines three conflict types that any real deployment hits. Dynamic conflict: an earlier state and a later true update coexist, and the later one should supersede, you moved cities, the new city wins. Static conflict: a later false contradiction should not overwrite a stable fact, someone misremembers your birthday, the original stands. Conditional conflict: multiple values are each valid under different conditions, and only the one matching the query applies, you like window seats on long flights and aisle on short ones. The framework evaluates six real memory systems, A-Mem, LangMem, Letta, MemOS, Mem0, and Memobase, through one common pipeline, with both black-box scoring of the final answer and white-box scoring of whether the right memory was even retrieved and how it ranked. And the diagnostic gap it surfaces, between “the supporting memory was retrieved” and “the supporting memory was actually used,” localizes failures the way nothing answer-level can.

And then there’s forgetting, which the measurement movement reveals as the field’s true blind spot, and which sets up our third movement. STALE, from Hanxiang Chao and colleagues, asks the question directly: can LLM agents know when their memories are no longer valid? Four hundred expert-validated conflict scenarios, twelve hundred queries, contexts up to a hundred fifty thousand tokens, probing belief revision over time. The best model scores fifty-five point two percent. Just above a coin flip on knowing whether what it remembers is still true. Put the LoCoMo number and the STALE number side by side: ninety-four percent on recalling what was said, fifty-five percent on knowing whether it’s still valid. That gap is the field’s self-portrait. We got very good at remembering and we are still bad at updating, and almost nobody was measuring the second thing until 2026.

Step back and look at the meta-signal here, because it’s the real state of the field. In a single quarter, the research community produced an audit showing scoring choices flip rankings, a paper showing self-evolution claims conflate activity with benefit, a benchmark showing raw trajectories beat distilled skills, two independent white-box failure-attribution harnesses, and a benchmark showing the best models are at chance on memory validity. Read together, that is a field reaching the maturity where it stops trusting its own leaderboards and starts auditing its instruments. The bottleneck in agentic memory right now is not building memory systems. It’s that we cannot trust the comparisons between them. A neutral, re-runnable harness, with explicit scoring targets, fixed-answerer controls so you isolate the memory from the model, confidence intervals instead of point estimates, cross-system evaluation, and stage-attributed diagnostics, is itself the most valuable contribution someone could ship. The systems are ahead of the science of measuring them, and that gap is the headline.

Which brings us to the third movement: what’s actually unsolved. The frontier. And I want to drive this off the real gaps, because the open problems are more specific and more tractable than the usual hand-waving about AGI.

The first frontier is forgetting and obsolescence, and it’s the thinnest-measured area in the entire field. Here’s the conceptual trap the whole field fell into: every metric we built rewards accumulation. Recall at k, did you keep the fact and find it. None of them reward correct deletion, removing a memory that’s stale, superseded, or wrong. So systems are optimized to be hoarders. The 2026 work is finally pushing back. There’s a neuroscience-inspired camp, SCM with sleep-style consolidation and explicit algorithmic forgetting, ZenBrain with a seven-layer architecture, Adaptive Memory Crystallization which actually puts numbers on it, reporting sixty-seven to eighty percent reductions in catastrophic forgetting and a sixty-two percent smaller memory footprint on robotics benchmarks. There’s an eviction-with-recall camp, cooperative memory paging that bookmarks evicted content by keyword so it can be paged back, Learning to Forget for robots that cuts memory forty-five percent while holding QA accuracy. And there’s the constrained-optimization camp, a paper called OSL-MR that charges an explicit cost for keeping stale memories and for discarding still-useful ones, and finds the learned policy keeps a smaller, evidence-denser store: on LoCoMo at a budget of one hundred twenty-eight memories, F1 of zero point three at seventy-six percent occupancy, versus a greedy baseline that fills to ninety-nine percent occupancy and scores zero point zero seven. The lesson is counterintuitive and important: deliberately keeping less, but keeping the right less, beats greedily keeping everything. What’s still missing is a shared metric, and the absence is specific enough to name. We have no standard retention curve, the analog of a forgetting rate over time. We have no agreed-on precision and recall for obsolescence decisions, no way to ask whether a pruning policy deleted the right stale items rather than just shrinking the store, because shrinking the store and curating the store look identical to a recall metric. And we have a strange evidence gap at the heart of the most popular mechanism: nearly every neuroscience-inspired system describes a consolidation step, sleep-style replay, synaptic tagging, the hippocampal-cortical metaphor, and almost none of them ship the ablation that would justify it, the run that turns consolidation off and shows long-horizon retention drops. STALE measures obsolescence detection with its own three-dimensional accuracy, Adaptive Memory Crystallization imports forward-transfer and forgetting-percent from continual reinforcement learning, but these don’t compose into a common protocol. Two forgetting papers cannot be ranked against each other today. Until a shared retention-and-obsolescence suite exists, this whole area can be admired but not compared, which is exactly the state the recall benchmarks were in three years ago before LoCoMo, and exactly the gap that made LoCoMo matter.

The second frontier is security and governance, and it’s where the persistence that makes memory useful becomes the attack surface that makes it dangerous. A stateless model has no memory to poison; the moment you give an agent a durable store, you’ve given an attacker a place to plant something that persists. The canonical attack is AgentPoison, from Zhaorun Chen and colleagues: optimize a trigger so that any query containing it retrieves a malicious memory, no fine-tuning required, just poison the store. The 2026 work shows how much nastier this gets in real systems. There’s a Trojan attack that poisons a shared agent’s memory purely through normal conversation, with a trigger that survives the memory-extraction pipeline, no privileged access needed, just talk to it. There’s ShadowMerge, the first poisoning attack tailored to graph-structured memory, where one unprivileged user’s message gets materialized as a graph relation, survives entity-resolution merging, and is later retrieved as graph-native evidence for a different user. Cross-user contamination through the merge path: one user poisons another’s answers. And there’s the finding that should worry you more than any deliberate attack, a paper on unintended long-term state poisoning, showing that memory gets corrupted without any attacker at all, just through routine interaction that gradually drifts the stored state toward harm. The defenses are forming, lineage and provenance tagging on every memory entry as in MemLineage, audit graphs of agent execution as in Agent-BOM, write-back auditing. But the gap is glaring: there’s no standardized security harness with shared metrics across attack families, poisoning success rate, induced over-refusal, cross-user leakage, provenance violations, all measured in bespoke per-paper setups. And nearly every attack targets semantic retrieval memory; poisoning of stored procedures and skills, where a corrupted skill executes instead of merely misinforming, is almost untouched.

The third frontier is synthetic-data realism, which sounds like a tooling problem and is actually a validity problem for the whole field. Almost every memory benchmark, LoCoMo and LongMemEval included, is synthesized by an LLM playing personas. So the question that undermines everything is: do these synthetic conversations look like real ones? The 2026 answer is a clear no, and it’s well-documented. OmniBehavior, built entirely from real-world behavior traces, shows that LLM user simulators converge to what the authors call a “positive average person,” with persona homogenization, hyper-activity, and a Utopian bias, losing exactly the individual quirks and long-tail behaviors that make memory hard. REALTALK contributes twenty-one days of genuine human-human messaging as a real-data anchor and exposes the same distribution gap. So you can saturate a synthetic benchmark while still failing on real users, because your synthetic users aren’t real users, they’re an averaged ghost. The constructive direction exists, controllable conflict and distractor injection from the MemConflict recipe, the quality-diversity-complexity auditing framework that measures the data itself instead of just downstream scores. But there’s no agreed fidelity metric that scores whether a synthetic memory dataset is realistic, and the benchmarks remain tiny and persona-thin, EngramaBench runs five personas, a hundred conversations, a hundred fifty queries. The scaling question, how to generate thousands of genuinely diverse personas without collapsing to the average person, is wide open.

The fourth frontier is multimodal and long-horizon recall, where the benchmarks are racing to catch up to the products. Most memory research is text-only, but agents increasingly see screens, images, and continuous sensor streams. MemLens and MemEye both, in 2026, started benchmarking whether vision-language models preserve the visual evidence needed for later recall. PersonaVLM pushes personalization into the multimodal regime, a model that remembers an individual’s visual preferences over time. And the most striking move is toward streaming, always-on input: StreamMemBench sources its tasks from real egocentric lifelog video, mining each five-minute segment for a hidden evidence anchor, a preference or plan or capability, then testing whether the agent carries it forward to a later related task without being re-prompted. That’s memory for a wearable that watches your day, and it breaks the clean-session assumption every dialogue benchmark relies on. The text-only era of memory evaluation is ending, and the multimodal era barely has a yardstick.

The fifth frontier is the cluster of production axes the literature covers least and deployments need most, and it starts with multi-user isolation. Every memory benchmark assumes one user, one memory. Real systems serve millions, and the failure mode is catastrophic and specific: one user’s memory leaking into another user’s response. ShadowMerge already showed it can happen through a graph merge. The Multi-User LLM Agents work names the problem, an agent that must maintain and isolate per-user state, but there’s essentially no benchmark that adversarially probes whether user A’s memory contaminates user B’s answers, which is a strange gap given that it’s the single risk most likely to make a real deployment a headline.

It pairs with proactivity. Every benchmark we’ve discussed is reactive: the user asks, the agent recalls. But a memory that’s only consulted on request is leaving most of its value unused. The PASK work couples long-term memory with intent inference to drive proactive behavior, the agent surfacing remembered information unprompted, and it exposes an evaluation problem nobody has solved: how do you score whether an agent should have spoken up, including the cost of false proactivity when it volunteers something unwanted at the wrong moment. Recall-style benchmarks have no way to measure that, because they only ever ask questions. And the domain deployments make the same point from the other side. LinkedIn’s hiring agent runs a production hierarchical semantic memory organized into abstraction tiers; a longitudinal health-agent framework argues memory and personalization alone are insufficient and proposes evaluation across coherence, continuity, adaptation, and agency over a patient’s trajectory. Generic recall QA captures none of that. Each high-stakes domain wants its own longitudinal criteria, and there’s no harness that lets one memory system be scored under each domain’s standard.

Underneath all of it sits cost, the dimension that turns every accuracy number into half a story. Every figure I’ve quoted has a token budget behind it, Mem0’s roughly sixty-nine hundred tokens per query, Zep’s ninety-percent latency cut, and the field has barely started treating efficiency as a first-class metric alongside accuracy. A memory system that’s two points more accurate and ten times more expensive is not obviously better, and almost no leaderboard reports the tradeoff. The procedural-memory people figured this out first, scoring reuse by inference saved as well as tasks solved; the conversational-memory people are still catching up. Memory exists to spend less compute than re-reading everything, so a memory benchmark that ignores compute is measuring the wrong thing.

Let me pull the whole arc together, because the three movements tell one story. We built the stack: working, episodic, semantic, procedural memory, with a storage-reflection-experience ladder that most systems are still climbing. We shipped the systems: Zep’s temporal graph, A-MEM’s self-organizing notes, Mem0’s lean production store, Letta’s self-editing memory blocks with sleep-time reflection, LangMem’s CoALA-shaped SDK, MemOS’s operating-system ambition, and the platform vendors, Cloudflare and Twilio, who quietly put memory in front of the most users, with multi-channel retrieval fused by weighted RRF as the highest-leverage production technique. And on top of it all, procedural skill libraries climbing toward the experience rung, from Voyager to Agent Workflow Memory to Skill1. That’s a real, shipping field.

Then we measured it and the floor moved. LoCoMo saturating at ten conversations. TIAP flipping the winner by changing the scoring target. Harness Updating Is Not Harness Benefit catching activity dressed as capability. SkillEvolBench finding raw trajectories beating distilled skills. The two MemTrace harnesses pulling failures apart into write-versus-retrieve-versus-use. STALE putting the best models at fifty-five percent on knowing whether a memory is still valid. The systems are ahead of the science of comparing them, and a neutral, stage-attributed, scoring-target-explicit, confidence-interval-reporting harness is the most valuable thing the field could build right now. And then the frontier: forgetting we can’t measure, security we can’t standardize, synthetic data that isn’t real, multimodal recall that’s barely benchmarked, multi-user isolation that production needs and research ignores.

Notice the meta-pattern under all three movements, because it’s the deepest thing here, and it traces straight back to the foundations of this whole series. The field keeps reaching for the human brain. Sleep-consolidation, hippocampal metaphors, the seven-layer architectures, the active-forgetting pathways borrowed from neuroscience. And the reason is the one we landed on at the very beginning: human memory is the only existence proof we have of a system that remembers across a lifetime, forgets gracefully without catastrophic loss, generalizes from a handful of examples, and stays coherent for decades, on a power budget smaller than a light bulb. Every architecture in this episode is a wager about which features of that system are worth copying and which are accidents of wet biology. The danger, the one the careful papers flag, is that a beautiful neuroscience metaphor can paper over the absence of a measured result. Sleep-consolidation sounds biologically plausible; the question that earns it its keep is whether there’s an ablation showing the consolidation step actually improves long-horizon retention against a no-consolidation control. Mostly, there isn’t yet.

So let me leave you where the field actually is, on the live open question, the one that subsumes the others. We have systems that store and reflect well, and we cannot yet build one that knows what to forget. Forgetting is not the absence of memory; it’s the hardest act of memory. It requires knowing that a fact is stale, that a skill is obsolete, that a preference has changed, that a memory was never true, and then having the judgment to let it go without losing what still matters. The best models are at a coin flip on the simplest version of that judgment. Every other frontier, security, multi-user isolation, long-horizon coherence, multimodal recall, runs through it, because a memory you can’t correct is a memory you can’t trust, and a memory that only grows is a memory that eventually drowns. The bet that opened this episode, that memory is a permanent layer of the stack, is settled. The next bet, the one the whole field is now placing, is that the agents worth having won’t be the ones that remember the most. They’ll be the ones that know what to keep. We’re not there. That’s the work. Thanks for listening.

Memory is the feature everyone demos and nobody can evaluate. You have seen the demo. An agent remembers that you are vegetarian, that you fly out of Newark, that last quarter’s incident was a connection-pool leak, and it brings that back at exactly the right moment, and the room nods. What you have not seen, because nobody demos it, is the same system three months later, quietly returning a stale preference, contradicting itself across two sessions, pulling a memory that is semantically close to the question and useless for answering it, and doing all of that with complete fluency, because a wrong memory and a right memory sound exactly the same coming out of a language model. That gap, between the demo and the deployment, between how good memory looks and how hard it is to know whether it works, is the whole subject of this episode.

This is the engineering cut. There is a companion series on this site that walks the research literature, the taxonomies, the survey wave, the storage-to-experience arc. This is the other lens. You are building agent memory in production, you have a budget and a latency target and real users, and you have to make a sequence of design decisions, each of which has options, each of which has a real tradeoff, and each of which some shipping system has already gotten right or wrong in public. I am going to walk you through eleven of those decisions, in the order you would actually hit them building the thing. For each one I will give you the decision, the options on the table, the tradeoff that bites, and what real systems chose. Think of it as a decision tree for agent memory, drawn from a corpus of fifty-one sources spanning vendor blogs, production postmortems, and the 2026 research front, plus a handful of launches from the last few weeks that landed while the corpus was being assembled.

Hold one idea through all eleven decisions, because it is the spine. Memory is not a database you attach to an agent. Memory is a pipeline with three jobs that can each fail silently: deciding what to write, keeping what you wrote coherent over time, and surfacing the right piece at the right moment. Most of the decisions ahead are really about where in that pipeline you spend your effort and your tokens, and every one of them is a place where the system can look like it is working while it is not. Let us walk the tree.

Start with the data model, because every other decision inherits from it. The question is: what is the shape of a memory? And the answer the field has converged on, almost without arguing about it, is a three-tier hierarchy. Sessions at the top: a conversation, an investigation, a work order, the natural unit of a user interaction. Turns underneath: the individual messages, the raw back-and-forth, the literal transcript. And consolidated documents on top of those: the distilled, durable artifacts you actually retrieve later, the facts and summaries and lessons extracted from the raw turns. Sessions, turns, consolidated docs. If you have read Cloudflare’s Agent Memory writeup from this year, that is its spine exactly, and it is worth dwelling on why this particular shape keeps winning. The raw turns are ground truth, cheap to store and never wrong about what was actually said. The consolidated docs are expensive to produce and lossy, but they are what fits in a context window and what answers a question fast. Keeping both means you have a fallback when the distillation drops something, and a fast path when it does not. That redundancy is not waste. It is the design.

Look at how the managed services landed on the same structure independently, because that convergence is the strongest signal you get in this field. Amazon’s Bedrock AgentCore Memory, which reached general availability this year, splits cleanly into short-term and long-term. Short-term memory stores raw interaction events, the literal conversation, with a configurable expiry you can stretch up to a year. Long-term memory is generated asynchronously, a background process that extracts insights from the raw events after the fact, without blocking the live interaction. That is turns and consolidated docs, with a different vocabulary. Google’s Vertex AI Memory Bank, also generally available now, does the same: it keeps session state for the live conversation and extracts long-term memories from conversation history with a Gemini model running in the background. Different cloud, same two-layer split, same decision to make consolidation asynchronous so it never sits on the critical path of a response. When three independent teams at three hyperscalers ship the same shape, that is not fashion. That is the shape the problem actually has. So the first decision is mostly made for you: keep the raw turns, derive durable documents from them, do the derivation off the hot path. Where the real choices begin is in how you do that derivation.

Which brings us to consolidation, the second decision, and the first one that is genuinely contested. You have raw turns piling up. When do you turn them into durable memory, and what do you keep? The naive answer, the one every tutorial reaches for, is eager consolidation: every time a turn comes in, fire an LLM at it, extract the facts, write them down. It is simple and it is current, and it is also, at scale, a quiet catastrophe for your token bill, because you are paying for an extraction call on every single message including the ones that contain nothing worth keeping. The 2026 research has a name for the alternative. RecMem, a paper out this year, calls eager consolidation a major cost driver and proposes recurrence-based consolidation that batches the work and defers it, trading a little staleness for a large reduction in spend. SimpleMem frames the same dilemma as a dial between retaining the full history, which is redundant, and reasoning hard over every turn to filter noise, which is expensive, and goes looking for the efficient middle. MemFly gives the tradeoff an actual objective function, an information-bottleneck criterion that balances compressing redundancy against keeping retrieval precise. The point underneath all three is the same: consolidation is a cost knob, and eager-on-every-turn is the most expensive setting on it.

Now the harder half of consolidation, the one that should keep you up at night. When you let an LLM rewrite your memory, the memory degrades. There is a paper this year with a title that is the whole warning: “Useful Memories Become Faulty When Continuously Updated by LLMs.” The finding is that if you repeatedly run a model to rewrite a textual memory bank, edit by edit, the consolidated memory drifts and decays over time, accumulating small distortions until what you have stored is confidently wrong. There is a context-side mirror of this in the work on agentic context engineering, which names the two failure modes precisely: brevity bias, where concise summaries silently drop domain insight, and context collapse, where iterative rewriting erodes detail until the abstraction is hollow. Put those together and you get the central caution for this decision. Distillation is lossy, and compounding distillation is lossy in a way that hides. Each rewrite looks fine. The drift only shows up in aggregate.

So what do you do about it, in production, today? Look at what Slack shipped, because they hit this wall on real long-running agents and wrote up the answer. Their security-investigation agents run for hundreds of inference requests, far past any context window, and their first instinct, accumulating chat logs, broke. So they moved to structured memory with an explicit validation step, and the phrase they use is distilled truth. Concretely it is three channels. A Director’s Journal that holds structured working memory. A Critic’s Review that scores findings for credibility using evidence-inspection tools. And a Critic’s Timeline that builds a single coherent narrative by taking the journal, the latest review, and the previous timeline, then keeping only credible evidence, removing duplicates, and resolving conflicts. The load-bearing move is the second channel. They do not trust the LLM’s rewrite. They validate it against evidence before it becomes truth. That is the production answer to the degradation problem: treat distilled memory as a claim that has to be checked, not as a fact because a model said it. Keep your raw traces as ground truth, distill aggressively for speed, and put a validation gate between the distillation and anything that calls itself memory. The systems that skip the gate are the ones that drift.

The third decision is what data structure that durable memory actually lives in, and this is where the field is loudest and least settled. The options are real and they genuinely diverge: a flat vector store, an entity-relationship knowledge graph, a pile of atomic facts, event-grounded episodic records, or layered stores split by type. For a couple of years the momentum ran hard toward knowledge graphs. The pitch is seductive: model entities and relationships explicitly, accumulate structured knowledge, let the graph self-evolve, and you get relational reasoning that flat vectors cannot do. Mem0, Zep, supermemory all leaned in. And then the backlash arrived, and it is worth taking seriously because it comes from practitioners shipping this stuff. The sharpest version is a widely-read post arguing that knowledge graphs are simply the wrong abstraction for agent memory. The costs it flags are concrete: every write now needs an extra entity-extraction LLM pass, which is latency and money, and graphs hallucinate edges, fabricating connections between entities that were never actually related, when the real job most of the time is just fast retrieval of the right past context. Adding a graph can add a failure mode and a bill without adding an answer.

The research has been busy patching the graph’s specific pathologies rather than abandoning it. GAAMA, this year, targets the mega-hub problem, where a few popular entity nodes accrue so many edges that they dominate every traversal and the structure stops discriminating, and proposes graph-augmented associative memory that keeps structure without the hub blowup. But notice the deeper challenge sitting under the whole representation debate, which several 2026 papers raise at once: maybe atomic facts are the wrong primitive in the first place. The dominant pipeline takes raw dialogue, runs a handcrafted prompt to compress it into atomic facts, stores those, matches them, and injects them. A paper this year titled, roughly, “Rethinking How to Remember: Beyond Atomic Facts” argues that this compression throws away exactly what you need to reason deeply over history. The coherence-first alternatives are getting concrete. CAST grounds episodic memory in who, when, and where, modeling characters and scenes instead of disembodied facts, because a fact stripped of its event loses the thing that made it answerable. Amory argues that fragmenting a conversation into isolated embeddings or graph nodes destroys narrative coherence, and rebuilds a continuous narrative instead. The throughline: the unit of memory is a design choice with teeth, and the more you shred the conversation into shards optimized for retrieval, the more you lose the structure that made the conversation mean something.

Here is the practical floor, though, because it is easy to overbuild this. There is a builder’s writeup in the corpus whose whole lesson is that a great many agents do not need a vector database at all: SQLite with full-text search covers an enormous amount of ground with a fraction of the operational weight. So the representation decision is not graph-versus-vector at the top of a ladder. It is: start at the simplest structure that answers your actual queries, and add structure only when a query you genuinely need fails on the simpler store. Most systems reach for the graph long before they have a query that requires one.

That naturally leads into the storage substrate, the fourth decision, which is the layer underneath the semantic one: where do the bytes physically live? And the freshest movement here is a deliberate retreat to boring infrastructure. One proposal making the rounds is plain Git plus S3 as the entire memory substrate: versioned, cheap, auditable object storage, keep the full history forever because storage is nearly free, and derive your memory downstream from a durable log you never have to trust a service to hold. A 2026 paper called GitOfThoughts takes that seriously and measures it, treating Git as the persistence layer beneath the semantic memory, each session its own repo, cross-problem insights on a memory branch. What is striking is the number it reports: roughly fifteen milliseconds per write and forty-eight per read, the same order of magnitude as an embedding index’s read latency, while Git uniquely buys you tested three-way merge with conflict surfacing, signed commits, and reproducible bundles. The substrate you would have dismissed as too primitive performs in the same ballpark as the bespoke one and gives you an audit trail for free.

The substrate decision also has a piece people consistently miss, and AWS drew the line cleanly this year. There is a difference between durable knowledge and durable working state. Bedrock AgentCore’s runtime added managed session storage that persists an agent’s filesystem state, the code it wrote, the packages it installed, the artifacts it generated, across stop and resume cycles, state that used to simply vanish when the session ended. That is not semantic memory. It is the agent’s desk, preserved. The design lesson is to keep those two layers distinct: the runtime can own session durability, the working filesystem an agent resumes into, while your memory store owns distilled knowledge. Conflate them and you will end up either stuffing transcripts into a knowledge store or trying to make a knowledge store hold a filesystem, and both go badly. The substrate spectrum runs from SQLite-and-full-text at the pragmatic floor, through object storage and Git for cheap auditable history, up to managed runtime storage for working state, and the right answer is usually a combination, chosen per layer, not one store asked to do everything.

Now the fifth decision, and the one I would argue is the most under-respected: retrieval. The reason it is under-respected is that the default is so easy it does not feel like a decision. Embed the query, embed the memories, return the nearest neighbors by cosine similarity, done. And that default is wrong often enough, in a specific way, that the entire production frontier has moved off it. The problem is that cosine similarity measures surface semantic closeness, and surface closeness is not relevance. A memory can sit right next to your query in embedding space and be completely useless for answering it, while the memory you actually need, the one whose connection to the question runs through an inference rather than through shared vocabulary, sits far away and never surfaces. A 2026 paper, AdaMem, makes this its whole thesis: memory systems lean too hard on semantic similarity, which misses user-centric evidence, and they store related experiences as isolated fragments, so the one relevant thing is both ranked wrong and disconnected from its context. The blunt version comes from a production thread in the corpus: people report that vector-DB RAG, summary-plus-embedding hybrids, all of it works for demos and then breaks once the agent runs a while, because it keeps pulling stale context purely on semantic closeness.

So what do the systems that have actually solved this do? They stop doing a single lookup and run several channels in parallel, then fuse the results. Cloudflare’s Agent Memory is the cleanest public blueprint, and it is worth naming all five channels because the decomposition is the lesson. One: full-text search, the lexical channel, for exact terms. Two: exact fact-key lookup, a direct hit on a structured key. Three: raw message search, going back to the literal transcript. Four: direct vector search, classic dense semantic retrieval. Five, and this is the clever one: a HyDE channel, where the system generates a hypothetical declarative answer to the query and embeds that, to catch the case where the question and the answer share no vocabulary at all. Five channels run at once, and then the results are merged with Reciprocal Rank Fusion, RRF, which combines them by where each result ranked within its own channel rather than by raw scores you cannot compare across channels. And the weighting tells you their model of relevance: the exact fact-key match gets the highest weight, because an exact topic hit is the strongest possible signal, while raw message matches get a low weight as a safety net, a backstop to catch things the extraction pipeline missed. There is even a tidy engineering detail in their model choices, a smaller mixture-of-experts model for extraction and classification and a much larger one reserved for synthesis only, because they found the big model only earned its cost at the final synthesis step.

This is not one vendor’s idiosyncrasy. It is convergent. Mem0’s own State of Agent Memory writeup this year credits multi-signal retrieval, running semantic similarity, keyword matching, and entity matching in parallel rather than in sequence, as one of two changes that drove their benchmark gains, reporting numbers like ninety-two and a half on LoCoMo and ninety-four point four on LongMemEval at around sixty-nine hundred tokens a query, against a full-context baseline that burned roughly twenty-six thousand tokens to score worse. The research front is doing the same thing with more structure: a bi-temporal engine called Engram retrieves through four parallel channels, dense semantic, BM25 lexical, graph traversal from the query’s entities, and recency-slash-salience, fuses them with RRF, and then assembles a deliberately hybrid context of conflict-resolved facts plus raw session chunks, because, they show, facts alone lose recall. The pattern to internalize: retrieval is not a lookup, it is an ensemble. Decompose relevance into the signals that actually carry it, run them in parallel, fuse with rank fusion, and keep a raw-text safety channel so the extraction pipeline’s misses do not become the system’s misses. If you build one thing from this episode well, build the retrieval ensemble.

There is a subtler retrieval decision riding alongside that one, and it is about when to retrieve at all. The reflexive design retrieves on every step, RAG-at-every-turn, and a 2026 paper, “To Retrieve or To Think,” calls that out as a rigid, brute-force strategy that wastes compute and can actively degrade performance by flooding the context with retrieved noise the model then has to fight through. The reframe is to make retrieval a policy decision the agent makes, retrieve when you need external evidence, reason from what you already hold when you do not. That decision, retrieve versus think, is a lever most designs leave permanently jammed in the on position, and turning it into an actual choice is both cheaper and, often, more accurate.

The sixth decision is temporality, and it is the one that breaks more production systems than anything else without anyone seeing it coming, because it looks solved until the day a user updates a fact. Here is the failure, lifted straight from a corpus thread: someone is running Mem0, their user changes a piece of information, and the agent develops amnesia about the timeline, can’t tell that the new fact supersedes the old one, ends up holding both, or surfacing the dead one as if it were current. The naive design has memory as a flat set of facts with no time axis, so when reality changes there is no principled way to know which version is current. The fix the field has landed on is bi-temporal modeling: track two clocks, not one. Valid time, when something was actually true in the world, and transaction time, when your system learned it. Aurra, which that same thread reaches for as the upgrade, differentiates exactly on bi-temporal modeling, and the Engram paper makes it first-class: a contradicted fact is not deleted, it is invalidated, with an invalid-at timestamp set and a supersedes pointer kept, so a point-in-time query, what did we believe was true as of last March, resolves correctly against history. Engram reports its knowledge-update and temporal-category scores rest precisely on that bi-temporality being built in rather than bolted on.

The design decision underneath is sharper than just adding timestamps. When a user’s fact changes, you have three options, and they are not equivalent. You can silently overwrite, which is the default and which destroys your ability to ever answer an as-of question or audit what changed. You can version, keeping both with a currency marker. Or you can supersede, the bi-temporal move, marking the old fact invalid-from a moment while keeping it queryable. Silent overwrite is the one that feels fine until it doesn’t, because the day someone asks why the agent did what it did six weeks ago, the history is gone. And there is a research caution stacked on top of this: the contradiction-detection problem is hard, and the “Useful Memories Become Faulty” finding means you cannot just throw every fact update at an LLM and trust it to reconcile cleanly, because that reconciliation is exactly where the drift creeps in. Detecting that two facts conflict, deciding which wins, and recording the supersession without corrupting the record is a real piece of engineering, not a property you get for free from your store.

Seventh decision: forgetting. And the reframe I want you to take from this one is that forgetting is not primarily a cost optimization. It is a correctness and safety requirement, and it is almost completely unmeasured. The default non-decision is that memory only grows. You write and you write and nothing ever leaves, and the store slowly rots, accumulating stale facts and dead context that drag every retrieval down. The bio-inspired research cluster offers an elaborate lifecycle as the alternative: a human-inspired architecture this year proposes sleep-phase consolidation, interference-based forgetting, engram maturation, reconsolidation on retrieval, the full neuroscience toolkit, turning forgetting from a crude time-to-live into a set of principled mechanisms. SuperLocalMemory bundles biologically-inspired forgetting with multi-channel retrieval in a zero-LLM local package, opening on the paradox that a coding agent can hold vast parametric knowledge and still not remember what happened an hour ago.

But the sharpest result on forgetting is the one that reframes it as safety. PersistBench, a 2026 benchmark, points out that persisting a fact like the user is vegetarian helps personalization and also introduces a safety risk that is largely overlooked, and it sets out to measure when persistence becomes a liability, when a memory should be forgotten rather than kept. And a paper this year, with the unwieldy name about observability-safe memory retention, treats what-to-forget as the primary decision rather than a side effect of retrieval. It trains an evidence learner offline from gold-evidence labels, not from an LLM’s guess at importance, to decide what to retain, and crucially it runs deliberately below full capacity, stopping early when no remaining candidate looks useful. That last detail matters: the system chooses to hold less than it could, because holding more is a liability, not a virtue. The throughline for your design: build an explicit lifecycle, decide on purpose what leaves and when, and treat some forgetting as mandatory for safety rather than optional for cost. The reason this is so under-built is the reason it is dangerous: there is almost no benchmark pressure on it. As Mem0’s own writeup admits, nearly every public benchmark grades the retrieval step, and the write step, deciding what is even worth keeping out of a conversation that is mostly noise, is barely measured at all.

The eighth decision is who the memory belongs to: per-user, per-agent, or a shared team profile. The single-user case is the easy one and not where the interesting tradeoffs live. The moment you have multiple agents collaborating, you face a real choice. Do they each keep private memory, or do they read and write a shared store? Cloudflare productized the shared answer with shared memory profiles, letting multiple agents access common knowledge, which is exactly what you want when a fleet of agents should not each independently rediscover the same fact. But sharing memory across long-running agents reintroduces the coherence problem at the team level, and the naive version, every agent dumping its full trace into a common pool, is a disaster of noise and contradiction. Slack’s three-channel design is one answer to keeping a multi-agent system coherent without that dump. A 2026 paper, DeLM, decentralized multi-agent systems with shared context, is another and a cleaner statement of the principle: instead of dumping full traces or routing everything through one main agent, the team shares a single verified context, agents read compact gists by default and unfold detail only on demand, and there is admission-time verification gating what is even allowed to enter the shared state. That gate is the same idea as Slack’s critic, applied to the team store: shared memory needs a bouncer, or it fills with garbage and one agent’s hallucination becomes every agent’s premise.

And there is a hard operational fact about shared, multi-agent memory that the corpus surfaces and that the framework-published benchmarks tend to hide. A paper this year, on the cost and accuracy of long-term memory in distributed multi-agent systems, builds a testbed across cloud and edge and runs the comparison everyone actually wants, vector-based Mem0 against graph-based Graphiti and Zep, on system-level cost and accuracy, not just the tokens and latency the framework vendors report in their own evals. That distinction, system-level cost versus framework-reported cost, is the whole game when you scale to many agents, because the costs that kill you, the cross-agent coordination overhead, the consistency machinery, show up at the system level and are invisible in a single-agent benchmark. If you are splitting work between a vector store and a graph store across a multi-agent deployment, that head-to-head is the most decision-useful thing in the corpus.

Which lands us at the ninth decision, the one that turned into a real market in the last twelve months: build versus buy. For most of this field’s short history there was nothing serious to buy, so the decision was trivial, you built. That is no longer true, and the change is recent enough that I want to give you the actual landscape as it stands in mid-2026. On the framework side, the named incumbents are Mem0, Zep, LangMem, and Letta, the open-or-self-hostable layers that pioneered the category. And then, in roughly the last year, every hyperscaler shipped a managed memory service and turned memory from a thing you build into a line item you provision. Amazon’s Bedrock AgentCore Memory went generally available, with short-term and long-term tiers, asynchronous extraction, and this year added metadata so you can tag and filter long-term records alongside semantic search, plus streaming notifications so you stop polling for memory changes. Google’s Vertex AI Memory Bank went generally available too, and here is the detail that tells you the market has matured: on January twenty-eighth this year, Google started charging for it, twenty-five cents per thousand stored events or memories. When a cloud provider starts metering a feature per thousand units, it has graduated from demo to infrastructure. Microsoft, at Build this year, pushed somewhere the others had not: procedural memory in Foundry Agent Service. Not just facts and preferences, but successful execution patterns, captured as structured items that record both when to use a procedure, the task context and preconditions, and what to do, the ordered actions and required checks, then retrieved and injected when a similar task appears. Their early numbers are real and modest, on the order of seven to fourteen points of absolute success-rate gain on Tau-bench at near-baseline cost, and they paired it with a governance surface, a portal where developers can view stored memories and do CRUD on individual items, plus time-to-live controls. That governance and TTL pairing is the tell: this is memory built for people who have to answer to compliance, not just to a benchmark.

So how do you make the build-versus-buy call now that buying is real? The managed services buy you asynchronous extraction, durability, and increasingly a governance surface, all things that are tedious and easy to get wrong. What they cost you is control over the representation and the retrieval logic, which, per everything in the first eight decisions, is exactly where the differentiation lives. The corpus also carries a strong counter-current of builders going the other way on purpose: the SQLite-and-full-text floor, the Git-and-S3 substrate, the self-hosted conversation archives, all motivated by wanting to own the bytes and the logic. The real framing is that this is a layered decision, not a single one. You might buy durable session storage from the runtime, build your own retrieval ensemble because that is your edge, and lean on a managed extraction pipeline for the consolidation you do not want to babysit. Buy the plumbing, build the part that is your product.

The tenth decision is the one that bites the day after you pick a vendor: interop. Because here is the uncomfortable fact the corpus states plainly. Mem0, Letta, Cognee, Zep with Graphiti, MemoryOS, MemTensor, each ships its own SDK, its own storage layout, its own vocabulary, and there is no shared wire format among them. The consequence is brutal and concrete: every integration is bespoke, every migration rebuilds your memory from scratch, and, the part that should alarm anyone in a regulated shop, none of them ships a governance surface to review what gets written and read. You do not just get locked in. You get locked in with no audit trail. The proposed fix in the corpus is memorywire, a vendor-neutral wire format for agent memory operations, and in the last weeks a second, complementary effort surfaced in the fresh research: Portable Agent Memory, which positions memory as the third leg of an interoperability stack, MCP standardizing how agents reach tools, A2A standardizing how agents delegate to each other, and portable memory standardizing how agents transfer accumulated knowledge, with a defined set of operations, remember, recall, forget, merge, expire, and a concrete artifact format, human-readable JSON by default and a compact binary option for constrained transport. Two independent groups converging on the same gap in the same quarter is the field telling you this matters and is not yet solved.

There is a quieter, human-facing companion to the wire-format problem, which is schema. A good writeup in the corpus argues that agent memory is only as good as its schema, that memory quality is bounded by schema quality, and that if you get the schema wrong, no amount of clever retrieval or consolidation downstream can recover what the schema failed to capture. That reframes interop as not merely a portability convenience but a design discipline: an explicit, reviewable schema is the thing that makes your memory both migratable and auditable, and the absence of one is why DIY unification efforts, the builders in the corpus gluing Mem0 and Memori and Supermemory together by hand, are so painful. They are reconciling three implicit schemas that were never meant to meet. So the interop decision, even if you are nowhere near switching vendors, is really a decision to make your schema explicit now, while it is cheap, rather than discover it implicitly later, when it is load-bearing and undocumented.

Interop bleeds directly into governance and security, which I am treating as the eleventh region of the tree because in production they are inseparable, and because the corpus is blunt that the memory frameworks largely lack a governance surface entirely. Start with multi-user isolation, the most basic and most violated invariant: one user’s memory must never surface in another user’s context. It sounds trivial and it is a frequent, expensive breach, because a shared retrieval index without hard per-user scoping will happily return a neighbor’s nearest-neighbor. But the threat that the persistent-memory design specifically creates, the one that does not exist for a stateless agent, is memory poisoning. And the distinction from ordinary prompt injection is the whole point. Prompt injection corrupts a single conversation, a single response, and then it is gone. Memory poisoning embeds the malicious content into persistent storage, so it remains, indefinitely, influencing every future interaction. The security writeups this year are sharp about a consequence builders miss: the standard defense against prompt injection is session isolation, every conversation starts from a clean context, and that defense does nothing against memory poisoning, because the poison lives in the store the clean session reads from. The mechanism is uglier than it sounds. An attacker does not need to talk to your agent directly. They plant the instruction in a document, a web page, a support ticket, anything the agent will later read, and if your consolidation pipeline extracts a fact from that poisoned source and writes it to long-term memory, the injection has installed itself permanently. The next clean session reads it back as established truth, and the agent has no way to tell a planted memory from an earned one, because by the time it is retrieved they are byte-identical. Worse, in a multi-agent system the poison propagates: a corrupted memory in a shared profile influences every agent that reads it, and one agent’s compromised premise spreads through the fleet by normal message passing. Memory is the one component that lets an attack outlive the conversation it arrived in.

The design implications are concrete and they are the same set of moves the better systems already make for other reasons, which is the good news. Hard per-user and per-tenant scoping on every retrieval, enforced at the store, not in the prompt. An admission gate on writes, the same critic-style validation Slack uses for coherence, doing double duty as a security control, because the gate that checks whether a distilled memory is true against evidence is also the gate that catches an injected instruction trying to install itself as a fact. Provenance threaded through every memory, so you can answer where this came from and revoke a poisoned source, which is exactly the provenance that the Engram representation carries on every fact and that the Git-based substrates give you as version history. Snapshot and rollback, so you can recover the store to a known-good state after a poisoning event. And the governance surface itself, the human-auditable view over what gets written and read that the wire-format paper calls out as missing and that Microsoft’s Foundry portal is one of the first managed offerings to ship. The pattern is that the coherence machinery, the temporal machinery, and the security machinery are largely the same machinery: validation gates, provenance, supersession, audit. Build them once, for any of those reasons, and you have most of what you need for all three. The systems that treat memory as a passive store and bolt security on later find that there is nowhere to bolt it, because there is no gate, no provenance, and no audit surface to bolt it to.

Now the part that ties every one of these eleven decisions in a knot, the thing this whole episode opened on: how do you know any of it works? Evaluation is the decision that audits all the others, and the corpus is unanimous and a little alarming about how badly the field has been doing it. The core mistake is measuring answer correctness and calling it memory quality. There is a beautifully clean demonstration of why that fails in a paper on structured belief state and precision-aware benchmarking. The observation: if you just return the entire belief store on every query, you get perfect recall, you pass the answer-quality eval, and you have built a useless retrieval system, because dumping everything is not retrieval. Which means answer correctness cannot validate a retrieval system at all. It is the unit-test-versus-integration-test problem. A green integration test, the right final answer, tells you nothing about whether the unit underneath, the retrieval, actually did its job, or whether the model just compensated for bad retrieval by reasoning over a pile of junk you handed it.

And when you do separate the two, the result is genuinely surprising and it should redirect where you spend your effort. A 2026 paper, MemTrace, evaluates thirteen memory systems and separates retrieval-correctness from answer-correctness, and finds that when a system answers wrong, the evidence it needed was already retrievable about ten times more often than it was actually missing. Read that again, because it inverts the common intuition. The dominant failure is not retrieval. It is evidence use. The right memory was in hand, and the system still got it wrong. Systems with identical pooled accuracy fail in completely different places once you pull the two apart, which means the single accuracy number everyone reports is actively hiding where the problem is, pointing your optimization at storage and retrieval when the real bottleneck is the model failing to use evidence it already has. StreamMemBench operationalizes the same split with a four-metric design, separating whether evidence is retained from whether it is actually used, and warns specifically that a system can inflate its retention score just by hoarding raw text, the same dump-everything trap. And the benchmark frontier is moving past factual recall entirely: LoCoMo-Plus targets the beyond-factual setting, whether the agent honored implicit constraints, the user’s state and goals and values that were never explicitly queried later, which is precisely the user-centric relevance that AdaMem argued cosine similarity misses.

There is one more evaluation finding I want to leave you with because it is the most humbling, and it comes from GitOfThoughts measuring when memory helps at all. They run a similarity sweep and find a copyability threshold. When the retrieved past case is a near-duplicate of the current problem, cosine similarity above roughly point-eight, accuracy jumps twelve to thirteen points. Below that threshold, nothing helps. And the gain, even at the top, is answer retrieval, not method transfer. The system is essentially finding a near-identical worked example and copying its answer. It is not extracting a transferable method from a related-but-different case, and a backbone four and a half times larger steepens the near-duplicate effect but still cannot pull a reusable method out of a worked example. That is a quiet, important result. A lot of what we call agent memory, measured rigorously, is sophisticated near-duplicate retrieval, and the thing we most want, learning a general lesson from one situation and applying it to a genuinely new one, the cross-trajectory abstraction the research literature calls the frontier, is exactly the thing these systems mostly cannot yet do. Measure your system rigorously and you may find it is a very good lookup wearing the costume of learning.

Let me pull the tree together, because eleven decisions is a lot to hold and the shape of it is the takeaway. Start with the data model: sessions, turns, consolidated documents, raw traces as ground truth and distilled docs derived off the hot path, which is what all three hyperscalers independently shipped. Then consolidation: defer it, because eager-per-turn is a cost trap, and gate it, because LLM-driven rewriting drifts, which is the Slack distilled-truth lesson. Then representation: start at the simplest store that answers your queries, treat graph versus vector as load-bearing not fashionable, and respect the argument that atomic facts may be the wrong primitive. Then substrate: separate durable knowledge from durable working state, and do not dismiss boring object storage, which performs and audits better than you would guess. Then retrieval, the decision I would spend the most care on: an ensemble of parallel channels fused with rank fusion, never a single cosine lookup, with a raw-text safety net and a retrieve-versus-think policy. Then temporality: bi-temporal modeling, supersede rather than overwrite, so as-of queries and audits survive a fact changing. Then forgetting: an explicit lifecycle where some forgetting is a safety requirement, in a field with almost no benchmark pressure to do it. Then shared memory: a verified admission gate on the team store, because shared memory without a bouncer fills with one agent’s hallucinations. Then build versus buy: a layered call now that the hyperscalers have made buying real, buy the plumbing, build the retrieval that is your edge. Then interop: make your schema explicit now while it is cheap, because two separate standards efforts this quarter are telling you the lock-in is real. And governance and security woven through all of it: per-user isolation at the store, provenance on every memory, admission gates that serve coherence and security at once, because memory is the one component that lets an attack outlive its conversation. And over all of it, evaluation: separate retrieval-correctness from answer-correctness, because the single accuracy number lies, and the real bottleneck, ten times out of eleven, is using evidence already in hand.

I will close where the field is genuinely stuck, because the open problems are sharper than the solved ones. First, the write step is unmeasured. We benchmark retrieval obsessively and barely measure what to keep, when to forget, how to reconcile a contradiction, which is to say we measure the easy third of the pipeline and look away from the hard two-thirds. Second, distilled memory degrades when an LLM maintains it, and our only real defense so far is to not fully trust the LLM, to keep raw traces and validate against evidence, which works but is an admission that we cannot yet let the system maintain its own memory unsupervised. Third, the systems we call learning are mostly near-duplicate lookup, and genuine cross-situation abstraction, the lesson learned once and applied somewhere new, is still out past the copyability threshold for everyone. Fourth, there is no shared wire format and no standard governance surface, so memory is non-portable and largely un-auditable at exactly the moment it is becoming the most security-sensitive component an agent has. And fifth, underneath all of it, we still cannot reliably tell, in production, whether a fluent answer rests on a real memory or a confidently wrong one, because they come out of the model sounding identical, and until we can attribute a failure to the precise stage that caused it, the write, the consolidation, the retention, the retrieval, or the use, we are tuning a pipeline by its final output and hoping. Memory is the feature everyone demos. The work that turns it into a feature you can trust is the part nobody can show you in five minutes, and it is most of these eleven decisions, made on purpose, measured rigorously, and gated every step of the way. That is the design problem. Go build it carefully.