Why Your AI Agent Repeats the Same Mistakes (and What Outcome Memory Fixes)
You corrected the agent this morning. It suggested the same deprecated API after lunch. Nothing is broken: the system is working exactly as designed, and that is the problem. Three designs produce this loop, and each has a different fix.
TL;DR
- A correction lives only inside the conversation that contains it. New session, clean slate, same mistake.
- Persistent storage alone does not fix it: similarity search recalls the wrong suggestion as readily as the right one, because nothing records what happened after the recall.
- The missing piece is an outcome attached to the memory: helped or misled. Recall that weighs outcomes stops re-surfacing what failed.
The loop, mechanically
An agent suggests a library you banned in March. You say so. The model apologizes and behaves for the rest of the session. Tomorrow, a fresh session assembles context from the same sources as yesterday: the repository, its instructions file, and whatever retrieval returns. The correction you made exists in none of them. The suggestion returns because, from the model's point of view, it was never corrected.
Teams usually try three fixes in order.
Fix one: put corrections in the instructions file. CLAUDE.md, a Cursor rule, a system prompt. This works and is the right first move, but it scales like a document edited by hand: rules pile up, nobody prunes them, and the file grows until the important rules compete with stale ones for the model's attention. Instructions files hold policy well; they hold a running log of individual corrections poorly.
Fix two: give the agent persistent memory and save corrections. Better: the correction now survives the session. But storage without outcomes has a quiet failure mode. The banned-library suggestion is also in memory, from the day it was made. Retrieval ranks by similarity to the task, and the wrong entry matches the task exactly as well as the correction does. Both come back, the model weighs them in-context, and sometimes the wrong one wins. Storage remembers everything, including the mistakes, with equal confidence.
Fix three: attach outcomes. When a recalled memory leads somewhere (build passed, tests failed, the user pushed back), record that result on the memory itself. Now the two entries are no longer equals: the suggestion carries its failures, the correction carries its confirmations, and recall can weigh them accordingly. This is the piece the first two designs lack: a channel from what happened back to what gets recalled next.
What outcome-weighted recall looks like
The idea is older than agents. Animal-learning theory models it as updating the strength of an association by the gap between expected and actual outcome: surprising failures weaken an association sharply, confirmations strengthen it gently. Applied to agent memory, the loop is:
- Recall returns a set of candidate memories for the task.
- The agent acts; the result becomes observable (a passing build, a failing pipeline, an explicit correction).
- Feedback writes the result back: positive outcome, negative outcome, on the specific memories that shaped the action.
- The next recall for a similar task ranks the survivors higher and the repeat offenders lower.
Two properties matter in practice. The signal must be per-memory, not per-session: it was one suggestion that failed, not the whole conversation. And negative outcomes must suppress without erasing: a suggestion that failed in one context may be right in another, and an erased mistake cannot explain a past decision. Keep the entry; lower its authority.
The honest limits
Outcome memory is not free. Someone or something has to report outcomes, and in practice explicit feedback is rare: agents act, sessions end, nobody files a verdict. Wiring outcome reporting into places where results are already observable (CI status, test runs, an explicit user correction) works better than hoping for manual ratings. And outcome weighting tunes ranking, not truth: it will not turn a wrong fact into a right one, only stop the wrong one from leading the queue.
Where this lives is an architecture choice, not a product requirement. A disciplined team can approximate it with files: a "failed approaches" section the agent is instructed to check and append to. A self-hosted memory store can carry an outcome field with a re-ranking hook. A managed memory service can do the bookkeeping automatically across every tool the agent works in. The mechanism is what matters: no path from outcomes back to recall, no learning from mistakes, whatever the storage.
Related: The Feedback Dilemma measures how rarely explicit feedback actually occurs in production. Stale Memory Is Worse Than No Memory covers the other half: what to do with entries that are not wrong, only retired. Agent Memory: Evidence versus Policy covers why corrections should close facts rather than overwrite them.