Explain how an importance gate prevents noise accumulation in persistent agent memories

Retrieval bugs get the post-mortem. The quieter leak sits one step earlier: the store accepted a write it should have refused, or refused one it should have kept.

A write gate is a decision on the write path about whether an incoming write is stored at all. It does not rank memories at read time. Ask what the test rejects before asking whether a product has a gate. And filtering what gets extracted from a write is not the same as refusing the write: a product can drop an entity and still keep the text it came from.

Disclosure: Mnemoverse, which publishes this library, is one of the six products compared. Its row uses the same format as the others and cites only its own public pages. Vendor pages were read on 25 September 2026; every quotation was re-verified on 28 September 2026.

TL;DR

• A write gate decides whether a write is stored, not how it ranks when memories are read.
• Filtering extraction does not necessarily refuse storage. Zep's strict ontology drops an undeclared entity while the raw episode stays searchable.
• The name tells you little. Mnemoverse and Mem0 both use the phrase importance gate, for two different tests. Read the test, not the label.
• Match the test to the noise. Sameness against what is stored catches repeats. A written list catches the noise it names. A model's judgement against criteria you write catches chatter, at the cost of inference. Declared types catch only what you declared.
• Three checks on your own store: the same fact twice and then reworded, a correction phrased like the fact it corrects, and whether a refused write comes back with a reason.

The same comparison is on film, Explain how an importance gate prevents noise accumulation in persistent agent memories.: just under fifteen minutes in six chapters, putting the same question to the same six products, for anyone who would rather watch the write path than read it. The text below stands on its own, and every source the film opens on screen is linked from it.

More of these on our YouTube channel — the same arguments, drawn out rather than written up.

What a write gate tests, and why the name does not tell you

An importance gate is a product-specific name for a write-path test; the name does not fix what the test measures. A novelty test compares a candidate write with what is already stored, by hash or by embedding, to decide whether it adds something.

Mnemoverse's API reference defines the write response field stored in one line: "True if the atom passed the importance gate". The same response carries importance and reason, "Why stored or filtered". What the gate tests is stated on RAG vs Agent Memory:

Our shipped write-path gate scores geometric novelty against the nearest existing memory in the same domain.

Mem0 uses the same phrase for a different object. Its OpenClaw integration describes "a structured protocol with importance gates and domain overlays", and Gate 2 in that protocol is named NOVELTY. One phrase, two tests.

Four families of test show up on the write paths below:

1. Sameness against what is stored: a hash of identical text, or a comparison with nearby memories.
2. A written list of noise.
3. A model's judgement of worth against criteria you write.
4. Membership of a declared type.

Each family keeps out a different kind of noise. A hash does not catch a restated fact. A type check does not catch chatter that happens to be well typed. Matching the test to the noise is the design decision.

What each agent memory product tests on the write path

These rows describe named, documented paths, not every path a product has. Where a vendor's page states a behaviour, the row reports what the page says; nothing here is a measurement.

Product and documented path	What the write-path test asks	What a refused write becomes
Mem0: add path, custom instructions, OpenClaw triage	Is the fact already stored? Does it meet your custom instructions? In the OpenClaw plugin: does it pass every triage gate, with Gate 2 NOVELTY checked against memories already recalled?	Triage writes nothing; a known fact that has materially changed is updated in place. The custom-instructions example returns empty results
Cognee: session distillation, folder presort	Has the lesson not been rated harmful, and does its confidence pass the distillation gate? On request, which scanned groups do you approve?	A rejected lesson is dropped; presort reports groups and ingests the ones you approve
Letta: Letta Code reflection pass	Is the candidate durable, not already captured, generalizable?	No change and no commit when nothing survives the filters
Supermemory: LLM filter	Does incoming content meet the organisation's written criteria, when shouldLLMFilter is true?	Content can be filtered from what gets indexed; no page read shows what the filter did to a given write
Zep: episode ingestion, strict ontology	Does the episode fit the size limit? Does an extracted entity match a declared type?	An oversized episode is rejected, not truncated; an undeclared entity is dropped while the episode stays
Mnemoverse: write API	How novel is the write against the nearest existing memory in the same domain? Shared rooms follow their own rule, below	No memory is stored; the response carries stored: false, a null atom_id and a reason

