Your agent can rate a memory. Almost nothing reads the rating.

An agent asks its memory for the last three facts about a customer. The memory returns three items. The agent writes an answer that is partly wrong because the second item was outdated. Nobody told the memory that the second item caused the mistake. The memory counted that the second item was retrieved, but it did not learn that the retrieval failed. Two different reports get filed under one word, and telling them apart is most of the work on this page.

Retrieval reinforcement is a count of the fact that an item was returned, with no verdict attached to it. Outcome feedback is a report, made after the fact, that says whether what came back helped or misled. The first is generated by the system itself. The second has to be volunteered by whoever used the result, and in an agent stack that is the agent, after the answer is already written.

Disclosure: I work on Mnemoverse, one of the tools in the table below. It is measured by the same rule as the others, and the section about it says what we have not shown.

One rule runs through this page, and it is worth carrying even if you read nothing else: 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, because several vendors use that word for several different things. The technique itself is old: re-ranking a result set from a reported judgement is relevance feedback, and the classic algorithm for it was published in 1971.

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

• Being retrieved and being useful are two different reports. Mem0's Memory Decay counts retrievals. A rating is a different signal about the same event, and it goes somewhere else or nowhere.
• The rule here has three names in it: where the verdict lands, what reads it when ranking happens, and what the default of that reading is. An adjective answers none of the three.
• Cognee is the one system here that documents the whole chain, from a rating on a session entry to a blend parameter in the recall call, with the blending line published in their repository, and it ships switched off, at 0.0. Mem0 publishes the route and not the reader. Supermemory, Zep and Letta each take an outcome and answer a different question with it.
• From an MCP client the loop mostly does not close. On the tool lists read on 21 September 2026, a rating is absent from most of them, and where it exists it can sit behind conditions.
• The idea is old and the access is new. Rocchio 1971, clicks in 2002, ExpeL in 2023, EARM on 24 August 2026. Our own row is a row, not a verdict: the shape of our ranking formula is published and the coefficient's value is not, our engine is closed, and over MCP a rating on a memory in a shared room (Beta) currently works only on the npm package, with the room's address.

Memory Decay counts retrievals, and that is a different input

The clearest way to see the distinction is a mechanism that is good at what it does and is not the thing this page is about.

Mem0 documents a feature called Memory Decay, and its own description is precise about the input. "Every memory carries a small piece of bookkeeping: when was it last retrieved, and how often. Memory Decay turns that history into a scaling factor in the range 0.3x to 1.5x and multiplies it into the ranking score at search time" (docs.mem0.ai/platform/features/memory-decay, read 21 September 2026). The step that grows the history is written down too: "Records a fire-and-forget reinforcement against each returned memory: its access history grows by one, capped at the most recent 20 touches."

Read the input again. It is "each returned memory". Not each memory that helped. A memory that came back and was wrong gets the same increment as one that came back and saved the session, because at the moment the increment is written nobody has said which happened. That is a real closed loop with a real effect on rank, and it is a loop over attention rather than over outcome.

It is also not on unless you turn it on. The same page states: "Memory Decay is opt-in per project and off by default." On the surfaces read, it applies in search v3.

So the first thing to check in any product that advertises improvement from use is which of the two reports it describes. Both are worth having. Only one can tell a store that the item it ranked first was the item that caused the mistake.

The rule, and the three names it asks for

The rule is one sentence: is there a documented call that takes the result of a recall that already happened and changes the order of the next recall.

It breaks into three questions, and each one has an answer that is a name rather than an adjective.

1. Where does the verdict land? A field name. Not "it is used to improve results".
2. What reads that field when ranking happens? The name of a term in the score, or the name of a call parameter. If the vendor documents its ranking layers in detail and your field appears in none of them, that is an answer.
3. What is the default? A published loop shipped switched off is not the same as a running loop, and the default belongs in the same sentence as the capability.

A fourth question sits outside the rule and decides whether any of it reaches you: is the call available from the client the agent is connected through. Everything that follows is those questions asked of eight systems, with the vendor's own words in quotation marks and the date of reading beside them.

