Summary
Every agent in your organisation starts each task knowing everything the internet knows and little of what your people know. The foundation labs are working on the first half. This paper is about the second.
"Memory" is the word the industry uses for that second half, and it has come to mean three things that build on each other: storing what happened, recalling it on demand, and learning from it. Most products stop at the second. We optimise for the third, which we define as a measurable change in what agents get right. Everything else in the design follows from that choice.
The first consequence is that the memory is shared. Learning is faster when done collectively, so ours is shared across agents and people. That sharing, however, changes what the memory can assume. A note an agent writes for itself can be taken at face value; a note written by a colleague, or by a colleague's agent, cannot be implicitly trusted. So each piece of shared knowledge carries two additional data fields: how likely we think it is to be right, and how much evidence sits behind that estimate. Both are updated every time the knowledge is used and the outcome is seen.
The second consequence is that the memory has to do more than remember. Remembering is not enough for learning, so the memory also abstracts rules from cases, resolves contradictions, and forgets what has stopped being true.
The test of all this is whether the agents get better, and the result we measure is operational. In our 'Learning on the job' paper [1], agents working the banking domain of τ-bench [2] that learned from reviewer corrections solved 2.6 times as many tasks as the same agents with static retrieval over the full policy corpus. Each of two model families, reading the memory built by the other, rose above its own no-memory baseline. On our own public scenario, built so that every task seen by the agent is new, agents without memory comply 20% of the time, while those with shared memory reach 64%, on average over the run. The gap opens within the first few tasks and widens as corrections accumulate over a hundred of them [3]. The knowledge accumulated this way is an asset. It outlives the model that produced it and it makes the next agent cheaper to bring in than the last.
Alongside the argument, six email scenes tell the same story from inside an organisation. Hallam Reed is a mid-tier advisory firm whose regulatory practice has started using drafting agents. Its people, its clients and the regulation they advise on are invented; the problems are ones we have seen real firms meet. The emails appear between sections, and the sections refer back to them.
1The three shapes of 'memory'
Ask three vendors what memory means and you will get three products. The first collects everything the agent did (trace storage). The second finds the right piece of that record when a new task needs it (recall). The third changes what the agent does next (learning). Each builds on the one before, since you cannot recall what you did not store and you cannot learn from what you cannot recall. Each is a legitimate product, making three different promises, and it pays to know which one you are being sold.
Storage is the base layer. The typical product today collects traces: every prompt, tool call and response an agent produced, kept in full and searchable. A markdown file the agent appends to is also storage. So is a long context window, with the property that it is emptied at the end of every session. Storage answers what happened? and nothing else, and it grows without limit because nothing in it decides what was worth keeping.
Recall is where most of the field sits. Given a new task, find the past fragment that helps. This is the problem the memory benchmarks measure: LoCoMo [4] and BEAM [5] present a long single-user conversation and score the agent on whether it can answer questions about earlier turns. Recall is a real capability and it is easy to score, which is a large part of why it gets measured.
Learning is a different claim. An agent that has learned behaves differently on a task it has never seen, and the difference can be measured as an outcome: fewer corrections at review, fewer tokens per task, a higher rate of decisions that hold up. The record of what happened is an input to learning, and recall is one of the mechanisms used, but neither is the direct outcome being measured.
All three exist in miniature. The methodology document and the agents' own transcripts are storage. A search over them, which is what the drafting agent did before writing section 4 of the Meridian assessment, is recall. Learning is what would have to happen for the next assessment to treat the outage as reportable without anyone repeating Priya's email. Scene 1 shows the practice with the first two and not the third.
The distinction matters because the three sound alike in a demo but diverge in production. A storage product looks like learning for a week, until the file grows past what the agent can read. A recall product looks like learning until the day two retrieved fragments disagree. The rest of this paper is about what it takes to build the third thing, and why the first two are not enough on their own.
Scene 1. An agent applies the written methodology and gets the answer wrong, because the current position was adopted after a regulator's letter and never written up. The knowledge exists; it lives with Priya.
2What we measure
Here is the definition we work to. Learning is a change in agent behaviour on unseen tasks that improves a measured outcome, where the change is caused by the agent's own operation rather than by retraining or by a human editing its instructions. In this definition, unseen rules out replaying a solved task; measured outcome rules out "the agent seems more helpful"; own operation rules out fine-tuning and prompt engineering, both of which are ways of making agents better but neither of which would be 'learning on the job'.
That definition also fixes what we compare against. The baseline is the same model, the same tools, the same tasks, with the memory removed. Whatever the difference is, the memory caused it.
Measuring learning
The standard memory benchmarks are the wrong instrument for this. LoCoMo and BEAM present one long conversation with one user and ask whether the agent can recall what was said. Passing them shows recall works, but doesn't necessarily mean the agent does its job better.
τ-bench [2] is closer to what we want. An agent handles customer requests against a set of business rules, and a second model plays the customer, wording each request differently on every run. The problems repeat in spirit and never in text, which limits what memorisation can achieve. On its banking domain, we compared agents that could read what earlier runs had learned against a static-RAG control retrieving over the complete policy corpus. Learning from a one-bit success or failure verdict lifted single-trial success to 1.6 times the baseline; learning from reviewer corrections lifted it to 2.6 times, and converted 22 of the 84 tasks the baseline never solved. We ran this on Mistral Large, an open-weights model an organisation with sovereignty requirements can self-host, and replicated it on Claude Sonnet 5. Each model, reading the memory the other had built, rose above its own no-memory baseline [1].
τ-bench still allows an agent to meet a request it has effectively seen before. So we built our own open benchmark, Fenmoor Supplies, a fictional B2B distributor whose order desk runs on 29 policies that live only with the reviewer: a customer who gets net-60 despite a net-30 policy, a product line never shipped to one region. The library holds 200 distinct tasks, each drawn with randomised phrasing and in randomised order, and the control arm answers the same emails without memory. Over a hundred tasks, compliance with the hidden policies gets a memory advantage of 47 percentage points on average over the full run (95% CI 41 to 52). The scenario and harness are public [3].
We report compliance because it is the number an operations lead would look at. Token savings on the same runs are real and secondary; a cheaper wrong answer is still wrong.
Two things about how those results were produced matter beyond the numbers, and directly impact the design the rest of the paper describes.
The first is what the agents learned from. The 2.6× result came from one signal, reviewer corrections, and nothing else. That signal is where the knowledge lives. Priya's position on clause 7.3 surfaces as a correction: a draft applies the four-hour test and she sends it back. The correction is the knowledge. Until that moment it existed nowhere except in Priya's head, so a system that only stores what was said, or only retrieves what was written, has nothing to store and nothing to retrieve. The memory has to capture knowledge at the moment the gap shows itself, because there is no earlier moment at which it exists.
Those moments exemplify a signal that the organisation already produces in its day-to-day operations. Every deployed agent is already being corrected. A reviewer amends a draft, a colleague overrides a decision, a customer replies that the answer was wrong, a test fails. These corrections already exist, and today most of them are used once and discarded. Our memory treats them as the learning signal. When a correction arrives, the agent records what it got wrong and what the right answer was, and the record is available to every agent that faces a similar task afterwards. Nothing new has to be laboriously labelled, no evaluation set has to be built. The review process the business already runs is the one that makes agents better next time. Priya's January email is a complete learning signal on its own; the practice needs nothing further from her. The marginal cost of learning is close to zero.
The reinforcement learning community has made the same observation about deployed systems: recommendation engines see engagement, coding assistants see acceptance rates, and leaving that signal unused leaves performance on the table [8]. The difference is that our agents' weights don't need to be expensively retrained; the learning goes into the memory instead.
The second is what the agents learned into. The result in our 'Learning on the job' paper was produced on two model families, and the memory built by one lifted the other, so whatever was learned was held outside either model. For a buyer this is the difference between an asset and a dependency. Models will be replaced every year or two. Knowledge fine-tuned into weights dies with the weights; knowledge held outside them moves to the next model with the agents. The memory has to survive the model, and these results show that it can.
Both points are about what happens after a correction. Scene 2 is about what happens when nothing does.
Scene 2. A second agent makes the same error a month later. The correction was written in January and reached nobody, and the cost of re-correcting it is now visible to finance.
3Learning is faster when it is shared
Two agents at Hallam Reed made the same mistake a month apart. After the first one, the correct position existed in an email from Priya to Nadia. Draft-2 never saw it, and neither would Draft-3. Every agent that joins the practice will apply the four-hour test until somebody tells it otherwise, one agent at a time.
That is the default state of agent memory today. Most harnesses now give every agent a memory of its own, which means the agent that was corrected does not make that mistake again. But the lesson stops there. An organisation running fifty agents is running fifty apprentices who never talk to each other, and they have to be corrected fifty times over before the practice as a whole has learned something.
People solved this a long time ago. Writing, apprenticeship and institutions exist so that one person's mistake becomes everyone's lesson. Shared memory gives agents the same arrangement. One correction, recorded once, changes what every agent does next.
The arithmetic is what makes this worth the trouble. With private memories, a fleet of N agents needs a lesson taught N times. With one shared memory it is taught once, and the more agents there are the larger the gap. The benefit compounds in the other direction too: an agent that is corrected rarely because it works on quiet accounts still benefits from the corrections given to its busier colleagues.
Sharing crosses models as well as agents. In our 'Learning on the job' paper [1], Mistral Large reading the memory built by Claude Sonnet 5 went from 6.4% to 28.9% task success, and Sonnet reading Mistral's memory went from 24.8% to 31.4%. Neither model was trained on the other's experience, and the memory contained no weights, only what earlier runs had written down. For an organisation this means the memory is a property of the organisation rather than of any agent, model, or vendor. Agents can be retired, models replaced, and harnesses swapped, and the lessons stay.
Sharing also has a cost, and it is the subject of the next section. A private memory contains only its own agent's corrections, and those can be trusted. A shared memory contains everyone's, including the ones that were wrong, the ones that were right at the time, and the ones that conflict with each other.
Scene 3. The first thing most teams try: a shared file every agent reads. It fixes the original error and fails on the next one, because a file has no record of who wrote what, cannot see that two entries disagree, and gives the last word to everyone.
4Shared memory needs a trust model
Priya's April email lists three things the shared file could not do. It did not know who wrote each entry. It did not know that two entries disagreed. It had no way to choose between them other than taking whichever was written last. Those three gaps are the requirements for any memory that more than one party writes to: provenance, detection of conflict, and a basis for resolving conflict that is better than recency. A file meets none of them. Neither does a vector store; retrieval by similarity will return both conflicting entries and leave the agent to choose.
Our answer is that every piece of knowledge in the memory carries a trust estimate, represented in two parts. The first is how likely the knowledge is to be right. The second is how much evidence sits behind that judgement. Two positions can both be rated as probably correct while one rests on a single review and the other on forty. When a contradicting review arrives, the first moves a long way and the second barely moves, which is how a person's belief would change based on the same input.
Figure 1. Two positions the memory considers probably right. Position A has been reviewed once; Position B forty times. The line is the memory's judgement; the shaded range is how far that judgement could still be off. One overturned review would move A a long way and B hardly at all.
Trust starts with provenance: a new position inherits the standing of whoever contributed it. And standing is a record rather than a title: a director's past corrections have been upheld more often than most, so her new position enters with more weight than a first draft from an agent, for that reason. From then on the position earns or loses trust on its own record: each time it is applied and the outcome is seen, the evidence updates, and the update flows back to the contributor as well. Contributors whose positions hold up at review gain standing; contributors whose positions are overturned lose it. Scene 4 shows the consequence that surprises people: a second-year associate's position on clause 9.1 outranks the methodology document on that clause. That happens because it has survived six reviews and the document's wording has not been tested since it was written. Trust in the memory is a track record that needs to be earned.
Evidence also ages. Trust in a position that has not been used or confirmed for months is allowed to weaken. The memory still thinks the position is probably right; it is just less sure, so the next review carries more weight than the fortieth did in the spring. This is what lets a memory that was correct in March become uncertain by August without anyone deleting anything, and it is the bridge to the next section.
All of this rests on one claim: that the system's trust estimates approximate the truth. Priya's positions are weighted highly because they have usually been right in the past. That is easy to state and worth checking, so we built a simulation in which every contributor has a hidden competence, every position has a hidden correctness, and the memory system sees neither. All it sees is reviews. Each review is a noisy signal, because reviewers are contributors too and their own competence is variable. As positions get reviewed, the system continually updates its trust score for each position, and for each contributor.
Reviews arrive on positions, so position trust is where the signal lands first. A position starts with the standing of whoever wrote it, so positions from reliable contributors already begin ahead. From there, every new review pushes right positions up and wrong positions down.
Figure 2. Trust in positions that are actually right (orange) and actually wrong (grey), against the number of reviews each has received. Each line is the average for its group. Individual positions vary around that average, and the shaded band shows how much: half of the group's positions fall inside the band, a quarter above it, a quarter below. The two groups are already apart before any review, because of who wrote them, and a handful of reviews pushes them further apart.
Each review then flows through to the people and agents behind the position: the contributor whose position is upheld gains standing, and the contributor whose position is overturned loses it. Contributor trust accumulates more slowly, because it is a more consequential decision and requires more evidence.
Figure 3. Estimated trust in three contributors, in a simulated population whose average competence is 80%. Solid lines are what the memory believes; dashed lines are the hidden truth it never sees. Every contributor starts at 50%. Within about thirty contributed positions the memory has them in the right order, and the estimates keep moving towards the true values as reviews accumulate.
Over a run of reviews, positions that are wrong are separated from positions that are right, and the memory orders contributors correctly while moving each estimate towards that contributor's hidden competence, all on the basis of review outcomes alone. The mechanism recovers the hidden state of the world from the feedback it is given, which is the property the design needs.
The cost to this approach is that a good position from a new contributor enters with less weight than it deserves. That real weight is recovered within a handful of reviews, however.
Scene 4. Each position now carries its author and its record at review, and the record sets its weight. Trust is earned rather than assigned: a second-year's position outranks the methodology document on a clause where it has held up six times.
5Learning needs more than remembering
Everything so far has been about getting corrections into the memory and deciding which ones to believe. That ensures reliable remembering, and the trust updates are already a first form of learning, but the full step needs more, for reasons that show up within weeks of any real deployment.
The first is that corrections arrive as instances and get used as rules. Priya's January email is about Meridian's November outage. The knowledge the practice needs is that any customer-facing outage is reportable regardless of duration, which is a rule Priya implied in her email. A memory that stores the instance will help the next agent that handles Meridian and no one else. So the memory writes lessons scoped to the conditions they were learned under, and when several scoped lessons point the same way it abstracts them into a rule that applies to accounts none of them mentioned.
The interesting case is the rule nobody has stated. Suppose three engagements at Hallam Reed each get pushback from the regulator's case team in the same quarter. Meridian is told a short outage is reportable despite the four-hour figure in 7.3. Halden is told a sub-contractor change needs notification despite falling under the size threshold in 9.1. Corvus is told a data-residency exception in 11.4 does not apply because customers were affected. Three directors, three clauses, three corrections, each recorded as a scoped position on its own clause. Each director has seen one of them and has drawn the obvious local conclusion. Nobody in the practice has seen all three, so nobody has noticed that they are one finding: the regulator reads the DSCR by effect on customers and sets aside the numeric thresholds in the text.
The shared memory has seen all three, because all three were written to it. Its abstraction operator runs over the store looking for scoped positions that share a shape, and when it finds them it writes the general rule as a new position, linked back to its sources and carrying a trust record of its own. The next engagement retrieves the general rule and drafts defensively from the start. The submission to the regulator is accepted, and the abstracted position earns its first confirmation.
This is the argument for a shared memory that individual memories cannot make. Abstraction needs several instances, and in an organisation the instances land on different desks. A person who has seen one case has no way to tell whether it is an exception or the first sign of a pattern, and a personal memory holds that same single case. The shared memory holds all three, because every desk wrote its correction to the same place. It is the only party that sees the practice whole, and that vantage point is what lets it learn the general lesson on the organisation's behalf.
The second reason is contradiction. Two positions on clause 9.1 arrived in the same week at Hallam Reed, and a shared file could only keep the later one. Some apparent contradictions are not contradictions at all: a position for a bank and a position for a building society can both be right given enough context. So the memory's first move on a conflict is to look for the scope that separates the two. When there is none and the positions cannot both be true, the trust machinery from the previous section decides. The loser is kept with its record rather than deleted, because knowledge that a position is no longer trusted is also useful.
The third reason is that knowledge expires. For Hallam Reed the four-hour test was correct until October and wrong afterwards. Nothing about the text of a position tells you it has stopped being true, so the memory has to notice that from the evidence. Certainty decays with time: a position that goes unconfirmed loses standing slowly, so the next review carries more weight. Forgetting, in this design, means retiring positions that have stopped earning confirmation, and telling the difference between a position that was wrong and one that was right for a while.
Scene 5. A position that was correct in March is wrong in August. Two amended reviews had already lowered its standing before the director noticed, and the agents had started asking before using it. This is what maintenance looks like when the memory can age.
6What this means for a deployment
The design above was built for organisations, and organisations have constraints additional to those of a personal assistant. Here are some that shape how the memory is deployed.
The first is that models change. A firm that adopts agents this year will change the model underneath them more than once over the agents' working life, for cost, for capability, or because a vendor relationship ends. Everything the agents learned in that time has to survive the change. Fine-tuned knowledge does not, and neither does knowledge held in a harness that is retired with the model. The memory is the part of the system that outlives procurement cycles, and the cross-model result in section 3 is the evidence that it does. If Hallam Reed's technology group swaps the drafting agents for a new vendor's, the firm's positions come with them.
The second is sovereignty. Regulated firms and public bodies increasingly want agents running on open-weights models on infrastructure they control, and those models are smaller and less capable than the frontier. Models given a long context of loosely relevant documents answer worse rather than better [11, 12], and small models have the least headroom to absorb the noise. Curated knowledge is what small models need, a short list of positions that apply rather than a retrieval dump. We saw this in our first study of shared memory, where retrieval over raw documents lowered the quality of small models' output and a small set of shared, curated insights raised it [13]. The memory was designed for that regime, and the Mistral Large result in our 'Learning on the job' paper [1] is the demonstration that an open-weights model with a shared memory can do work it could not do alone.
The third is governance. Positions in the memory are the firm's know-how, and know-how has owners. The memory is organised as a hierarchy: a practice group's positions are visible to its own agents, a firm-wide layer holds what applies everywhere, and access at each level follows the same roles the firm already uses for its documents. What the memory holds is the generalised position, the rule and its scope and its record, rather than the client documents or the transcripts the rule was learned from. A director can read every position her group relies on and see where each one came from.
Figure 4. The memory as Hallam Reed deploys it. Each box is a layer: the firm layer holds what applies everywhere, each practice holds its own positions, and an engagement can hold positions that stay with its team. An agent reads its own layer and every layer above it in one query; what it writes lands in its own layer and travels no wider. Membership of each layer follows the roles the firm already uses for its documents.
The fourth is return on investment. Agent usage is an operating expense, and most of it buys output that is consumed once. A memory that learns turns a fraction of that spend into something that persists. Figure 5 is that persistence measured on our open benchmark: the compliance the first corrections bought is still being paid out at the hundredth task. Every correction the practice makes is paid for once and used indefinitely, by future agents, running on future models, and working for future clients. Scene 6 is the moment this becomes visible. The tax practice reaches an acceptable error rate in a week rather than a quarter, and the difference is the six months of corrections the DSCR group had already paid for. Mark's reply puts it best: the onboarding was absorbed into the operating budget because the asset already existed.
Figure 5. Compliance with unwritten policies on our open benchmark: the average over all tasks completed so far, from the first task to the hundredth. Neither arm begins with any knowledge of the policies. Agents with shared memory are ahead within the first few tasks and settle at 64%; agents without memory settle at 20%. The gap between the lines is what the organisation has bought.
Scene 6. A second practice brings in new agents and reaches an acceptable error rate in a week rather than a quarter, because the agents inherit six months of corrections. The accumulated positions are the asset; onboarding cost is where it shows up.
7Our position on memory
Memory will keep meaning three things. What a buyer can do is ask which of the three is being sold. A product that stores is selling an archive. A product that recalls is selling a search. A product that learns is selling a change in what the agents get right next time. Our position is that the third is the one worth building, and worth buying, and that the first two are components of it rather than substitutes for it.
Learning, on our definition, is a measured change in agent behaviour on unseen tasks, caused by the agents' own operation. The signal that drives it already exists in many deployments: reviewers amend drafts, colleagues override decisions, customers push back. Today most of those corrections are used once and discarded. A memory that captures them at the moment they happen learns at close to zero marginal cost, and holds the result outside any model, so the knowledge survives every model swap and vendor change that a procurement cycle brings.
Learning is faster when it is shared, so the memory is shared across the organisation's people and agents. One correction, recorded once, can help what every agent does next, and the more agents there are the more each correction is worth. Sharing is also what makes trust necessary. A memory that many parties write to holds entries that are wrong, entries that were right at the time, and entries that conflict. For us, every position carries a judgement of how likely it is to be right and the evidence behind that judgement, seeded by the contributor's track record and updated by every review.
Trust earns its place twice. It is what makes sharing safe, and it is also the first step from remembering to learning. A memory that revises what it believes as review outcomes arrive is already changing what agents do next, which is the definition of learning this paper works to. Three further operations complete it. The memory abstracts: when scoped lessons from different desks point the same way, it writes the general rule, a rule no individual and no personal memory could write because the instances never land on one desk. The memory reconciles: when two positions disagree, it first looks for the scope that separates them, and where none exists the trust record decides. And the memory forgets: positions that stop earning confirmation weaken and retire, so knowledge that expired in July has stopped being applied by August without anyone needing to delete anything.
What accumulates in the memory is an asset. Agent spend today is an operating expense: it buys output, the output is consumed, and next month buys it again. Learning changes the shape of that ledger. Part of what the organisation already pays for its agents' mistakes comes back as knowledge it keeps, and the value of that knowledge grows with every agent, model and team that draws on it. Most technology depreciates from the day it is bought. A memory that learns is the part of the agent stack that appreciates.
The question we would put to any memory, ours included, is the question behind Nadia's February email: not how much the agents remember, but whether the same mistakes are being made twice. Ask it of your own deployment. The raw material is already there, in the corrections your reviewers make every day. Agents that get better month on month need a memory built to learn from those corrections. That is the platform we are building, and fewer repeated mistakes is the measure to hold it to.
References
- V. Tablan, S. Taylor, K. Bernhem. Learning on the Job: Continual Learning from Deployment Feedback for Frozen-Weights Agents. arXiv:2607.22157, 2026.
- S. Yao, N. Shinn, P. Razavi, K. Narasimhan. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045, 2024.
- The Memory Company. Learning on the Job: companion repository. github.com/memcoai/learning-on-the-job, 2026.
- A. Maharana, D.-H. Lee, S. Tulyakov, M. Bansal, F. Barbieri, Y. Fang. Evaluating Very Long-Term Conversational Memory of LLM Agents. arXiv:2402.17753, 2024.
- M. Tavakoli, A. Salemi, C. Ye, M. Abdalla, H. Zamani, J. R. Mitchell. Beyond a Million Tokens: Benchmarking and Enhancing Long-Term Memory in LLMs. ICLR 2026, arXiv:2510.27246.
- P. Chhikara, D. Khant, S. Aryan, T. Singh, D. Yadav. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv:2504.19413, 2025.
- Letta. Benchmarking AI Agent Memory: Is a Filesystem All You Need? letta.com/blog/benchmarking-ai-agent-memory, August 2025.
- P. Behdin, K. Roice, G. Mesbahi. Position: Deployed Reinforcement Learning should be Continual. ICML 2026, arXiv:2606.04029.
- L. Wang, X. Zhang, H. Su, J. Zhu. A Comprehensive Survey of Continual Learning: Theory, Method and Application. TPAMI 2024, arXiv:2302.00487.
- Letta. Continual Learning in Token Space. letta.com/blog/continual-learning, December 2025.
- F. Shi, X. Chen, K. Misra, N. Scales, D. Dohan, E. Chi, N. Schärli, D. Zhou. Large Language Models Can Be Easily Distracted by Irrelevant Context. ICML 2023, arXiv:2302.00093.
- N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, P. Liang. Lost in the Middle: How Language Models Use Long Contexts. TACL 2024, arXiv:2307.03172.
- V. Tablan, S. Taylor, G. Hurtado, K. Bernhem, A. Uhrenholt, G. Farei, K. Moilanen. Smarter Together: Creating Agentic Communities of Practice through Shared Experiential Learning. arXiv:2511.08301, 2025.