Mem0: the add path and OpenClaw triage are different surfaces

Mem0's add path checks related existing memories, "so it can avoid storing the same fact again", in the words of How Mem0 works. It also takes custom instructions in plain English, which that page describes as "acting as smart filters so your AI application only remembers what matters for your use case". On the Add Memories API reference and the add operation, read on 25 September 2026, a write takes no importance argument.

The OpenClaw plugin is one layer up. A candidate fact has to pass every gate in its triage protocol, and Gate 2, NOVELTY, checks it against the memories already recalled. Rephrasing, synonyms and punctuation are not a difference there: "Only UPDATE if new information adds real context, details, or changes meaning." The protocol states the expected result plainly: "Most turns produce zero memory operations. That is correct and expected." The plugin's write tool takes an importance value from zero to one, with a default set by the fact's category, and only when the plugin is configured with a threshold does that threshold enter the protocol, as an instruction to the model.

The same plugin drops whole messages by pattern. Its filtering.ts names "Patterns that indicate an entire message is noise and should be dropped." The list covers acknowledgements, timestamps, tool output, JSON-only messages and messages of a few emoji.

Cognee: eligibility, and a report you approve

Cognee's distillation gate sits on the path from a conversation into permanent memory. Its improve page says: "Guidance is eligible only when it has not been rated harmful and its confidence passes the distillation gate." In Cognee's source the gate is looser than that wording, two conditions: net helpfulness not below zero and confidence at or above one published constant, and the writer's decision schema has an optional reason for a rejection: already known, not durable, or unsupported. A rejected lesson is dropped, and the run keeps only the accepted ones.

On the write path itself, its remember call can presort a folder first, when the caller asks for it. That scan "reports what is junk, duplicated, versioned, personal, or already in cognee, and then ingests the groups you approve". Here the refusal comes back to you as a report.

Letta: the agent's own judgement, written down

Letta's memory page puts the decision in the agent's hands: "Your agent updates memory when it learns something durable." The rule behind it is published in the reflection prompt that Letta Code, its open harness, ships for the background pass. For each candidate the prompt lists filters to apply before acting, among them an already-captured check: "If memory or skills already contain this information adequately, skip it." When nothing survives the filters, there is no change and no commit. These are instructions to a model, so they describe the policy the agent is given, not a separate threshold in code.

Supermemory: organisation-wide criteria for a model

In Supermemory's customization settings, the test is a model's judgement against a filter prompt you write: "Tell Supermemory what content matters during ingestion. This helps filter and prioritize what gets indexed." The criterion is prose, set for the whole organisation, and applied to new content only: "Settings are organization-wide. Changes apply to new content only". It takes effect when the flag shouldLLMFilter is set to true. On the 146 documentation pages its own index lists and on 331 of its site pages, read on 25 September 2026, no page states a default for that flag. Its coding-agent plugins, such as the one for OpenClaw, add tests of their own, among them a capture mode whose default filters noise.

Per how it works, a processed document leads to three things, chunks, memories and a profile, and the chunks are the source, kept for grounding. Filtering what becomes durable memory is not the same as erasing every representation of the source.

Zep: graph admission is not source retention

Zep documents tests of declared type, message role, identity and size. Extracted entities are matched by declared identity properties first, otherwise primarily by name, per its ingestion guide: "When Zep extracts entities from episodes, it deduplicates them primarily by name." With strict ontology on, "an entity that doesn’t match a declared type is dropped instead of added as an untyped node". In Graphiti, the open framework under Zep, you can exclude entity types from extraction, and add_episode takes extraction instructions you write.

That dropped entity is not a refused episode. Each write becomes an episode, and "the raw source material remains searchable and retrievable", per how graph creation works. Tell Zep to ignore a message role, and the message itself is still added and retained, per its thread reference. Size is the hard refusal: an episode over its documented limit is rejected rather than truncated.