Our own library pages are not evidence about a competitor, so every vendor statement below was taken from that vendor's own source again on 21 September 2026. The neighbouring page on this site, Agent memory feedback: the missing signal, covers what happens once the input exists, and this page relies on it rather than repeating it.

Eight systems, one rule

Every statement in this table is quoted from a page or a file that vendor published, read on 21 September 2026. Each row links the surface it was read from. An empty cell means no claim, not a negative.

system	documented input that takes the outcome of a recall	what the input is attached to	what reads it when ranking happens	default	in the MCP tool list
Cognee	yes: "attach feedback to specific entries using cognee.session.add_feedback", rated from 1 to 5 points	a recorded question-and-answer entry in a session	"Session feedback updates feedback_weight on graph nodes and edges that were used during retrieval", blended into the triplet score by feedback_influence on recall	DEFAULT_FEEDBACK_INFLUENCE is "0.0 (off) by default"	no: 5 tools in the default list, and improve and save_interaction "have been removed in every mode"
Mem0	yes: POST /v1/feedback/ taking POSITIVE, NEGATIVE or VERY_NEGATIVE plus a free-text reason	a memory identifier	not documented on the surfaces read: three ranking layers are written out and the report is an input to none of them		no: 11 tools in the hosted server table, feedback not among them; 9 registered in the archived open server, not there either
Zep, Agent Skills	yes: success or failure plus a confirmation class of 5 values, sent with a signed search_id	a Skill use, resolved back to "the Skill version and rank from the signed search result", which "expires after one hour"	admission rather than order: outcomes feed candidate compilation and an approval policy	"The default memory_settings.approval value is manual"	a tool exists, and it appears in the list only when 5 conditions hold at once
Zep, Context Graph	not documented on the surfaces named below
Supermemory	yes, for a different object: "approve, decline, or undo a decision" on an inferred memory	a fact the graph derived by itself, flagged "isInference: true"	approval makes it rank "like a stated fact"; unreviewed inferences are "down-weighted in search"; a decline removes it from search	inferred facts start down-weighted and wait in a review queue a person builds
Graphiti	not documented on the instruments named below		closed reranker enumerations, 5 values in the edge enumeration; episode_mentions counts episode mentions at ingest, not reads of a record		no: 13 tools in the built-in server
Basic Memory	not documented on the instruments named below		"max+0.3*min/v1", the fusion formula version written into the search trace; an optional cross-encoder from version 0.23 over a window of 20 candidates	"reranker_enabled", "false"
Letta	yes: feedback: optional "positive" or "negative"	an agent step, not a returned memory	no page on the surfaces read names a consumer of the signal
Mnemoverse	yes: memory_feedback, "Report if a memory was helpful (+1) or wrong (-1)", an outcome from -1.0 to 1.0	the memories a recall returned, by memory_ids	"Final score after valence modulation: score * (1 + alpha * v)" in the public engine schema; the coefficient is unpublished	relevance order; under a recency sort the date sets the order and valence does not change it	yes, in a shipped surface of 10 tools on each path; only the npm package's tool takes a room's domain for shared rooms (Beta)

Instruments and dates. Vendor rows: the documentation pages, API references, machine-readable specifications and published source named in each section, read on 21 September 2026, with the load-bearing quotations re-read on 22 September 2026. The Mnemoverse row: MCP server 0.11 and the public engine schema, checked on 22 September 2026. "Not documented" is bounded to those instruments.

An empty cell is empty because the surfaces read did not answer that column, and every absence is an absence on a named surface on a named date, which is the only kind of absence a page like this can honestly report. There are nine rows for eight systems, because Zep answers differently for Agent Skills and for the Context Graph, and collapsing the two would misstate both.

Cognee documents the whole loop, and ships it switched off

Of the seven systems here that are not ours, Cognee is the only one where all three names are published. The rating lands somewhere named, something named reads it, and the default is stated in the same breath as the capability.

