Why AI coding assistants repeat fixed mistakes: who takes an outcome?

A fixed mistake comes back because the memory that carried it is still being retrieved. Writing the correction down does not stop that by itself: the old item stays in the store, it stays eligible, and at the start of the next session it arrives in front of the model again, next to your correction, with nothing separating them. Storing a mistake and learning from it are two different things. Storage means the mistake can be read again. Learning means that something about what the system does next is different because that outcome was bad. Underneath the complaint there is one mechanical question, and it can be put to every product in this category including ours: does anything change when the outcome was bad? Not when you write something new. When something failed.

Disclosure, and on this page it belongs above the argument rather than under it. We build Mnemoverse, a memory layer for AI agents, so this is a vendor comparing itself with five competitors, and on this particular question we come out ahead, which is exactly why you should be told now rather than in a footer. We publish an input for an outcome, documented, taking a float from minus one to plus one. Our own published article about that input reports that it is almost never called in the traffic we measured, and that is where this page ends. Every quotation below is a contiguous substring of a page you can open, every query is printed so you can run it, and the section where we come off worst is the last one.

This is the written half of a video asking the same question, and the sections below follow its chapters in order, so anyone arriving from the end card can pick up where they stopped. It also goes deeper than the video in two places and further than it in one, all three marked where they land. The sweep behind the video looked for vendor changelogs on each marketing host and read a single page of each documentation tree, and both of those turned out to be too narrow.

There are no performance numbers on this page, ours or anyone's. A number is the output of a recipe, this page is not showing a recipe, and a number without a recipe is not something you can check.

TL;DR

• Storing a mistake and learning from it are different things. Almost everything sold as agent memory does the first one well. The second one needs a report, after the fact, that the thing which came back was wrong.
• Four of the five other systems publish an input that takes an explicitly negative verdict. Cognee, Mem0, Letta and Supermemory, each read on its own documentation host on 10 September 2026. On the surfaces read, only Zep publishes none.
• What they attach it to is where they separate. An answer to a recall, a memory result, an execution step, or a guess the engine made about a fact. Those are four different objects and only two of them are the thing this question is about.
• Fewer publish what the input moves. Cognee says feedback influences future retrieval and names the call that applies it. Supermemory says an unreviewed guess is down-weighted in search. Mem0's page says what its endpoint accepts, not what changes in ranking. Letta's says nothing about retrieval order.
• The solid spelling of the word for the negative direction returns zero files in all five vendor organisations, re-run on 10 September 2026 with a control that returns files in every one of them, and the queries are printed below.
• The hyphenated spelling is not zero, and this page says so before you find it. Supermemory publishes down-weight in its review documentation, Cognee publishes it in a guide, and the second one is a sentence about what their search does not do.
• Our row: the input is documented, the engine is closed, and the signal is voluntary by design. You can read the endpoint, the range and the description. You cannot watch it work.
• Where this page and the video differ is marked in the text. Two of the video's bounded statements are true of the surfaces it read and not of the pages below them, and one sentence in it goes past its own evidence. All three are named where they land.

Disclosure, and it goes above the argument

We build one of the six systems on this page. Mnemoverse is a hosted memory layer for agents, and on the question this article asks we hold a strong row, which is a worse reason to be trusted than a weak one.

So here is our row with its limits attached. Our API reference documents the field this whole article is about, in a table of parameters, and the range is the point: "Outcome signal: -1.0 (failure) to +1.0 (success)". The same page says what the call is for: "Report outcome (success/failure) for memories." Our machine-readable index says the same thing to an agent reading it, and adds what it moves: report outcomes "when a recalled memory was useful (+1) or wrong (-1)", and then, in three words, "This tunes future recall."

And here is where we lose. Our engine is closed. mnemoverse-core is not one of our public repositories, so the endpoint, the range and the description are readable and the thing that would settle whether any of it works is not. The endpoint needs an account and a key, so public here means publicly documented rather than open to anyone. And the ending of this page is a measurement we published against ourselves: the signal exists and is almost never sent.

