An agent with a memory layer will remember every correction it has ever been given. It will still repeat the mistakes those corrections were meant to prevent.
The pattern is easy to reproduce. A support agent quotes a customer a delivery date. The customer corrects it: never quote a date without checking stock first. The correction is stored, and the next week that customer returns to a perfect answer.
That same week, a different customer asks the same question — and gets the same wrong answer.
Nothing malfunctioned. The memory system did exactly what memory systems do.
Two systems in the same slot
Teams install a memory layer expecting that gap to close. It doesn't, and the reason is architectural — obscured by the fact that the system which would close it looks almost identical from outside.
Both sit between the application and the model, reading before it answers and writing after. Both persist text across sessions. Both use a model in the write path to decide what is worth keeping. Both are sold against the same failure: the agent that starts every conversation from zero.
Same slot, same substrate, same pitch. The difference is one question: what has to happen before the system writes anything down?
What memory architectures optimize for
Give a memory system a transcript and it extracts the facts worth keeping, compares each against what it already holds, and picks an operation — add, update, or retire a fact that was just contradicted.
Better designs keep the superseded fact retrievable as memory rather than only in a change log, and record when it stopped being true. Move cities, and last year's address is marked valid until a Tuesday in March — and the store can still answer questions about last March.
That is hard engineering and it works. But note what all of it is for: deduplication, contradiction resolution, retiring stale facts, deciding which of two conflicting statements is current. Every mechanism serves one job — maintaining a clean, current picture of the person being served.
What is true about this user right now? Memory systems answer that well. It is not the only question a production agent needs answered.
The write trigger
Memory systems write on observation. Learning systems write on judgment.
A memory system commits a fact because it was stated. A learning system commits a rule because an outcome was evaluated.
Same trigger point, same destination — but the write conditions, the scope, and the failure modes all differ.
| Memory | Learning | |
|---|---|---|
| Writes when | Something is said | Something is judged |
| Unit | A proposition | A behavioral rule |
| Answers | What is true about this user? | What should the agent do differently? |
| Verified by | Checking it | Testing it |
| Fails by | Going stale, self-contradicting | Overfitting, eroding under rewrite |
| Ships only after | Nothing that tests the outcome | Approval, held-out evaluation, rollback |
Adding or retiring an entry resolves a bookkeeping question: does this fact contradict one already held? Memory systems are very good at that, and they have no opinion about whether the agent's answer was any good.
Some platforms accept feedback on a stored memory — useful, not useful. That grades the note, not the answer. Nothing in the loop connects a bad outcome to the behavior that produced it.
Making that connection is the hard part. A learning system needs a signal that something went wrong — a correction, a retry, an escalation — and must then determine which of the agent's behaviors caused it. That is credit assignment, and in the general case it remains unsolved.
The consequence is concrete: an agent can retrieve "this user prefers short answers" and still produce six paragraphs. Retrieval does not oblige a model to act.
Facts, rules, and the evidence each needs
Return to the support desk. The two things that agent needed are different kinds of object.
This customer's orders ship from the Rotterdam warehouse is either true or false. You check it.
Check stock before quoting a delivery date is neither. It is effective or it is not, and the only way to find out is to deploy it and measure. Most teams have tooling for the first case and nothing for the second.
The second difference usually gets stated backwards. Memory is described as per-user and learning as cross-user, but memory stores cross user boundaries routinely — shared stores are an ordinary feature. What differs is what crosses, and on what evidence.
A fact propagates because someone asserted it. A rule should propagate only once it has been shown to work, and a bookkeeping loop has no outcome evidence to gate on because it never collected any.
That asymmetry cuts both ways: one customer's bad correction becomes every customer's bug. So a rule needs approval before it goes live, validation against cases it has not seen, and a way to roll back — not conveniences, but requirements for something that applies to people who never generated it.
Rules also decay in a way facts do not. Rewrite a rule set wholesale and it erodes: the specifics that made it useful get summarized away, leaving something shorter, tidier, and worse. Extending a playbook beats regenerating one.
What the benchmarks measure
Each field reveals its priorities in how it scores itself.
Memory is evaluated on recall: information appeared earlier, and the system is asked to produce it later. The benchmarks have grown more demanding — current ones test temporal reasoning, whether a system registers that a fact has been updated, and whether it knows to abstain. The question underneath is still did you produce the right answer?
Self-improvement is evaluated on task completion. Did the agent finish the job?
A system can score near-perfectly on recall while the agent it serves repeats the same mistake for the thousandth time. Remembering a mistake and not repeating it are different capabilities, measured on different axes.
Learning in text, not in weights
"Self-improving agent" suggests an expensive retraining loop. It does not require one.
One of the strongest recent results improves an agent by rewriting its instructions in natural language — reflecting on failures and editing the guidance. No weight updates, no training run. It outperformed a standard reinforcement-learning method while using up to 35× fewer runs at the task.
A scalar reward tells a system that it lost. A sentence tells it what to do differently. Language carries the reason; a number cannot.
The blurry edge
One class of system complicates this line.
Background processes now review an agent's recent conversations and fold what they find back into its memory, without a per-write prompt. Consolidating lessons from experience is not clearly bookkeeping, and not clearly learning. Whether the write is triggered by observation or by judgment depends on implementation details vendors do not consistently document.
The adjacent case is a grader that scores an agent's output against a rubric and sends it back for another pass. That is a system with an opinion about whether the answer was good — but it is an evaluation loop sitting beside the agent, not a memory system changing what the agent does next. The line holds there. It is less clear in the first case.
That case is genuinely unsettled, and the distinction drawn here may prove to be a gradient rather than a line.
A diagnostic
None of this argues against memory. It argues against expecting one thing from a system built for another. Both questions need answering — who is this person and what is true about them, and what should this agent do differently tomorrow — and at runtime, retrieval should pull from both.
One question is worth taking to your team:
Does your agent's error rate on repeated mistake classes decline over time?
Not whether it recalls the correction. Whether the same class of failure becomes rarer across customers, without anyone editing a prompt by hand. Whether the second customer stops receiving the answer the first one already corrected.
If that question has no answer, what is in place is not a learning system. It is an excellent record of every time the agent got it wrong.
For most teams the answer is not yet. The obstacle is usually attribution — determining which behavior to blame — with evaluation cost and rule-approval workflow close behind. If any of the three is behind you, that is worth writing up.
What answering it takes
Nothing above needs a bigger model. It needs a second loop — one that writes on outcomes rather than utterances, and produces rules a person can read rather than weights they can't.
That is the layer we work on at Reflexio. Not a memory store, and not a claim to have solved attribution — that problem is exactly as open as this post says it is. What's buildable today is narrower: corrections held as rules, scoped to where they earned their evidence, tested before they ship, and reversible when they stop paying. We've written up the shape of that loop as LGRO; closing it cut agent planning iterations by more than 80% in our own evaluations.
Reflexio is on GitHub, along with our open-source coding-agent plugin claude-smart. If you're running a memory layer and wondering why the error rate is flat, we'd love to compare notes.