Where it lands: "Feedback on recall answers is handled via Sessions: you record Q&A in a session, then attach feedback to specific entries using cognee.session.add_feedback and cognee.session.delete_feedback" (docs.cognee.ai/guides/feedback-system). The rating runs from 1 to 5 points against that entry.

What reads it: "Session feedback updates feedback_weight on graph nodes and edges that were used during retrieval" (docs.cognee.ai/core-concepts/main-operations/improve). The weight then enters the score through a published expression in their repository, in cognee/modules/graph/cognee_graph/CogneeGraph.py:

blended_normalized = (1.0 - active_feedback_influence) * normalized_distance + ( active_feedback_influence * (1.0 - normalized_feedback_weight) )

What the default is: "The per-call feedback_influence defaults to the DEFAULT_FEEDBACK_INFLUENCE environment variable, which is 0.0 (off) by default". Their own worked example gives the value at which the behaviour becomes visible: "From 0.4 on the up-rated context owns the answer."

Two further details belong with that, because a loop shipped at zero has a cost of entry. A separate personalisation path is bounded from above by published constants: the per-user rank multiplier is capped at 0.3, the weight step is 0.3 per rating, the return toward neutral is 0.02 per conversational turn, and the neutral weight is 0.5. And in the shipped 1.6.0 package, switching feedback influence on globally moves hybrid search onto the graph answer path. Turning the loop on therefore changes which read path runs, not only a weight, which is worth knowing before a rollout rather than after one.

Mem0 publishes the route, and not the reader

Mem0 takes the report, and says what it is for in words rather than in a mechanism. The route is documented and specific, against a memory identifier and with a free-text reason:

The `feedback` parameter can be one of the following values: * `POSITIVE`: The memory is useful. * `NEGATIVE`: The memory is not useful. * `VERY_NEGATIVE`: The memory is not useful at all.

Their guidance, on the feedback mechanism page rather than in the API reference the table links, names the moment this page is about: send it "Immediately after memory retrieval when you can assess relevance" and "Through automated evaluation using your application's success metrics". That is a vendor telling you to wire an automatic outcome into the call, which is the shape this page is looking for.

What the page says the effect is: "This feedback is used to improve the accuracy of the memories and search results", and "Over time, Mem0 continuously learns from this feedback, refining its memory generation and search capabilities for better performance". Those are statements of result. Neither of them is the name of a field or a term.

Set that beside their own ranking documentation, which is unusually clear about what moves order and what does not: "rerank is the only lever here that changes result order. filters, top_k, and threshold change which memories come back, not how they're ordered". Three ranking layers are written out on those pages, a hybrid score combining semantics with a normalised BM25 term and an entity bonus, an optional reranker, and the optional Memory Decay described above. The report is an input to none of the three, on those pages, on 21 September 2026.

The bound on that absence, in the same paragraph. The machine-readable specification in their repository carries 43 paths; the feedback route is 1 of them; its response carries 3 fields, an identifier, a value and a reason; and there is no route that reads feedback back. The open memory class carries no feedback at all, checked by reading the shipped 2.1.0 package rather than a code-search result, so feedback lives in the hosted client. The correct statement is that Mem0 accepts the report and does not document a mechanism that reads it when ranking. It is not that the report does nothing, which is a claim about a backend nobody outside the company can see.

Three more inputs that take an outcome and answer another question

Each of these is a real mechanism, each is useful, and none of them answers the question this page asks. Confusing any of them with outcome re-ranking is the easiest mistake in this subject.

Supermemory judges whether a derived fact is true. Its documentation is more precise about an effect on rank than most: facts the engine inferred "are flagged as inferred (isInference: true) and down-weighted in search until confirmed", and two endpoints "let you build a review experience on top of that queue: list the inferred memories awaiting review, then approve, decline, or undo a decision on each one". Approval makes an item rank "like a stated fact". That is a documented, directional effect on ranking. The verdict it takes is about the truth of a guess the graph made by itself rather than about how a recall turned out, and the page describes it as a screen a person builds. On what is absent: a feedback route does not appear in their documentation export, in the live specification, which carried 33 paths when it was re-read on 22 September 2026, or in either published SDK, and because their path list is incomplete by demonstration that is a floor rather than a ceiling. A probe in the /v3 namespace does not distinguish a missing path from a real one, so it measures nothing there. In /v4 it does distinguish, and there is no such route.