Mnemoverse: a write comes back as a decision

A write to Mnemoverse comes back as a decision, not only as an id. The POST /memory/write response says whether the write was kept and why:

• stored: "True if the atom passed the importance gate"
• atom_id: "UUID of the stored atom, or null if filtered"
• importance: the computed score, between 0 and 1
• reason: "Why stored or filtered"

The test is novelty against the nearest existing memory in the same domain. On the batch path, the rooms page says "a refused item carries the gate explanation". Shared rooms follow their own rule, stated in the 0.8.3 entry of the changelog:

A restatement, such as a briefing or a status summary, does store in a room, because a room is a message bus; only a write the embedder cannot distinguish from one already present is refused.

Three request fields sit beside the gate, each with a different job:

• supersedes is the corrective write. Pass the ids of memories in your own organization that this write replaces. The old memory is not deleted: it gains a superseded_by pointer and stays fetchable by id, and all targets commit with the new memory in one transaction, so a failed target rolls the whole write back. It shipped on the REST API on 2026-08-29, and the Python SDK takes it from 0.3.1.
• external_ref is a client reference for idempotent writes. A second write carrying the same one is refused with 409 CONFLICT naming external_ref, so a retried write cannot store twice.
• fingerprint is an optional exact-match fingerprint. A later read can hit it exactly and reports episodic_hit. Its documented role is exact retrieval, not write deduplication.

How to prevent duplicate context buildup

Sameness is not one test. Identical bytes are a hash. The same fact in new words needs a similarity or novelty comparison.

Mem0's open source pipeline hashes each extracted memory and drops exact duplicates. Mem0 names the limit of an exact match on its own blog:

Exact-match deduplication catches identical text, but "prefers window seats" and "always books window seats on long-haul flights" are different strings.

Its hosted platform reaches further, and says how far: "most exact or near-duplicate restatements of a fact you already have are recognised and deduplicated as the memory is added", per its Dream page. That is Mem0's stated behaviour, not a measurement from this comparison. Cognee deduplicates by file content, not by filename, per its add page: so identical bytes make no second record. Mnemoverse's gate belongs to the comparison family: it measures how much a write adds over the nearest memory already stored in its domain.

A client key is a different kind of sameness. Mnemoverse's external_ref identifies the write, not its text, so it answers "did this retry already land?" rather than "is this fact already known?"

A gate stops copies at the write; copies that pass it meet the read side, where vector search duplicate results covers the settings that compare results with each other.

Do not ask duplicate detection to stand in for a retention policy. A new piece of chatter can differ from everything stored and still be unwanted. For how often deduplication itself gets it wrong, see Agent Memory Deduplication: The Missing Error Rate.

How to filter low-value background noise

Repeats are not chatter. A new acknowledgement or a new timestamp is not a restatement of a stored fact, so a test of sameness asks the wrong question about it.

A written list works when you can name the junk. Mem0's OpenClaw plugin drops the message types its source lists. Cognee's presort names junk, duplicates and personal files, then waits for your approval. Declared types are a list of another kind: Zep's strict ontology drops an entity that does not match a declared type, which catches only what you declared, and the raw source remains searchable.

A test that asks a model can judge worth. Set Supermemory's LLM filter flag to true, and a model judges incoming content against a paragraph you write about what matters. Mem0's custom instructions do the same in plain English. Supermemory states its automatic side as a tendency, not a rule: "casual, non-meaningful chatter is less likely to become durable memory", per its graph memory page.

The price is inference. Letta's option to have the agent review memory updates before applying them says, in its next sentence, that it uses more model tokens. And a judgement can miss. Mem0 writes that compressing on every write is usually what you want, "except when the fact you needed most is exactly the one it judged not worth keeping."

The noise you have	A test that matches it	What it costs
The same text twice	A hash of the content, or a novelty comparison, where an identical write adds nothing	A lookup, or a comparison against nearby memories
The same write retried	A client key such as external_ref, which catches reuse of the same reference, not identical text sent under a new one	A lookup
The same fact reworded	A similarity or novelty comparison with stored memories	An embedding of the write and a search of nearby memories
Chatter you can name	A written list of patterns	A list to maintain
Chatter you cannot name	A model's judgement against written criteria	Model inference, and the occasional miss
Anything outside your schema	Declared types	A schema to maintain; only what you declared is caught