One more, because you will meet it before you meet anything else on our side. The description on the front page of our public memory-server repository still advertises two behaviours our own changelog withdrew. We named that on this site two days ago, in Cursor Memory Bank: what actually loads, and it is still there while you read this.

Every query in this article works against us as well as against everybody else. Run them on us first.

Storing the mistake is not learning from it

You fixed it once. You explained why. The next session it came back.

Two different things get called memory in that sentence, and separating them is most of the work. One is storage: the mistake, or the correction, is written down somewhere and can be read again. The other is learning: something about what the system does next is different because the last outcome was bad.

Almost everything sold as agent memory does the first one, and does it well. A note, a file, a graph, a vector index, a hosted store. All of that is storage, and storage is genuinely useful. It is also symmetric: it remembers the wrong suggestion exactly as faithfully as the correction, and hands both back with the same confidence.

Three checks separate the two, and you can run all three yourself.

1. Is there an input for an outcome at all? Not a place to write a new note. A report that says the thing you gave me was wrong.
2. If there is, what does it move? The text of the memory, its weight, or the order in which things come back.
3. Does that survive a restart, and can you see it?

The rest of this page is those three checks applied to six systems: Cognee, Letta, Mem0, Supermemory, Zep and Mnemoverse.

What has to change for a mistake not to come back

Before any product, the mechanics, because they decide what to look for.

A coding assistant does not consult a memory the way you consult a note. Something retrieves a handful of items, puts them in front of the model, and the model writes what it writes. If a wrong item keeps arriving in that handful, the model keeps having the same bad idea, and it is not being stubborn. It is being fed.

Which tells you where the lever has to be. Deleting the wrong memory is one answer, and a blunt one. You have to know which of the retrieved items was the bad one, which means reading them, which is the work you were trying to avoid. And a memory that was wrong once is often right in another context: the note about the deployment path is correct for one service and misleading for the next. Delete it and you lose both.

Ranking has neither problem. Nothing is destroyed, and the same item can be down for one kind of question and up for another. But it needs something the writing path cannot supply. It needs a report, after the fact, that the thing which came back was wrong. An outcome.

That is why this article is about inputs rather than about storage formats. Every system here can store a correction. The question is whether anything downstream of a bad result reaches the thing that decides what comes back next.

Keeping what worked and correcting what did not are different jobs

Search for how to make an agent learn from its errors and a lot of what comes back is about the other half of the problem: how to keep a workflow that worked and replay it. That is a real product idea, it is well explained in plenty of places, and it is not this question. The two jobs look similar and behave nothing alike, because a success can be captured at the moment it happens and a failure usually cannot.

The vendor pages show the same split. Letta's quickstart tells you what to do when the agent gets something wrong, and what it describes is a durable write: "When it makes a mistake it should never repeat", use the /remember command to make the correction stick. That is storage, done deliberately and done well, and it is the first category from the section above rather than the second.

Supermemory's review endpoints look like the second category and turn out to be a third thing again. They let you approve, decline or undo a decision on a memory the engine inferred rather than one you stated, and the vendor's own page is precise about the effect: while a memory is unreviewed and inferred it "is down-weighted in search", an approved one ranks like a stated fact, and a declined one is "Removed from search entirely". That is a verdict on whether a derived fact is true. It is not a report on how a recall turned out. Both are useful. They are not interchangeable, and a feature table that files both under feedback is comparing two different mechanisms.

Does anything here take an outcome at all?

This is the section where this page goes further than the video it accompanies, so it starts with the difference. The sweep behind that video, run on 8 September 2026, covered six surfaces per vendor: the documentation tree, the changelog, the release notes, the GitHub organisation with a term search, the machine-readable index, and the forum. A changelog answered for Cognee, Supermemory and Mnemoverse, and for us it was found in the repositories rather than at an address of its own; for Letta, Mem0 and Zep the sweep found no changelog at all. The video's sentence about that sweep is careful and it is worth repeating exactly, because it is what makes the difference below a widening rather than a correction: on the surfaces the receipts cover, three of the six describe no input that changes retrieval because an outcome was bad, and it names Mem0, Cognee and Zep. That statement is true of those surfaces. It is not true of the pages that sit below them, and the documentation surface in those receipts is a single fetch of one page of each tree, while the pages describing these feedback inputs sit several clicks down. Re-read on the documentation hosts on 10 September 2026, two of the three publish an input.