Zep uses an outcome to admit a Skill. The binding is unusually exact: "Send the signed search_id with the Skill use. The server resolves the Skill version and rank from the signed search result", and the reference "binds the Agent, principal, query, request identity, and ordered Skill hits. It expires after one hour". The outcome takes success or failure plus a confirmation class of 5 values. The documented consequence is admission rather than order: "Zep compiles eligible Trajectories into a candidate Skill. The default memory_settings.approval value is manual, so a developer approves the candidate." No page says a reported outcome changes the order of the next read. And the verb is documented, not shipped: neither published SDK at 3.28.0, Python or JavaScript, contains a file mentioning skill, trajectory, outcome or feedback, and none of the 50 changelog pages through 19 September 2026 mentions it.

For Zep's memory itself, the Context Graph, an outcome report is not documented, and the direction of travel is the other way. Fact ratings, the one relevance lever handed to a developer, are withdrawn in the February 2026 deprecation wave, and the migration table gives three different replacements for the three removed fields, so no single row describes what happens. The three rows read: "| minRating query parameter | Remove - use context block relevance instead |", "| fact_rating_instruction field | Use custom ontology or user summary instructions |" and "| min_fact_rating in search queries | Remove - rely on default relevance ranking |". The page states the scope itself: "Fact ratings are being deprecated entirely", listing the query parameter, the instruction field on users, sessions, groups and graphs, the search field, and "Methods for retrieving facts directly by rating". Their stated philosophy fits the direction: "The underlying principle: it's better to provide complete information and let the agent or downstream LLM filter what's relevant than to risk omitting something important." The bound on the absence: 267 pages of the third-version documentation read in full with every keyword hit opened, plus both official SDKs at 3.28.0. Zep publishes a blog page with the word feedback in its title, so the claim here is specifically that an outcome report for the Context Graph is not documented on those surfaces, not that the word is absent from their site.

Letta stores an outcome on a step. The endpoint takes feedback: optional "positive" or "negative", two values plus labels, and steps can be filtered by whether a report exists. What it is attached to is an agent step rather than a returned memory, which are different objects, because a step can succeed while the memory that informed it was wrong. No page on the surfaces read names a consumer of the signal. Their search does publish its ranking, "Returns messages with FTS/vector ranks and total RRF score", and their file-backed memory states its own limit, "MemFS does not include a semantic or vector index by default". Their instruction to their own memory subagent is about organisation rather than outcome: "Your goal is to reorganize memory for long-term usefulness. Avoid arbitrary limits; prioritize clarity, low redundancy, and easy retrieval." The bound, re-measured on 22 September 2026: their sitemap lists 116 documentation pages and 516 API reference URLs, and the published @letta-ai/letta-code package at version 0.32.17 holds 1,094 files. The starred letta-ai/letta repository is a 12-file stub, so a zero from searching it looks like proof and is not one.

If a vendor answers "yes, we have feedback", the useful follow-up is not whether they have it. It is which of these five things they mean: reinforcement for having been returned, a verdict on a fact the engine guessed by itself, an outcome that admits a skill, an outcome stored on a step with no named consumer, or an outcome that re-orders the next recall.

Where the rule finds no input at all, and what it does find

Graphiti publishes no mechanism for receiving an outcome, on a search of the unpacked main tarball rather than a code-search result, with the PyPI version matching main. What it does publish is a closed set of rerankers, five values in the edge enumeration, written into graphiti_core/search/search_config.py:

class EdgeReranker(Enum):
    rrf = 'reciprocal_rank_fusion'
    node_distance = 'node_distance'
    episode_mentions = 'episode_mentions'
    mmr = 'mmr'
    cross_encoder = 'cross_encoder'