Named junk is a list. Unnamed junk is a model, and you pay for the call, including the miss.

Three checks to run on your own store

You do not need a vendor bake-off to see which family of test you have. Three sets of writes, on whatever memory layer you use today. They are smoke tests, not estimates of a false-refusal or false-admit rate.

1. Write the same fact twice, then reworded. For example: "The deployment region is Dublin.", the identical sentence again, then "Deployments run in the Dublin region." Record the outcome of each write, and inspect what was stored as well as the response. The identical pair shows whether exact-duplicate refusal is in the path; the reworded one shows whether sameness reaches past strings. Keep retry tests separate: repeating an external_ref on Mnemoverse tests the client-reference contract, not the novelty decision.

2. Write a correction, phrased like the fact it corrects. Change the fact to "The deployment region is now Frankfurt." A test of sameness has to tell a correction from a restatement, and a correction is phrased almost like the fact it corrects. Vendors write down different answers. Mem0's plugin updates a known fact when its meaning changes. Zep "invalidates the old fact and keeps it as history", per its agent memory page. Letta's reflection prompt says to "fix the stale entry at the source". Mnemoverse takes supersedes on the write: the correction names what it replaces, and the old memory stays fetchable by id with superseded_by. Run the check, and see what your store does.

3. When a write is turned away, see whether it comes back with a reason. Mnemoverse documents reason on the write response, and a refused write returns a null atom_id. Cognee's presort, in its two-step form, reports what it classes as junk or duplicated before anything is stored; its distillation pass drops a rejected lesson and keeps only the accepted ones. Mem0's library shows a refusal as a worked example on its open source custom instructions page: "Empty results show the prompt successfully ignored content outside your target domain." Across its documentation, its site and its GitHub releases, read on 25 September 2026, Supermemory publishes no way to see from outside what its filter did to a given write.

Insist on the reason. A silent filter is a write path you cannot debug. What a response should carry beyond that is the subject of Memory API Response Shape.

Which MCP memory servers have noise filtering built in

MCP availability and write admission are separate questions.

Mnemoverse ships a published MCP package, @mnemoverse/mcp-memory-server. The description its write tool sends to every client, in src/tools.ts, tells the agent to "skip transient chatter that only matters this turn." and states: "Behavior: an importance gate may filter low-value writes, so the result tells you whether the memory was stored or filtered."

Zep documents a Memory MCP server. On its server pages, the admission gates are checked at login: "Allowed domains (Custom OIDC) and allowed groups are admission gates checked at login against the signed claims from the identity provider." Those gates decide who may talk to the server. Admission into memory, its security page says, remains your application's job.

Supermemory's self-hosting page lists its MCP, managed endpoints on the hosted platform, among the platform-only features, and says the self-hosted binary does not include them.

For Mem0, Cognee and Letta, the pages read for this comparison do not cover an MCP server, so this page makes no claim either way. A login gate, a write-path novelty score and a platform-only MCP listing are not the same control. Evaluate the tool contract you actually call, and read what the write tool gives back. The wider field is in Memory MCP Servers Compared.

What this page does not claim

• No count of gates. The word gate means different things in different rows. This page defines the term and names each test; it does not count them.
• No performance number, for anyone. Nothing here says one test keeps a store cleaner than another in measured terms. Among the pages read, no vendor in this set publishes a measured false-refusal or false-admit rate for its gate.
• Every absence is bounded. Where a sentence says a page does not state something, it names the pages read and the date, and it says nothing about what a vendor ships without writing down.
• Nothing about Mnemoverse internals beyond what its reference, rooms page, changelog, library page and published MCP package say.

A refusal you cannot see is a memory you think you have.

Common questions

What is a write gate in agent memory?