Here is what the five publish, each line taken from the page named beside it and read again on 10 September 2026.

system	published input that takes a negative verdict	what it is attached to	what the vendor publishes about the effect
Cognee	cognee.session.add_feedback, with optional feedback text and a score from one to five	the answer to a recall, by its identifier inside a session	"To make feedback influence future retrieval, run improve() with the relevant session_ids."
Mem0	POST /v1/feedback/, values POSITIVE, NEGATIVE and VERY_NEGATIVE	a memory result, by memory_id	the page says the endpoint is there to "Submit positive or negative feedback on memory results", and says nothing about what changes in ranking
Letta	PATCH /v1/steps/{step_id}/feedback, "Whether this feedback is positive or negative"	an execution step	the page describes the operation, "Modify feedback for a given step.", and connects it to no retrieval order
Supermemory	the review endpoints, approve, decline and undo	a memory the engine inferred, not one you stated	an unreviewed inferred memory "is down-weighted in search", a declined one is "Removed from search entirely"
Zep	none found on the surfaces read
Mnemoverse	memory_feedback(atom_ids, outcome), "Outcome signal: -1.0 (failure) to +1.0 (success)"	the memories a recall returned	"This tunes future recall", and on the same index, "unhelpful memories are out-ranked rather than erased"

Cognee is the clearest case and it deserves to be stated plainly. Its feedback guide says "Feedback on recall answers is handled via Sessions", then walks through recording the interaction, finding the identifier of the answer you want to rate, calling add_feedback on it, and finally the sentence that matters here: "To make feedback influence future retrieval, run improve() with the relevant session_ids." That is an input on the answer to a retrieval, with a published path from it back to what retrieval does next. It is the mechanism the sweep did not reach.

Mem0 publishes an input too. The endpoint is documented at docs.mem0.ai/api-reference/memory/feedback, it takes a memory identifier and one of three values, and the honest boundary is what the page does not say: it states what the endpoint accepts, not what happens to ranking afterwards. Mem0 separately publishes a search-time ranking bias in its changelog, and it is worth reading precisely because it moves the order of results while taking no verdict at all. The entry describes a per-project bias that boosts recently-touched memories, notes that "Every memory returned in a search has its access history updated", says "Decay can reorder candidates but never removes them", and gives its default in the vendor's own words: "Off by default; opt in per project via the decay field on the project endpoint". Frequency and recency move that ranking. Whether the answer was right does not.

Letta's input exists and is attached to something else. A step is an execution object, and marking one positive or negative is a useful thing for observability and for evaluation. It is not a report that a retrieved memory was wrong, and nothing on that page or in the quickstart says either one reorders a later read.

Zep is the one absence claim on this page, and its bounds go in the same paragraph. On the surfaces read, nothing Zep publishes describes an input that takes a verdict on a recall: its machine-readable index at getzep.com/llms.txt, 3,963 bytes on 10 September 2026, contains zero occurrences of feedback, outcome, valence, rerank, reinforce and downweight, while the file is plainly not empty; the 324 pages listed in help.getzep.com/sitemap.xml were walked the same day and every occurrence of the word feedback in them was example content rather than an input; and a term search of the getzep organisation returns files for the control term and none for the term this article is about. What is not covered: the changelog at help.getzep.com/changelog paginates, a plain fetch of it renders only the top of the page, and nothing here rests on it; and the closed part of the product cannot be read from outside at all.

One bound applies to the whole page. Four of these six do not publish an engine you can read, ours among them. A sweep of what is published is not a sweep of what runs. Where this page says something is absent, it is naming the pages and repositories listed here on the day they were read, not the behaviour of a product. Two of these vendors also run chat communities that cannot be read from outside; the sweep does not cover them, and if an answer is in there, this page does not have it.