One of those five sounds like use counting and is not. episode_mentions runs this query:

MATCH (episode:Episodic)-[r:MENTIONS]->(n:Entity {uuid: node_uuid})
        RETURN count(*) AS score, n.uuid AS uuid

It counts how many ingested episodes mention an entity, which is a property of the data written in, not of the reads that came out. Saying Graphiti counts nothing would be wrong. Saying it counts outcomes would be wrong in the other direction.

Basic Memory publishes its ranking and takes no outcome signal. The fusion is in the source with a version string attached, FUSION_BONUS = 0.3 and FUSION_FORMULA_VERSION = "max+0.3*min/v1", and the version string travels in the search trace. Cross-encoder reranking exists from version 0.23 over a window of 20 candidates and is off by default: "| reranker_enabled | false |". Ranking there is a function of the query and holds no state about past reads. Their own use of the phrase feedback loop means a person editing notes: "- Human-in-the-loop refinement - You can correct and improve AI-generated notes, and the AI learns from your edits". The bound on the absence, re-measured on 22 September 2026: a 652 KB documentation export plus the published basic-memory wheel at version 0.23.2, 398 files, because their sitemap is empty, so a sitemap-driven sweep would have measured zero and called it an answer.

The MCP wall: where the loop mostly does not close

An SDK page is not an answer to the question an agent asks. The agent is connected through a client, the client is handed a list of tools, and the loop closes only if a tool in that list takes an outcome. If these servers are new to you, this site has a separate page on What Is an MCP Memory Server? Protocol, Tools, Tokens.

From that list, it mostly does not close. On the hosted Mem0 MCP page the tool table carries 11 tools and feedback is not among them; the archived open server registered 9 and did not have it either. The claim is scoped to that table and that date for a reason: their own changelog for 9 June 2025 carries a line about a JavaScript MCP server with feedback support. What the tool table says today is a fact about today.

Cognee's default list is 5 tools: write, recall and forgetting, plus two discovery tools, search_tools and call_tool, which reach the rest of the catalog by name. A fourth memory tool, cognify_status, is "registered but not advertised" unless the server runs in all mode. Its own page records what left: earlier versions "also registered cognify, search, prune, improve, save_interaction, get_document, get_chunk_neighbors, list_data, delete, and delete_dataset as MCP tools ... The workspace UI and all of these tools have been removed in every mode". Graphiti's built-in server carries 13 tools and none reports an outcome. Zep does publish a tool for recording an outcome, and it appears in the list only when 5 conditions are satisfied at once.

The caveat, without which the paragraphs above are false. Cognee's same page says any registered tool can be invoked by name, that the default list does not show all of them, and that separate search and invoke tools exist. So the statement here is narrow on purpose: in the tool list there is no tool that moves ranking. Not that an outcome cannot be reported at all. If you rely on a tool that is reachable but unlisted, check whether your own client can call it.

One system on this page breaks the pattern. Mnemoverse's tool list carries the rating tool on both paths, the npm package and the hosted connector, and it is reachable from an MCP client on either one. Only the npm package's tool accepts a room's domain for shared rooms (Beta); the hosted connector's does not. That is a shipped surface of ten tools. The section near the end unpacks what the rating does after it is received.

The idea is 55 years old, and that is the interesting part

Everything above is a question about plumbing. The technique itself has been settled for a long time.

The standard textbook describes the whole loop as a numbered cycle: "The user issues a (short, simple) query. The system returns an initial set of retrieval results. The user marks some returned documents as relevant or nonrelevant. The system computes a better representation of the information need based on the user feedback. The system displays a revised set of retrieval results." The classic implementation is named in the same book: "The Rocchio Algorithm is the classic algorithm for implementing relevance feedback." Rocchio was published in 1971, which makes the technique 55 years old in 2026.