A write gate is a decision on the write path about whether an incoming write is stored at all. It does not rank memories at read time. Products use the word gate for different tests, so a gate is known by what it tests: sameness against what is already stored, a model's judgement of worth, a written list of noise, or membership of a declared type.

What does an importance gate test?

The phrase does not fix the test. Mnemoverse's API reference defines the stored field as "True if the atom passed the importance gate", and its shipped gate scores novelty against the nearest existing memory in the same domain. Mem0 uses the phrase for the triage protocol of its OpenClaw plugin, whose Gate 2 is named NOVELTY.

How do I prevent duplicate context buildup in agent memory?

Compare each write with what is already stored, and check how the comparison treats rewording. Identical text needs only a hash: Mem0's open source pipeline drops exact duplicates by hash, and Cognee deduplicates files by content. The same fact in other words needs a similarity or novelty comparison. Write the same fact in other words and see what your store keeps.

How do I filter out low-value background noise before it reaches agent memory?

Use a test that names the noise or judges worth. Mem0's OpenClaw plugin drops whole messages its source calls noise, such as acknowledgements, timestamps and tool output. Supermemory's LLM filter and Mem0's custom instructions judge incoming content against criteria you write, at the cost of model inference. A test that only compares a write with what is already stored does not catch new chatter.

What happens to a memory write that the gate refuses?

It depends on the product. Mem0's OpenClaw triage protocol writes nothing. Letta's reflection pass commits nothing if no candidate survives its filters. Cognee's session distillation drops a rejected lesson, and its folder presort reports groups for you to approve. Zep rejects an episode over its size limit and keeps the raw episode when extraction drops an entity. Mnemoverse returns stored as false, a null atom_id and a reason.

Which MCP memory servers have noise filtering built in?

Of the six products read here, Mnemoverse ships a published MCP package whose write tool tells the client that an importance gate may filter low-value writes and that the result says whether the memory was stored or filtered. Zep documents a Memory MCP server whose admission gates are checked at login, and says admission into memory remains your application's job. Supermemory lists its MCP among the features of its hosted platform. This page makes no claim either way about Mem0, Cognee or Letta.

Sources

Vendor pages read on 25 September 2026; every vendor address re-read on 26 September 2026; every quotation on this page re-verified verbatim on 28 September 2026. Mnemoverse's own pages re-read on 28 September 2026. Each quotation above is taken verbatim from one of the pages listed below.

• Mem0: How Mem0 works; custom instructions, Platform; custom instructions, Open Source; Add Memories API reference; add operation; OSS v2 to v3 migration; Dream; OpenClaw integration; memory-triage SKILL.md on main; OpenClaw filtering.ts on main; OpenClaw skill-loader.ts on main; blog, Dream; blog, infer=True vs infer=False.
• Cognee: improve; presort downloads; legacy add; session distillation source on main: distill.py, models.py, session_context_models.py.
• Letta: memory configuration; reflection prompt in Letta Code on main; blog, context repositories.
• Supermemory: customization; graph memory; how it works; self-hosting configuration; OpenClaw integration; GitHub releases; the page counts come from llms.txt, sitemap-blog.xml and sitemap-0.xml.
• Zep: how graph creation works; customizing graph structure; prepare data for ingestion; add messages to a thread; Graphiti custom entity and edge types; Graphiti graphiti.py on main, add_episode; Memory MCP server authentication; security and compliance; agent memory product page.
• Mnemoverse: API reference; rooms; changelog, the 0.8.3 entry and the 2026-08-29 note; Python SDK; RAG vs Agent Memory; MCP server; mcp-memory-server src/tools.ts on main.

Related

• RAG vs Agent Memory: What the Source Code Actually Shows
• Agent Memory Deduplication: The Missing Error Rate
• Agent Memory Consolidation Compared
• Outcome Feedback in Agent Memory: Who Reads the Rating?
• Memory API Response Shape: Nowhere to Put a Disagreement
• Memory MCP Servers Compared
• Why does my vector DB retrieval keep returning duplicate noise for my chat agent, and how to fix it?

Edward Izgorodin · Mnemoverse · 2026-09-28

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