The changelogs the sweep did not find, and why it did not find them. The video says the changelogs of Mem0, Letta and Zep were not found, and that is a true statement about the sweep rather than about the vendors: it says the surface was missing rather than that the vendor is silent. All three do exist, and all three are on the documentation host rather than the marketing host, which is where the sweep looked. On 10 September 2026, docs.letta.com/reference/changelog answers 200 with 412,108 bytes, holding about eighty four thousand characters of text, against a made-up path on the same host that answers 404 with about a twentieth of that text; docs.mem0.ai/changelog answers 200 and resolves to /changelog/highlights; help.getzep.com/changelog answers 200 and resolves to /v3/changelog. Guessing was never going to find the first one, because docs.letta.com/changelog resolves to a client SDK page instead. A sweep is only as wide as its narrowest surface, and both of the places this page goes deeper than the video come from the same shape of mistake.

Learning from context is not learning from outcome

Two of the five publish a stated position on how learning should work, and both deserve quoting rather than summarising. Both put the learning in context.

Supermemory, on its own machine-readable index. The subject of the sentence is their model rather than the product in general: "Our model, learner-1, extracts and dreams on the context of every user, task, and tenant". A section heading in the same file reads "Memory that keeps learning". That is learning, and it is learning from context: more of what happened goes in, and the model gets a better briefing. Nothing in that sentence takes a verdict on whether the last answer was any good, and the review endpoints covered above take a verdict on a guess rather than on an outcome.

Letta, in its published research on continual learning. The argument is that learning belongs in token space, and the sentence carries a should rather than a does: "updates to learned context, not weights", named as the primary mechanism agents ought to use to learn from experience. The framing underneath it is that a deployed model cannot learn the way people assume, because "their weights are frozen at deployment".

The human sentence on that page is about humans, and it is the easiest line here to misquote. Letta draws a comparison with people: "Humans continually learn and improve over time", acquire new skills, update their beliefs, and "modify their behavior to correct for past mistakes". That is a description of the thing to copy, not a claim about what a Letta agent does. Quoting it without its subject would put words in their mouth.

And the same page names an exception, so this page names it too. Directly after the sentence about frozen weights, Letta writes: "The one notable exception is Cursor's tab-completion model which uses online RL to continuously improve based on user feedback, but this form of continual learning operates at the population level, improving the model for everyone rather than enabling individual agents to learn from their own experience." They add that "it is scoped to a narrow domain: short code completions, not general reasoning and actions". So there is a shipped, widely used mechanism that learns from user feedback, inside a coding tool, and both limiters on it are the vendor's own: it improves the model for everybody rather than fixing the mistake in your project, and it covers completions rather than reasoning and actions. If you have read anywhere, including in our own video, that nobody in this field learns from outcomes, that sentence is the counter-example, and it sits on a page this article cites for something else.

The word for it, and the two places it appears

The mechanism has a vocabulary, so the sweep searched for the vocabulary in each vendor's own organisation. Feedback. Outcome. Valence. Rerank. Reinforce. And one more: downweight, the word for what has to happen to an item that was retrieved and turned out to be wrong.

The query is not complicated and nothing about it is ours. It is the word in quotes, then the organisation.

"downweight" org:topoteretes
"downweight" org:letta-ai
"downweight" org:mem0ai
"downweight" org:supermemoryai
"downweight" org:getzep

Those are GitHub code search queries; the command form is gh api -X GET search/code -f q='"downweight" org:topoteretes' --jq .total_count. Re-run on 10 September 2026, all five return zero.

Three things bound that zero, and each is a reason not to lean on it too hard.

The first is the unit. GitHub code search counts files, not occurrences, and a zero there is a zero in an index rather than a zero in the world. The web interface at github.com runs on a different index and can return a different number for the same query.