Removing the human from the loop is not new either. The same book gives it a section: "We can also use indirect sources of evidence rather than explicit feedback on relevance as the basis for relevance feedback. This is often called implicit (relevance) feedback." Learning a ranking function from that evidence was published in 2002: "This paper presents an approach to automatically optimizing the retrieval quality of search engines using clickthrough data". And combining a reported judgement with a similarity score is ordinary infrastructure, documented in mainstream search: "While a judgment list can be created manually by humans, there are techniques available to leverage user engagement data, such as clicks or conversions, to construct judgment lists automatically".

It is present in agent memory research as well. ExpeL, published in August 2023, gives the agent a vote on its own accumulated insights: "The operations the LLM can perform are ADD to add a new insight, DOWNVOTE to downvote an existing insight, UPVOTE to agree with an existing insight or EDIT to edit the contents of an existing insight." EARM, dated 24 August 2026, states the proposal directly: "These results motivate a broader view of agent memory: a long-lived agent should remember not only past content, but also how that content has proved useful for retrieval."

One more piece of vocabulary, named here rather than left to be discovered. The rule we name in our own documentation, "a prediction-error feedback signal (Rescorla-Wagner-style)", is a prediction-error rule, standardly described as the same rule as the Widrow-Hoff delta rule of 1960. Naming it that way is a choice of vocabulary and not a claim of novelty; it is written out as a rule in Rescorla-Wagner for agent memory.

So what actually changed

Three things, none of them the algorithm.

The reporter changed. A click is evidence about a page. An agent's report is a verdict about a task that has finished, and the agent knows the identifiers of the items the read returned a moment ago, because it was handed them. That is a narrower and later signal than a click, and a negative value is available in it.

The moment changed. In the textbook loop the user marks documents in the middle of a search. In an agent loop the report arrives after the work, when the outcome is known and the session is ending, which is the moment nobody is watching. You can require the call in a standing instruction rather than hoping someone volunteers it, and that bounds itself: a rules file is a request rather than an enforcement mechanism, which this site treats separately in CLAUDE.md, AGENTS.md and Cursor Rules Do Not Enforce.

The reachability is the part that does not follow. A technique 55 years old is, in this category, mostly unavailable to the client that would use it. What was measured for that sentence is a set of tool lists on one date, and on that date the loop mostly did not close from the list an agent is handed. That is a reading of one day, not a trend: two withdrawals are documented here, Cognee removing feedback tools from its server and Zep withdrawing fact ratings, and two withdrawals do not make a direction.

Mnemoverse: the rating tool, the valence term, and the unpublished coefficient

The row above is a row, not a verdict. This section states what we do with sources, in the same neutral register as the vendor sections, and then names what we have not shown.

The call is memory_feedback, on both MCP paths: the npm package and the hosted connector each register it, current as of version 0.11, and the two schemas are not identical. Both take memory_ids, the identifiers of the memories a memory_read returned, and an outcome from -1.0 to 1.0. The npm package also takes an optional domain; the hosted connector's schema has no domain field on this tool, per its published source. The tool description says: "Report whether memories returned by memory_read were actually helpful. This is a learning signal, not a log: 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", and, in the same sentence, that nothing is erased and nothing decays with time. It also tells the agent when to call: "right after you act on (or reject) recalled memories". On the npm package, for memories read from a shared room (Beta), the agent passes the room's xroom: address as domain; a read-only member cannot rate the room's memories. The tool is annotated as not destructive: a rating moves ranking scores, it does not touch saved text, concepts or domain.

The reply reports what the engine returns after the rating: the mean valence of the memories the rating reached, on a scale from -1 to 1. The engine's public schema describes the route as one that "Updates valence and Hebbian weights" and its answer as carrying the "Average valence of updated atoms after the update", so a caller sees a number move rather than an acknowledgement alone. The REST and Python SDK take the same call with two more fields, concepts and query_concepts; over MCP the npm package's tool sends ids, outcome and domain, and the hosted connector's sends ids and outcome only. Linking the rated memories to the query's concepts is a REST and SDK option.

