Yesterday your agent pulled four memories into context and acted on one that had been out of date for two sprints. You sent the rating the tool exposes, a negative one, against that memory id. The call came back clean. This morning the same memory is in the same recall, in the same position.
The question is not whether the rating was sent. It is whether anything reads it. One rule runs through this article: is there a documented call that takes the result of a recall that already happened and changes the order of the next recall. The word feedback does not settle it: several vendors use it for several different things.
Disclosure: I work on Mnemoverse, one of the tools in the table below. It is measured by the same rule as the others.
There are no performance numbers here, ours or anyone's. And one correction first. Re-ranking a result set from a reported judgement of it is relevance feedback; the classic algorithm for that was published in 1971, so the technique is 55 years old. Learning a ranking function from clicks was published in 2002, so removing the human is not new either. What is new is how rarely the client your agent is connected through can reach it.
The report that gets counted, and the report someone has to volunteer
Two things get filed under one word. The first says an item came back. The second says it helped, or that it misled. A system generates the first by itself; the second has to be volunteered by whoever used the result, which in an agent stack is the agent, after the answer is already written.
Mem0 has a clean example of the first, and its page is precise about the input (docs.mem0.ai/platform/features/memory-decay, read 25 September 2026):
Records a fire-and-forget reinforcement against each returned memory: its access history grows by one, capped at the most recent 20 touches.
That history becomes "a scaling factor in the range 0.3× to 1.5×" multiplied into the ranking score at search time. Read the input again: "each returned memory", not each memory that helped. The one that came back wrong gets the same increment as the one that saved the session, because nobody has said yet which happened. It is a real loop with a real effect on rank, and it runs on attention rather than outcome. It is also "opt-in per project and off by default".
Three names, and an adjective is not one of them
The rule breaks into three questions, and each answer is a name.
- Where does the verdict land? A field name, not "it is used to improve results".
- What reads that field when ranking happens? A term in the score, or a call parameter. If a vendor documents its ranking layers and your field is in none of them, that is an answer.
- What is the default? A loop shipped switched off is not a running loop.
Four rows, and the third column is the one that decides
Every quotation below is from a page or file the vendor published, read on 21 September 2026 and re-read on 25 September 2026.
| system | where the verdict lands | what reads it when ranking happens | default |
|---|---|---|---|
| Cognee | "specific entries" in a session, 1 to 5 points, via cognee.session.add_feedback
|
"feedback_weight on graph nodes and edges that were used during retrieval", blended by feedback_influence on recall
|
"0.0 (off) by default" |
| Mem0 | a memory identifier, with POSITIVE, NEGATIVE or VERY_NEGATIVE
|
not documented on the surfaces read: the ranking layers are written out, and the report is an input to none of them | |
| Letta | an agent step, not a returned memory: feedback: optional "positive" or "negative"
|
no page on the surfaces read names a consumer | |
| Mnemoverse | the memories a recall returned, by memory_ids, with an outcome from -1.0 to 1.0 |
"Final score after valence modulation: score * (1 + alpha * v)", in the public engine schema |
on: the default relevance order carries the valence term |
An empty cell is no claim rather than a negative: that surface did not answer that column. Every absence is an absence on a named surface on a named date. The full table runs to eight systems: Outcome feedback in agent memory: who reads the rating?
Cognee is the one system there, ours aside, that publishes all three names, and its own example names the value where behaviour changes: "From 0.4 on the up-rated context owns the answer."
Mem0 is the opposite shape, and the more common one. Their guidance names the exact moment this article is about, send it "Immediately after memory retrieval when you can assess relevance". The effect is then stated as a result rather than a mechanism, "This feedback is used to improve the accuracy of the memories and search results". Their own ranking page says "rerank is the only lever here that changes result order". The bound: 47 paths in their machine-readable specification, 1 feedback route, a 3-field response, no route that reads feedback back. So Mem0 accepts the report and does not document a mechanism that reads it when ranking. Not that the report does nothing.
One more input answers another question: Supermemory judges whether a fact its graph derived by itself is true, holding it "down-weighted in search until confirmed". That is a verdict on a guess the engine made, not on how a recall turned out. So when a vendor answers "yes, we have feedback", the follow-up is which of four things they mean: reinforcement for having been returned, a verdict on a guess the engine made, an outcome with no named reader, on a memory or on a step, or an outcome that re-orders the next recall.
From an MCP client, the loop mostly does not close
Your agent is handed a list of tools, and the loop closes only if one of them takes an outcome. An SDK page is not an answer.
On the hosted Mem0 MCP page the tool table carries 11 tools and feedback is not among them. Cognee's default list is 5 tools, three for memory and two for reaching the rest by name, and its own page records improve and save_interaction among the tools removed "in every mode". Graphiti's built-in server carries 13 and none reports an outcome.
The caveat, without which that paragraph is false. Cognee's same page says any registered tool can be invoked by name, and that the default list does not show all of them. So the claim is narrow: no tool in the list moves ranking. Not that an outcome cannot be reported.
One row breaks the pattern. The Mnemoverse tool list carries the rating tool on both MCP paths, the npm package and the hosted connector. For memories in a shared room (Beta), the rating goes through the npm package, which takes the room's address as domain.
Our row, asked the same three questions
Where the verdict lands. The tool is memory_feedback. It takes memory_ids, the identifiers of the memories a memory_read just returned, and an outcome from -1.0 to 1.0. Its description tells the agent when to call it, "right after you act on (or reject) recalled memories", and what the call is for: "positive feedback raises a memory's ranking so it surfaces faster next time (across all of the user's tools), negative feedback lowers it so other memories out-rank it". The rating lands in each memory's valence, which the public engine schema describes as "Outcome polarity [-1, +1]: positive = successful, negative = failed." Nothing is erased. An unhelpful memory is out-ranked.
What reads it. The public engine schema describes the relevance of a returned item as "Final score after valence modulation: score * (1 + alpha * v)". The shape of the term is public and the value of alpha is not, so this article claims no magnitude. The adjustment is applied before the cut, so the rating counts when the engine chooses what comes back, not only in the score printed beside it.
The default. Relevance order, so a rating affects the default read. Valence is one term among several: a recency boost and expansion along learned associations also move the order, and under a recency sort the date sets it.
The loop is explicit. A rating is a call the agent makes after acting on a recall, and nothing runs on a background clock, which is why the call belongs in a standing instruction rather than in the hope that the agent remembers.
One claim this article does not make about anyone, us included: that an outcome loop improves retrieval accuracy. This is about whether a documented mechanism exists and is reachable.
The four steps, and the control on each one
Four steps, each with a control, because a zero without a control proves nothing.
- Ask the server for its tool list and look for one that takes the identifiers of the items just returned plus an outcome. Control: ask for a package version that cannot exist. It must fail to start.
- Find the field name the rating lands in, a name rather than a sentence about improving results. Control: request a page that cannot exist on that host. If it answers 200 with a not-found body, compare bodies, not status codes.
- Find the term in the ranking score that reads that field. Control: search the same corpus for a word that must be found and one that must not.
- Read the default together with the capability, and check the path is reachable from your client. Control: call the tool and read what came back. A silent success that changes nothing is how you find out the call went elsewhere.
Run it against us first. Step 1 finds memory_feedback taking memory_ids and outcome. Step 2 finds the field: valence, "Outcome polarity [-1, +1]" in the public engine schema. Step 3 finds the term in the public engine schema. Step 4: the default order is relevance, and the tool is in the list on both MCP paths.
Then run step 2 on the memory tool you have connected right now and tell me what you got: a field name, or a sentence about improving results.
Disclosure: I work on Mnemoverse, one of the memory layers this question is about. The full review, read on named surfaces on a named date, with every source, is on our library, and the MCP server is open source (MIT): github.com/mnemoverse/mcp-memory-server.
Top comments (0)