The second is the control, without which a negative result proves nothing. The same instrument, on the same day, for the same five organisations, returns files for "rerank": thirteen, three, one hundred and forty four, twenty eight, and one hundred and sixty three. The index is answering for every one of them. A second instrument was run beside it: the default branches of the vendors' flagship repositories were downloaded and searched directly on 10 September 2026, and the solid spelling appears in none of them. That second instrument has a hole worth naming, because it is the kind that returns a quiet zero. The default branch of letta-ai/letta now carries sixteen files, a README and a set of policies, with the code no longer on it, so searching it proves almost nothing; letta-ai/letta-code, two thousand one hundred and ninety two files, was searched in its place and returns zero for the word as well.

The third is the spelling, and this is the one place where a sentence in the video goes past its own evidence. The video says the negative direction is the one nobody writes down. It is written down, by two of the five, with a hyphen. Supermemory writes it in the review documentation quoted earlier, and the same query with a hyphen returns one file in their organisation. Cognee writes it in a guide on fact validity, in a sentence about what their retrieval does not do: "Search and graph completion neither filter nor down-weight closed nodes, so a superseded fact can still surface in results." That page lives outside their GitHub organisation, so the code search returns zero for it while the page says it anyway, which is the clearest demonstration here that one instrument is not enough to claim an absence.

So what does the zero actually show? Not that nothing happens inside these products. Plenty of code does a thing without ever naming it, and two vendors name it in a spelling the plain query misses. What it shows is a lopsided vocabulary. Rerank is everywhere. The direction that means down, on the strength of a bad result, is written down twice across five organisations, and one of those two times is a sentence explaining that it does not happen.

For completeness, all fifteen of our own public repositories were downloaded and searched the same way on the same day, and all four spellings of the word return zero across them. We do not publish it either.

Our own row, and the channel we built

Our turn, and on this question we come out ahead, which is why this section is longer rather than shorter and why the disclosure is at the top rather than here.

We publish an input for an outcome, in the API reference and in the machine-readable index, and it takes a negative value. The reference states the range in a parameter table: "Outcome signal: -1.0 (failure) to +1.0 (success)". Minus one is the case this whole article is about: the thing that came back was wrong, and the report says so.

What it is attached to is what separates it from three of the four inputs above. The call takes atom identifiers, which are the memories a recall returned, so the verdict lands on the items that were actually put in front of the model. Not on an execution step, not on a chat reply, and not on a guess the engine made about a fact. Our published definition of the signal says what it reports: "whether a recalled memory helped, misled, or should be ignored after use".

And what it moves is the order of the next read, not the text of the memory. The memory stays where it is. Our index says the effect in its own words, "This tunes future recall", and elsewhere in the same file, "unhelpful memories are out-ranked rather than erased" and "outcome feedback re-ranks what comes back next".

The bounds on all of that are ours to state, so here they are. The engine that would prove it is closed, the same as for three of the other five. The endpoint needs an account and a key. You can read the range and the description, and you cannot watch the ranking move. On the axis of what a reader is able to verify, we are in no better a position than anyone here, and our own article on this signal says as much about our own measurements in one line: "that is our practice, not independent evidence".

Nothing makes the agent say it was wrong

There is one more thing to say, and it is the reason this page exists rather than a page about our own feature.

We built the input. We wrote it down. And our own published article about it, The Feedback Dilemma, says that explicit outcome feedback "is almost entirely absent from production traffic, at least the traffic we measured". The second half of that sentence is our own limit on our own finding, which is why it is quoted whole: it is a statement about the traffic we could see, not about production traffic everywhere.

The reason is in the same article, and it is not a defect in the endpoint. Reporting an outcome is something the agent has to choose to do after the answer is already written, when nothing is watching. Our guidance is one feedback call per acted-on recall, and the article says what that buys and what it costs: "This keeps the signal voluntary at the account level." It makes behaviour auditable and, in the same article's words, "It avoids forcing fake labels". Voluntary is the honest word for it, and it is also the limit. Having the input does not mean the mistake will not come back. A channel nobody calls and a channel that does not exist produce the same repeated mistake, and that is the fairest summary of where this category stands today, ours included.