What reads the rating is documented in the public engine schema. The relevance field of a returned item is described as "Final score after valence modulation: score * (1 + alpha * v)", with similarity as the raw cosine similarity. The shape of the term is public; the coefficient alpha is not published. Our llms.txt states: "outcome feedback re-ranks what comes back next, and unhelpful memories are out-ranked rather than erased". Since 2026-08-23 the adjustment applies before the cut, as the MCP server page puts it: "The read path used to apply its feedback and recency adjustments after ordering and truncation, so the advertised re-ranking never actually changed what came back. The engine now applies them before the cut (live in production since 2026-08-23), so a memory you up- or down-weight genuinely moves in the results." Valence is one term among several: a recency boost and expansion along learned associations also move the order. Under a recency sort the date sets the order and valence does not change it. The default ordering is relevance, so a rating affects the default read. The loop is explicit: a rating is a call the agent makes after acting on a recall, nothing runs on a background clock.

The page about Hebbian memory for AI agents covers the association half of the read, and Rescorla-Wagner for agent memory writes the update rule out as a rule rather than as a feature.

What this page does not claim

Said plainly, because the omissions are as load-bearing as the findings.

Nothing here says that an outcome loop improves retrieval accuracy, ours or anyone's. This page is about whether a documented mechanism exists and is reachable, which is a separate question from whether it works.

No magnitude is claimed for our own effect. The signal range and the shape of the term are published; the coefficient alpha is not.

Nothing here is a statement about any closed backend. Every absence is an absence on a named instrument on a named date. Vendors ship things they have not written down, and this page cannot see them.

Nothing here accuses anyone of overstating. Where a vendor's page describes a result and does not describe a mechanism, that is what is reported, with their sentence quoted whole.

Nothing here is a promise about us: no timeline, nothing forthcoming, nothing planned.

Five checks you can run yourself, each with a control

Do this before believing any comparison, including this one. A zero without a control is not a result, which is why every step carries one.

1. Ask the tool for its own tool list. For an MCP server that is tools/list. Look for one that takes the identifiers of memories a read just returned, plus an outcome. Control: ask for a version of the package that cannot exist. It must fail to start. If it starts, the list you just read is not the artifact you think it is.
2. Find in the documentation where the rating lands. You need a field name, not the phrase "used to improve results". Control: request a page on the same host that cannot exist. It must return 404. If it returns 200 with a not-found body, compare bodies rather than status codes.
3. Find what reads that field when ranking happens. You need the name of a term in the score or of a call parameter. If the vendor documents its ranking layers in detail and your field is in none of them, that is your answer. Control: search the same corpus for a word that must be found, such as the product's own name, and for a nonsense word that must not be.
4. Read the default out loud with the capability. A published loop shipped at zero is not a running loop. Quote the default in the same sentence as the feature, the way Cognee's own page does. Control: if the default is set by an environment variable, read the variable's default rather than the parameter's.
5. Check whether any of it reaches your client. REST and an SDK are not MCP. If you connect over MCP, read the tool table rather than the API page. Control: call the tool and read what comes back. A silent success that changes nothing is the normal way to discover that your call went somewhere else.

One warning about step 3 that cost us time. If you are grepping a vendor's repository, check that the repository is the source and not a placeholder. One of the vendors here has a starred repository of twelve files whose README points at the real one. Zero from a placeholder looks exactly like zero from an absence.

Three names are what you are looking for in any memory tool, and they are the same three every row of the table above was asked for: the field the rating lands in, the term in the ranking score that reads it, and the default value of that reading. Run all five steps against us first. Step 1 passes, the tool exists and takes memory_ids and outcome, plus an optional domain on the npm package. Step 2 passes, the field is named. Step 3 rests on the public engine schema, which names the term but not its coefficient; what a caller can observe directly is the average valence the reply reports after each rating. Step 4 passes: the default order is relevance. Step 5 passes on both MCP paths; rating a shared room's memories (Beta) currently works only on the npm package, which is the step this category fails most often.

And if a vendor answers "yes, we have feedback", the useful follow-up is not whether they have it. It is which of these five things they mean: reinforcement for having been returned, a verdict on a fact the engine guessed by itself, an outcome that admits a skill, an outcome stored on a step with no named consumer, or an outcome that re-orders the next recall.

