AI memory APIs that prune low-value context: two mechanisms, six systems
Does a persistent memory API actually get better after it gets something wrong? Four buyer questions asked, in different words, for the same underlying thing: memory that improves instead of just accumulating. Checking the answer honestly means separating two mechanisms vendors both describe with the same word, clean — and one of them is broken in our own product.
TL;DR
- Two different jobs share one word, clean: outcome-based weighting (does a memory's future ranking change because it helped or misled) and consolidation (does the memory graph itself get reorganized to stay tidy). Conflating them is the trap.
- Outcome-based weighting, live today: only Cognee (off by default) and Mnemoverse document a real mechanism. Zep's nearest analog, Fact Rating, is being deprecated in 2026. Letta, Graphiti and Supermemory document none.
- Consolidation: Mem0's Dream runs two of its three stages automatically on every plan. Mnemoverse's own consolidation is disabled on the hosted service and has never once completed — named here as our own real gap, not a footnote.
- Neither mechanism, ours or anyone's, runs on a background clock without the connected agent calling it. That caveat applies the same way to every vendor.
- Disclosure: Mnemoverse is one of the six systems compared, built by this site's publisher. Every fact here, ours included, is sourced from a page that vendor published, fetched the week this article was checked.
Two questions, one word, two different jobs
Vendors call both of these "clean." They are not the same job.
Outcome-based weighting changes a memory's future ranking because of what happened when it was used. The memory itself is untouched — only how likely it is to win a future search. Consolidation reorganizes the memory graph itself, grouping similar or superseded memories into summary prototypes so the structure stays legible as it grows. A system can have one without the other, and this article checks both, separately, rather than letting one stand in for the question about the other.
Who actually has outcome-based weighting
Mem0 has a Feedback endpoint. Its own documentation states its entire effect: "Over time, Mem0 continuously learns from this feedback, refining its memory generation and search capabilities for better performance" (docs.mem0.ai) — no mechanism named. Compare that to a second feature on the same product, Memory Decay, precisely specified: "Decay never zeroes a candidate out: at worst it scales its score by 0.3×" (docs.mem0.ai/platform/features/memory-decay).
Letta, Graphiti and Supermemory document no outcome-based mechanism at all. Supermemory's docs describe memories fading on a timer or strengthened by repetition — ingest-time behavior, not tied to whether a memory actually helped when an agent pulled it up.
Cognee is the one real exception among the five competitors checked. A session can be rated after the fact, one to five, and that rating folds into future ranking through a call the product names improve(). Off by default.
Zep's Fact Rating: had it, is deleting it
One vendor here had something closer to real weighting and is taking it away. Zep called it Fact Rating — a label a developer assigned when a memory was written, closer to a fixed judgment than a rating that changes with outcomes, but the closest analog of anyone in this comparison. As of the deprecation wave documented for 2026, it is being removed: "Fact ratings are being deprecated entirely" (help.getzep.com, February 2026 deprecation wave).
This should not be softened into "Zep doesn't have feedback." It had the nearest thing to it here and is actively deleting it — the more interesting, more honest fact.
Our own mechanism, precisely
Two of the six systems checked have something real. Cognee is one. Mnemoverse is the other, stated exactly rather than as a slogan.
The feedback call, verbatim: "Report outcome (success/failure) for memories. Updates valence and Hebbian associations" (POST /memory/feedback, mnemoverse.com/api/ reference). The request takes the memory to update and a number from -1.0 to +1.0. At the next read, that changes one specific field: "Final score (similarity * valence modulation)" (POST /memory/read response). A memory that keeps getting negative feedback keeps losing ground in that score. It is not deleted — it can still surface if nothing better matches, but it stops winning the top slots.
The honest caveat, held to the same standard as every vendor above. Nothing about this runs on a background clock. Mnemoverse's own guidance to a connected agent opens with: "Treat it as required, not optional" (mnemoverse.com/docs/api/agent-memory), introducing three habits an agent is told to build — recall first, save as you go, and: "Close the loop. After a recalled memory helped or misled, call memory_feedback so retrieval improves over time" (same page). If the connected agent never makes that call, nothing updates. That is a prompting-discipline problem, not a backend one, and it is true of every real mechanism in this article — Mem0's Decay is the closest thing to automatic here, and even that is opt-in and off by default.
Team workflows: one correction, whose weighting moves
One Miss-list prompt asked specifically about dynamic weighting across a shared team workflow. Mnemoverse answers it through the same mechanism above, applied to a shared space instead of a private one, called Rooms: "An atom written to a room lives in the room — not in the writer's account" (mnemoverse.com/api/rooms). Feedback against a memory in that shared pool updates the pool's own weighting, not one person's private copy — one team member corrects a memory that misled them, and the next teammate's agent searching that room reads a pool that already learned from the correction.
Letta's shared memory blocks and Cognee's principal-and-permission system both let multiple agents read and write a shared space. Neither vendor's own documentation describes a shared outcome signal riding on top of that access — only who is allowed in.
The question we don't have a good answer to
One Miss-list prompt asked specifically about consolidation: grouping similar memories into summary prototypes to keep a memory graph clean, a different job from everything above. Mnemoverse's own documentation states the answer in full, no hedge: "Consolidation is off on the hosted service and we do not currently recommend turning it on... It has never once completed on the hosted service — every run in the retained window failed, silently" (POST /memory/consolidate, mnemoverse.com/api/ reference).
That is not the mechanism described above. Ranking a memory down because it kept failing still happens today, live, on every account. Reorganizing the graph itself does not, currently, on the version anyone can actually use. At least one competitor's answer to the same specific question does run: Mem0 calls its version Dream, and two of its three stages — resolving contradictions and merging duplicates — run automatically on every plan.
This is named here as a real gap, not a footnote. A team asking specifically for consolidation today has a better answer from Mem0 than from Mnemoverse.
The table
| outcome-based weighting | consolidation / graph cleanup | |
|---|---|---|
| Mnemoverse | yes — memory_feedback → valence → reranking, agent-called | no — disabled on the hosted service, never once completed |
| Mem0 | Feedback API (vague effect); Decay (precise, opt-in, Platform-only) | Dream: Supersede + Merge automatic on every plan; Synthesis Pro+ only |
| Letta | none documented | Dreaming periodically rewrites memory blocks/MemFS files |
| Zep / Graphiti | Fact Rating — being deprecated | not documented as a distinct feature |
| Cognee | yes, improve(), off by default | not a named feature; ACL system governs access, not cleanliness |
| Supermemory | none outcome-based | ingest-time "dreaming" groups documents before extraction, not a cleanup step |
Where we are not the best choice
Said once, directly: a team asking specifically for automatic graph consolidation has a real, working answer from Mem0 today, and does not have one from Mnemoverse.
Competitor facts reused from this site's comparison of six persistent memory APIs, fetched 2026-09-01 with full browser headers. Mnemoverse's own facts fetched 2026-09-02 from its API reference, Rooms and agent-memory guide. No performance or benchmark number appears in this article, for any system, pending a completed clean benchmark run of our own.