It is the mirror image of a finding this site published about rule files. If you have written a rule down, watched your agent read it back to you, and then watched it do the thing anyway, nothing was ever stopping it. Here the mechanism that would keep a fixed mistake from coming back needs the agent to volunteer that it was wrong, and nothing makes it.

The one-minute test, on whatever you already use

Do this before believing any comparison, including this one. It needs no installation and it works on any tool in this article.

Find a memory your tool holds that you know is wrong. Ask it a question that memory would answer, and watch the wrong item come back. Now tell the tool it was wrong, in whatever way the tool allows: the endpoint, the review action, the slash command, a message in the chat. Then ask the same question again in a fresh session, so nothing is left in the context window doing the work. If the same item comes back first, the report went nowhere, and writing more notes will not change that. If the order moved, you have found the mechanism this article is looking for, and you can go and read what the vendor says it does.

What to ask a vendor

Four questions, in this order, and they work on a sales call as well as on a documentation site.

1. Is there an input that takes an outcome? Not a place to write a note. A report that the thing you returned was wrong.
2. What is it attached to? An answer, a memory, a step, or a stored guess. Only the first two are about a recall.
3. What does it move, and where is that written down? The text, the weight, or the order of the next read.
4. Who has to remember to send it? If the answer is the agent, after the work is done, when nothing is watching, then read everything else with that in mind. That is our answer too.

Related

• Why your AI agent repeats the same mistakes: the same question from first principles, with the three fixes teams try in order
• The feedback dilemma: the measurement this page ends on, in full, including how rarely the signal actually arrives
• Rescorla-Wagner for agent memory: what outcome weighting looks like written as an update rule rather than as a feature
• Agent memory knowledge graphs compared: the same six systems, a different mechanical question, and the row where we come off worst
• CLAUDE.md, AGENTS.md and Cursor rules do not enforce: the other half of the same finding, on the writing side
• Cursor Memory Bank: what actually loads: what a folder of files in your repository does and does not do about this
• Stale memory is worse than no memory: the neighbouring problem, entries that are not wrong, only retired

---

Live probes for this article were run on 2026-09-10 with full browser headers, in both the trailing-slash and no-slash forms, with negative results controlled in both directions, and every quotation checked as a contiguous substring of the extracted text of the page named beside it rather than of its raw markup, because markup breaks a sentence across tags. Vendor punctuation and capitalisation inside quotation marks are the vendor's own. Pages read that day: supermemory.ai/llms.txt, supermemory.ai/docs/recall/memory-review, www.letta.com/blog/continual-learning/, docs.letta.com/quickstart.md, docs.letta.com/api/resources/steps/subresources/feedback/methods/create/, docs.letta.com/reference/changelog, docs.cognee.ai/guides/feedback-system, docs.cognee.ai/guides/fact-validity, docs.mem0.ai/api-reference/memory/feedback, docs.mem0.ai/changelog, getzep.com/llms.txt, help.getzep.com/changelog and the 324 pages listed in help.getzep.com/sitemap.xml, together with our own mnemoverse.com/docs/llms.txt, mnemoverse.com/docs/api/reference and mnemoverse.com/docs/library/agent-memory-feedback-dilemma. The term searches were re-run against all five vendor organisations the same day with a positive control, and counts from GitHub code search are counts of files in an index that does not cover every public repository, which is stated wherever they are used. Where this article states an absence it names the surfaces it covered in the same paragraph, and the surfaces it could not cover, the paginated Zep changelog and the two vendor chat communities that cannot be read from outside, are named rather than left out. The receipts from the 8 September sweep record which surfaces answered for each vendor; they do not record quotation text, so every quotation here was verified against the live page rather than against a receipt. Disclosure: this site publishes one of the six systems compared, the disclosure is the second section rather than the footer, our own limits are named before anybody else's, and the closing section is the one where we come off worst. There are no performance, latency or benchmark numbers in this article, for any system, ours included.

Edward Izgorodin · Mnemoverse · 2026-09-10

Mnemoverse is a persistent-memory API for AI agents. Free key: console.mnemoverse.com · Plans and limits · Docs: Getting Started