Common questions

Can I tell an AI agent's memory that a recalled result was wrong?

Yes, in several systems, but the object and the effect differ. Cognee takes a rating from 1 to 5 points attached to a recorded question and answer. Mem0 takes POSITIVE, NEGATIVE or VERY_NEGATIVE against a memory identifier. Letta takes a binary verdict on an agent step. Supermemory takes approve, decline or undo on a fact its graph derived. The question worth asking is whether anything reads that input when the next read is ordered, and what the default of that reading is.

Does Mem0 feedback change search ranking?

Mem0 documents the route and describes the effect in words rather than in a mechanism. Its page says the feedback "is used to improve the accuracy of the memories and search results". On the surfaces read on 21 September 2026, three ranking layers are written out in detail: a hybrid score, an optional reranker and an optional Memory Decay. None of them names the feedback report as an input. The machine-readable specification carries 43 paths, one feedback route, a three-field response and no route that reads feedback back. That is an absence on those instruments on that date, not a claim about their backend.

What is the difference between memory decay and outcome feedback?

The input. Mem0's Memory Decay reinforces a memory because it came back: the documentation calls it "a fire-and-forget reinforcement against each returned memory: its access history grows by one, capped at the most recent 20 touches", and that history becomes a scaling factor from 0.3x to 1.5x at search time. Nothing in that path knows whether the memory helped. Outcome feedback carries a verdict about how the recall turned out. Memory Decay is opt-in per project and off by default, and it runs in search v3 only.

Which agent memory systems re-rank by outcome feedback?

On the surfaces read on 21 September 2026, Cognee is the one system here that documents the whole chain end to end: a rating attached to a session entry, an improve step that writes feedback_weight onto the nodes and edges used during retrieval, and a recall parameter that blends that weight into the score. It ships switched off, with DEFAULT_FEEDBACK_INFLUENCE at 0.0. The other vendors document parts: a route without a named reader, an outcome bound to an agent step with no named consumer, an outcome that feeds an admission decision, or a human review of whether a derived fact is true.

Can an agent send outcome feedback over MCP?

Usually not from the tool list it is handed. 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 finding the rest by name, and its own page says the improve and save_interaction tools were removed. Graphiti's built-in server carries 13 tools and none reports an outcome. Zep has a tool for recording an outcome that appears only when 5 conditions hold at once. Mnemoverse's tool list carries the rating tool on both paths; shared-room (Beta) rating via domain currently works on the npm package only, per its published source — the hosted connector's schema has no domain field on this tool.

How do I check whether a memory tool actually reads my rating?

Five steps, each with a control. Ask the server for its tool list and look for one that takes the identifiers of the items just returned plus an outcome. Find the field name the rating lands in. Find the term in the ranking score that reads that field. Read the default value, because a loop shipped switched off is not a running loop. Then check that the path is reachable from the client you actually use. Mnemoverse's tool passes steps one, two, four and five; step three rests on the public schema line, and the coefficient is unpublished.

Related

• Agent memory feedback: the missing signal: the same subject from the other side, once the input exists, which this page relies on rather than repeats
• Why AI Coding Assistants Repeat Fixed Mistakes: Who Takes an Outcome?: the same mechanical question asked in the narrower form its title states
• Rescorla-Wagner for agent memory: the update rule named in our documentation, written out as a rule rather than as a feature
• Hebbian memory for AI agents: the association half of the loop, and what expansion along links does to an order
• What Is an MCP Memory Server? Protocol, Tools, Tokens: the protocol and token grounding under this article's MCP section
• CLAUDE.md, AGENTS.md and Cursor Rules Do Not Enforce: the bound on requiring the report in a standing instruction
• Mnemoverse API reference: the REST endpoint for outcome feedback
• Mnemoverse MCP server: the tool list and the rating tool's description
• Mnemoverse changelog: the 2026-08-23 change that moved feedback before the cut

Edward Izgorodin · Mnemoverse · 2026-09-22

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