Memory Is a Job, Not a Layer

Here is a result every team shipping agents should sit with.

In August, researchers ran 8,000 episodes of a tool-selection task where the right answer flips halfway through. Agents with no memory at all succeeded 31% of the time after the flip. Agents with append-only memory succeeded 21% of the time. So did agents with last-write-wins memory. (TEPA, arXiv:2608.07429)

Read that again. Once the world changed, the memory made the agents worse than having none.

That isn’t a bug in one product. It’s what happens when memory is built as a layer: a place where text goes in, gets embedded, and comes back out ranked by similarity. A layer has no clock and no judgment. It can’t notice that Monday’s fact died on Thursday, and nobody is responsible for noticing on its behalf.

In my last article I argued that agents need a memory agent, not a memory API. The response was generous, and the sharpest readers all asked the same thing: isn’t that just branding?

This is my answer. I’ll take the six most common ways teams give agents memory today, name who each one puts in charge of the truth, and show the evidence for where each breaks. Then I’ll follow the argument to its logical conclusion, with code, and hand you a test you can run on any memory system, including ours.

Disclosure: I’m CTO of the team behind Memanto, an open-source (MIT) memory agent. I name competitors below, but only through their own documentation and independent research, and I hold Memanto to the same test at the end.

The one question that sorts every memory system

Forget embeddings, graphs and context windows for a minute. Ask one question of any memory setup: who decides what is true now?

Long-lived memory is not a pile of text. It’s a stream of small, ongoing decisions:

• Keep. Is this worth remembering at all, and how sure are we?
• Revise. Did something new change what an old memory means?
• Retire. Is this fact no longer current, even though it’s still relevant to the query?
• Escalate. Do two memories disagree in a way a model shouldn’t settle alone?
• Brief. Of everything we know, what does this agent need right now?

Every memory system makes those decisions, or quietly leaves them unmade. The difference between systems is who makes them, when, and whether anyone can see or undo the result.

When you sort the market by that question, six setups fall out. Each puts a different party in charge of the truth. None of them is a party whose job is the truth.

Fig. 2. Six setups, six owners, and the evidence for where each breaks.

Setup 1: The vector store. Owner: nobody.

How it works. Every turn, document or tool result gets embedded. At query time, the top-k most similar chunks go into the prompt. It’s the default “long-term memory” in most framework tutorials, and it’s where most teams start.

Where it breaks. Similarity is not currency. “The API allows 100 requests a minute” and “The API now allows 500 requests a minute” are nearly the same vector. Ask about the rate limit and both come back. Whichever ranks higher wins, and usually both land in the prompt.

The TEPA authors put it precisely: stale evidence can remain highly relevant to the current query, giving similarity, recency and larger context only a weak signal that a fact has been superseded.

The evidence. In MemoryAgentBench, a UC San Diego benchmark built to test whether memory can revise itself when new evidence contradicts old, embedding-based retrieval agents scored 18–28% on single-hop updates and 4–7% when the update had to propagate through a second fact (Hu et al., arXiv:2507.05257). And Chroma’s context-rot study of 18 models found that even a single topically related distractor lowers accuracy (Chroma, 2025). A stale fact is the perfect distractor: same topic, wrong answer.

A vector store has no opinion about time. It has an opinion about cosine.

Setup 2: The write-time resolver. Owner: the writer.

How it works. On every write, an LLM extracts facts from the message, looks up similar memories, and emits an operation: add, update, delete or nothing. Mem0 made this pattern popular, and many homegrown systems copy it.

Where it breaks. The decision is made at the worst possible moment: with one message of context, inside a model call, and destructively. When the model misreads scope, it doesn’t warn you. It deletes.

In August, a developer published a reproducible case: two compatible preferences (“async feedback for design reviews” and “sync calls for incidents”) were collapsed into a contradiction, and the design-review preference was silently deleted (DEV Community). Nothing threw. The agent just started routing feedback wrong, weeks later.

The evidence. The strongest evidence comes from Mem0 itself. Its v3 platform replaced the two-pass extract-and-merge pipeline with a single ADD-only pass in which, in its own words, nothing is overwritten or deleted, and it reports gains of 20+ points on its benchmarks from the change (Mem0 migration guide). Credit to them for changing course. When the best-known proponent of a design walks away from it, take the hint.

Setup 3: Append-only with read-time ranking. Owner: the reader.

How it works. Keep everything. Old and new facts both persist, and retrieval ranking (similarity, recency, temporal cues) is supposed to surface the current one. This is where Mem0 v3 landed. It’s lossless, which is a real improvement over silent deletes.

Where it breaks. Append-only doesn’t resolve the contradiction. It moves it from the writer to the reader, and the reader is the worst possible owner: it meets the conflict mid-task, inside a token budget, with no authority to fix anything. Tomorrow it meets the same conflict again.

The evidence. This is the TEPA result from the top. In a controlled benchmark of 8,000 episodes, scored by a deterministic executor so it isolates the memory policy from any model’s quirks, success after a full reversal was:

• No memory: 0.309
• Append-only memory: 0.210
• Last-write-wins memory: 0.210
• Revocation (TEPA): 0.950

On a preference-reversal stream it was worse: append-only scored 0.138, against 0.837 for no memory at all (Zhou et al., arXiv:2608.07429).

What won was revocation, which the paper describes as removing the stale precedent from ordinary retrieval while keeping it available for audit. Remember that sentence. It is most of this article’s argument.

Fig. 3. When the facts reverse, memory that can’t revoke is worse than no memory. Data: TEPA, Table 2.

Setup 4: The temporal knowledge graph. Owner: the pipeline.

How it works. Messages become episodes. An LLM pipeline extracts entities and relationships into a graph, and every fact carries a validity window. When new information contradicts an old fact, the system invalidates the old one instead of deleting it. Zep and its open-source engine Graphiti are the reference design (Zep docs).

This is the most serious temporal model in the field, and invalidate, don’t delete is the right instinct. I want to be clear about that.

Where it breaks. Two places. First, the invalidation is still an automatic model judgment made inside an extraction pipeline. Nobody is asked, and a wrong extraction quietly becomes a wrong graph. Second, there is a gap between writing and knowing. Zep’s own docs say added data is processed asynchronously and can take a few seconds to a few minutes, that a 100-episode import often takes minutes, and that a processed flag doesn’t guarantee every episode succeeded (Zep docs). In a fleet, that’s the window in which agent B acts without what agent A just learned.

The evidence. In MemoryAgentBench’s selective-forgetting test, Zep scored 7% on single-hop updates and 3% on multi-hop. That run used GPT-4o-mini as the backbone and Zep has shipped a lot since, which is exactly why these tests should be rerun in public, by everyone.

Setup 5: The self-editing agent. Owner: the worker.

How it works. Memory lives in blocks pinned to the agent’s own context window, and the agent edits them through tool calls. This is the MemGPT idea, now Letta: a stateful agent is a system prompt, memory blocks, messages and tools, and the agent can modify its own memories (Letta docs).

Where it breaks. The worker is doing two jobs. Every memory edit spends the worker’s context and attention, which is the scarce resource context rot tells us to protect. Housekeeping only happens when the worker thinks of it, in the middle of something else. MemGPT scored 28% single-hop and 3% multi-hop on the same selective-forgetting test.

The evidence. The most telling evidence is what Letta built next: sleep-time agents, background agents that manage the primary agent’s memory blocks, triggered every five steps by default and still marked experimental (Letta docs). That is a memory agent in all but name. The team that invented self-editing memory concluded the worker shouldn’t do it alone. I take that as the strongest validation of this article’s argument.

Setup 6: The instruction file. Owner: you, at 11 p.m.

How it works. CLAUDE.md, AGENTS.md, Cursor rules, system prompts: hand-curated standing instructions loaded into every session.

This is honestly the most trustworthy memory most teams have. It’s explicit, reviewable and in git.

Where it breaks. It’s a human doing the memory agent’s job by hand. There’s one file per tool, so Claude Code and Cursor drift apart. Nothing in it carries confidence, provenance or an expiry date. It grows until it rots, and because it’s loaded in full every session, it rots inside every context window. And it never learns from anything your agents observe.

The tally

Count the owners: nobody, the writer, the reader, the pipeline, the worker, and you. Six setups, and not one puts the truth in the hands of something whose job is the truth.

The benchmark agrees. Across every method MemoryAgentBench tested (long-context models, BM25 and embedding retrieval, structured RAG, Mem0, Cognee, Zep, MemGPT and MIRIX), the best multi-hop selective-forgetting score was 7%. The authors’ conclusion is one line: “Selective Forgetting still poses a significant challenge to all memory mechanisms.”

LongMemEval, one of the benchmarks memory vendors quote most, lists knowledge updates and temporal reasoning among its five core abilities, and found commercial assistants and long-context models losing about 30% accuracy on long interactions (Wu et al., ICLR 2025). Retrieval is not the hard part. Revision is.

Fig. 4. Every method tested, including four commercial memory systems, scored 7% or less on multi-hop updates. Data: MemoryAgentBench, Table 3.

The logical conclusion

Lay the argument out plainly.

• Long-lived memory is a stream of decisions (keep, revise, retire, escalate, brief), not a container.
• A decision needs an owner with enough context, enough time, and the authority to act, plus someone to answer to.
• Every existing owner is missing at least one. The writer sees one message. The reader has no time and no authority. The pipeline answers to nobody. The worker is busy. You don’t scale. And “nobody” is not an owner.
• So the decisions need an owner whose only job is the memory estate: with its own clock, its own rules, an audit trail, bounded authority, and a way to escalate to a human.

Now look at what that owner does. It perceives (every write, every trace). It decides (type, confidence, conflict). It acts (retires, briefs, syncs). It answers to you. That is an agent by any definition you like. A layer can’t do any of it, because a layer has no goals and no clock.

That’s why “memory agent” isn’t branding. It’s the only shape the job fits.

Follow it all the way

If you actually believe that, some uncomfortable things follow.

• Worker agents lose the right to destroy memory. They can write and they can read. Retiring and resolving belong to the memory agent and to you. Separation of duties is old news in security; it’s new in memory.
• Retrieval accuracy is the wrong scoreboard. A system that finds the stale fact perfectly is perfectly wrong. Judge memory on behavior under change.
• Memory belongs to the fleet, not the tool. One memory estate, many agents, no per-tool notebooks.
• Memory learns from outcomes, not just conversations. Your traces and evals already know which lessons matter.
• You keep custody. Accountability needs inspection, and inspection needs the ability to read, export and leave.
• Agents should be able to hire their memory agent themselves. If memory is a colleague rather than a component, an agent ought to be able to sign up for one. More on that at the end.

The rest of this article is how we built Memanto to meet those obligations, written as a contract you can hold any memory system to.

Fig. 5. Worker agents write and read. The memory agent and you do the rest.

The Memory Agent Contract

Eight clauses. Each one comes with the evidence behind it, how Memanto meets it, and code you can run. Commands assume a local memanto serve on port 8000 and an active agent.

Clause 1: Nothing is destroyed silently

Why. Setup 2. A memory system that deletes on a model’s judgment will eventually delete something true, and you won’t hear about it.

How Memanto does it. A memory is either active or expired. There is no third state. Expiring a memory keeps its content and timestamps and writes three fields together: status, expired_at, and expired_by, which records why (a named policy rule, a retention entry, manual, or conflict-resolution). Restoring clears all three. Permanent deletion is a separate, explicit step that is off by default and never part of the nightly job.

bash# Retire a memory; the reason becomes its audit stamp
curl -X POST "http://localhost:8000/api/v2/agents/support-bot/memories/$MEMORY_ID/expire" \
  -H "X-Session-Token: $TOKEN" -H "Content-Type: application/json" \
  -d '{"reason": "superseded-by-rewrite"}'

# Changed your mind? Bring it back; the stamp is cleared
memanto memory restore $MEMORY_ID

Separation of duties, in practice. Memanto’s MCP server exposes seven tools by default: remember, batch_remember, recall, three time-based recalls, and answer. None of them deletes or retires anything. Agent-management tools stay off unless you set MEMANTO_EXPOSE_ADMIN=true. Your worker agents can learn and look things up; they can’t destroy.

Clause 2: Stale facts are revoked, not out-ranked

Why. Setup 3 and the TEPA result. Ranking can’t tell an agent that a fact has been superseded. Revocation can.

How Memanto does it. A fact leaves the active set in one of three ways: you resolve a conflict with an expire action, a policy rule matches it, or the writer expires it directly because it knows. Agent-facing recall can then exclude it, while audits still see it, labelled. That is the same design TEPA arrived at: out of ordinary retrieval, still available for audit.

Policies are per-agent YAML. This one is adapted from the built-in balanced preset, plus a rule of our own:

yaml# ~/.memanto/policies/support-bot.yaml
version: 1
retention:            # maximum age by memory type
  context: 7d
  event: 30d
  error: 30d
  observation: 60d
  commitment: 90d
  artifact: 180d
rules:                # evaluated in order; first match wins
  - name: pinned
    match: { tags: [pinned] }
    expire_after: never
  - name: unverified-voice-claims
    match: { source: [vapi], tags: [unverified] }
    expire_after: 7d
  - name: low-confidence-guesses
    match: { provenance: [inferred], confidence_below: 0.5 }
    expire_after: 14d
purge_expired_after: never   # the only destructive automatic step, off

Age counts from the last update, because an edit is evidence a memory is still alive. Types with no retention entry, like decisions and preferences, aren’t aged out by the table. Preview every sweep before it runs:

bashmemanto policy apply --dry-run

# What your agent should see: current facts only
memanto recall "public API rate limit" --active

# What an auditor sees: both, each labelled active or expired
memanto recall "public API rate limit"

One honest note: recall returns both states by default, clearly labelled. For agent-facing calls, pass --active on the CLI or "status": "active" on the REST API.

Clause 3: Contradictions are escalated, not guessed

Why. The best multi-hop selective-forgetting score in MemoryAgentBench was 7%. Models are not yet good at settling contradictions alone, and a confident wrong settlement is worse than an open question.

How Memanto does it. A conflict-detection pass reads a day’s memories, finds pairs that contradict each other, and writes a report. Each conflict has an index, a title, and the IDs of the old and new memory. Memanto recommends the newer memory when that’s the likely answer, but it never applies a resolution on its own. You resolve from the CLI, side by side in the dashboard, or through the API:

bashmemanto detect-conflicts --agent support-bot      # writes the day's report

curl "http://localhost:8000/api/v2/agents/support-bot/conflicts?date=2026-10-15" \
  -H "X-Session-Token: $TOKEN"

curl -X POST "http://localhost:8000/api/v2/agents/support-bot/conflicts/resolve" \
  -H "X-Session-Token: $TOKEN" -H "Content-Type: application/json" \
  -d '{"date": "2026-10-15", "conflict_index": 0, "action": "expire_old"}'

There are eight actions. Four are reversible: expire_old, expire_new, expire_both and keep_both. Four delete: keep_old, keep_new, remove_both and manual (which replaces both with text you write). Use the expire actions unless you mean it.

Clause 4: Every memory has a chain of custody

Why. Memory is an attack surface. MINJA showed that an attacker who can only send ordinary queries can plant malicious records in an agent’s memory, with a 98.2% average injection success rate and a 76.8% attack success rate across the agents tested (Dong et al., arXiv:2503.03704). OWASP’s Top 10 for Agentic Applications (December 2025) lists Memory & Context Poisoning as ASI06 (summary). An unlabelled vector can’t tell you where it came from.

How Memanto does it. Every memory carries its custody with it: a type, a confidence score from 0 to 1, a provenance (explicit_statement, inferred, corrected, validated, observed or imported), a source (the user, an agent, or the named tool that wrote it), tags, a status and timestamps. Attribution never guesses. If Memanto can’t identify the calling tool, it records the call as unidentified, because a wrong label is worse than none.

In practice, untrusted channels write with low confidence, and agents read above a threshold:

bash# A claim from a phone caller enters as a low-confidence, tagged observation
memanto remember "Caller says admins can skip 2FA from the reset link" \
  --type observation --confidence 0.3 --source vapi --tags unverified
# Agent-facing recall ignores anything below 0.7
memanto recall "how do admins reset 2FA?" --active --min-confidence 0.7

The unverified-voice-claims rule from Clause 2 then retires it at the first nightly sweep after seven days, unless someone checks the claim and removes the tag. Underneath, the hardening is specific: conversation extraction drops secrets and tokens; since v0.2.29, tags that start with # or match known injection phrases are rejected, and closing-tag tricks in extraction are neutralized. In the Vapi integration, caller memory is keyed by an HMAC of the phone number, and the server, not the model, identifies the caller, so a prompt injection can’t reach another caller’s memories.

None of this makes poisoning impossible. It makes poisoned memory labelled, filterable and reversible, which is the most any honest system can promise.

Fig. 6. The chain of custody every Memanto memory carries. Values are illustrative.

Clause 5: Memory work runs on its own clock

Why. Setup 5. A worker that tends its own memory does it mid-task, with borrowed attention, and only when it remembers to. Letta’s move to sleep-time agents says the same thing.

How Memanto does it. One command sets up a nightly job that runs three steps in order: a written summary of the day’s memories, the conflict-detection pass, then an expiry sweep under each agent’s policy. Purging is never part of it.

bash$ memanto schedule enable
What time should daily summaries run? (HH:MM in 24-hour format, UTC): 23:30
✓ Daily summaries enabled
  Time:     23:30 UTC
  Agent:    support-bot

The Langfuse handler in Clause 7 works the same way: it runs on a background thread, off your hot path, and swallows its own errors so a failed write can never break your app.

The write path, though, is not deferred. New memories are searchable in under a second, with no indexing step and no event to poll. Compare Zep’s asynchronous processing of seconds to minutes, or Mem0 v3, where add() returns an event ID you poll for completion. Housekeeping belongs off the hot path. Knowing what a teammate just learned doesn’t.

Clause 6: Agents get briefs, not dumps

Why. Chroma’s context-rot study found model performance grows increasingly unreliable as input grows, and that even one distractor hurts. Top-k retrieval is a machine for producing distractors.

How Memanto does it. The design principle is queryable, not injectable: agents ask memory for what they need, when they need it. answer returns a written answer grounded in the agent’s memories. In Claude Code, a memory-scout subagent runs several recalls in parallel and returns a short, sourced brief, and it surfaces contradictions instead of quietly picking a winner. When you do want raw memories, ask narrowly by type, tags, similarity, confidence and status.

pythonfrom memanto import Memanto

memanto = Memanto(agent_id="support-bot")

# A brief: one grounded answer instead of twenty snippets
brief = memanto.answer("What should I know before replying to Dana today?")

# Raw memories, asked for narrowly
hits = memanto.recall("Dana's team and approver",
                      type=["fact", "relationship"], limit=5)

Where an up-front briefing is right, as at the start of a voice call, it’s bounded. The Vapi integration hands the assistant at most 10 recent and 10 relevant memories per section, capped at 4,000 characters.

Clause 7: Outcomes feed memory

Why. A 2025 study of agent memory found that agents strongly copy similar past records, so “inaccuracies in past experiences compound and degrade future performance.” Being selective about what enters memory raised one medical agent’s score from 16.75 to 38.50. Pruning by later outcomes shrank its memory from 1,012 records to 248 with performance held. The authors’ conclusion: “future task evaluations can serve as free quality labels for stored memory” (Xiong et al., arXiv:2505.16067).

How Memanto does it. Your observability stack already knows which lessons matter. Memanto reads Langfuse traces and turns errors into error memories, latency and cost outliers into observations, and failed or passed evals into learnings.

Failures are grouped by signature: the operation name plus the message with IDs, numbers, emails, IP addresses, paths and quoted strings replaced by placeholders. Grouping and scoring are rule-based, with no LLM calls. Confidence grows with recurrence, as min(0.95, 0.60 + 0.15 × log10(occurrences)), so one occurrence scores 0.60 and a hundred score 0.90. A ledger makes it idempotent: a recurring failure updates its memory in place, and re-running never duplicates. In the docs’ own example, 812 observations became 2 memories.

python# pip install langfuse-memanto
from langfuse import Langfuse
from langfuse_memanto import attach

Langfuse()                                  # your existing setup
attach(agent_id="checkout-agent",           # start capturing
       capture=["errors", "slow"], latency_ms=5000)

Failed evals sync from the CLI with your own pass/fail rules:

bashmemanto migrate langfuse --discover
memanto migrate langfuse --capture errors,low-score --score-fail 'correctness<0.7' --save
memanto migrate langfuse --dry-run
memanto migrate langfuse

Fig. 7. Outcomes feed memory. The two signatures and their split are illustrative; the 812-to-2 example and the confidence formula are from Memanto’s docs.

Clause 8: One estate for the fleet, and you keep custody

Why. Setup 6. Per-tool notebooks drift apart, and memory you can’t inspect or take with you isn’t accountable to you.

How Memanto does it. One memory estate serves every agent you run. memanto connect wires up 14 coding agents with one command each, including Claude Code, Cursor, Codex CLI, Gemini CLI, GitHub Copilot and Windsurf. The MCP server covers any other MCP client. There are SDKs for Python, TypeScript and Go, and integrations for LangGraph, CrewAI, Google ADK, Amazon Bedrock AgentCore, Pydantic AI, NVIDIA NeMo Agent Toolkit and more.

Instruction files stop drifting because Memanto keeps them current. memanto memory sync writes each agent’s active, high-confidence (0.8 and above) instructions, preferences and goals into every connected tool’s own file, between markers, and touches nothing outside them:

markdown<!-- MEMANTO-DYNAMIC-MEMORIES -->
- [INSTRUCTION] New services use PostgreSQL 16. Never scaffold MongoDB.
- [PREFERENCE] Small PRs with tests over large refactors.
- [GOAL] Public API p95 latency under 200 ms by end of Q4.
<!-- /MEMANTO-DYNAMIC-MEMORIES -->

Isolation is enforced, not assumed. In the LangGraph integration each namespace is bound to one Memanto agent, and a second namespace that maps to the same agent raises an error instead of quietly sharing memories. With strict_namespace_binding=True, agents created before binding existed are refused too, because they can’t prove which namespace they belong to.

Custody runs both ways. Your estate exports as Markdown or as an Open Knowledge Format bundle: a folder of Markdown files with YAML front matter, organized by type, with confidence and provenance intact. Coming in, memanto migrate imports from Mem0, Letta, Supermemory, Zep, Hindsight and OKF. A dry run writes nothing; it builds a report from your actual data (how many records, how they map onto Memanto’s types, and for Mem0, Letta and Supermemory sources, the expected savings) so you decide whether to continue with real numbers in front of you.

bashmemanto connect multi          # pick Claude Code, Cursor, Codex and the rest
memanto memory sync            # push standing rules into each tool's file
memanto memory export --okf    # the whole estate, as Markdown + YAML
memanto migrate mem0 --dry-run # a report built from your data; nothing written

One reversal, end to end

Here is the whole contract on one ordinary change. A platform team runs Claude Code and Cursor against one shared Memanto agent, platform-team, with the nightly job set for 23:30 UTC. All times are UTC.

Monday 12 Oct, 10:02. In Claude Code, the agent records a fact. The source is detected automatically as claude-code.

bashmemanto remember "Public API rate limit is 100 requests per minute" --type fact

Thursday 15 Oct, 16:40. A config change ships. In Cursor, the agent records the new value, and it’s searchable in under a second.

bashmemanto remember "Public API rate limit raised to 500 requests per minute" --type fact

For now, both facts are active. That’s honest: nobody has decided anything yet. An agent that recalls the rate limit sees both, and Claude Code’s memory scout reports the contradiction instead of picking a winner.

Thursday, 23:30. The nightly job writes the day’s summary, runs conflict detection, and flags the pair: conflict 0, a contradiction between the Monday fact and the Thursday fact. Nothing changes yet.

Friday 16 Oct, 09:10. You open the conflict in the dashboard, old and new side by side, and choose expire old, keep new. The Monday fact is now expired, stamped expired_by: conflict-resolution. It isn’t gone.

Friday, 09:11. Every agent in the fleet sees one current fact:

bashmemanto recall "public API rate limit" --active     # → 500 only

The following Monday. An incident review asks what the agents could have known on Wednesday the 14th:

bashmemanto recall --as-of 2026-10-14 --type fact       # → 100, shown as active

The answer is 100, shown as active, because that is what memory said on Wednesday. Nothing was overwritten, so history can be reconstructed exactly.

If sixteen and a half hours with both facts active is too long for your case, you have three levers: run memanto detect-conflicts on demand after important writes, call the conflict-report endpoint from your pipeline, or have the writer expire the old fact directly when it knows it’s replacing one.

Fig. 8. The reversal walkthrough on one timeline.

The Memory Agent Test

If retrieval accuracy is the wrong scoreboard, here’s a better one. Eight tests, an afternoon, any memory system. Run them on whatever you use today. Run them on Memanto.

• Reversal. Store a fact, then its replacement. Pass: agent-facing recall returns only the current fact, without you re-ranking anything. Harder: change a fact that another answer depends on (Dana moves to marketing; who approves her expenses now?). Pass only if the dependent answer changes too.
• Silence. Store two similar but compatible preferences, like async feedback for design reviews and sync calls for incidents. Pass: neither disappears without someone being told.
• Undo. Retire a memory by mistake. Pass: you get it back, history intact.
• Time travel. Pass: you can ask what memory said at a past moment and get that answer, not today’s.
• Custody. Pick any memory. Pass: you can see who wrote it, whether it was stated or inferred, and how sure the system is.
• Poison. Send a false claim through an untrusted channel. Pass: it doesn’t enter as a full-confidence fact, and you can find and retire everything that channel wrote.
• Read-after-write. Write from one tool, read from another a second later. Pass: it’s there.
• Exit. Export everything in an open format and import it somewhere else. Pass: confidence and provenance survive the trip.

Memanto was designed to pass all eight, and the commands in this article are how you check. Two caveats from our side. Reversal depends on a conflict being resolved, a policy matching, or a writer expiring the old fact, so by default there’s a window until the nightly scan. And we have not yet proven the harder, multi-hop version.

Our own evidence gap

I’ve asked a lot of evidence from everyone else, so here is ours. Memanto has not yet been run on MemoryAgentBench’s selective-forgetting tasks or on a TEPA-style reversal stream. Our paper reports results on LongMemEval and LoCoMo, including 93.6% on LongMemEval’s knowledge-update questions (arXiv:2604.22085). But those questions test whether a system can return a fact’s latest value, which is a narrower test than revising everything that depends on it.

So here’s our commitment: we’ll run Memanto on both and publish the results, whatever they show. If it fails, you’ll read it from us first. And I’d like to see Mem0, Zep, Letta, Supermemory and Cognee do the same, on the same harness, in public. The field will get better faster if we’re all graded on the hard part.

Fig. 9. The Memory Agent Test. Share it, run it, publish what you find.

What to know before you adopt it

• It’s young and moves fast. v0.2.30 shipped on October 23, and recent releases carried breaking changes (memanto-mcp’s remember and batch_remember now require type, confidence and provenance, for example). Pin a version and read the changelog.
• Conflict detection is a batch pass, not a per-write check. See the three levers in the walkthrough if you need a shorter window.
• Recall includes retired memories by default, labelled. Use --active or "status": "active" for anything an agent will act on.
• Some actions are destructive by design. Four of the eight conflict actions delete, and adopting a policy preset replaces your whole policy, including rules you wrote.
• Cloud and on-prem keep separate agent registries. To move between them, export to OKF and import on the other side.
• It’s not an agent runtime. If you want memory built into the runtime your agents live in, Letta’s sleep-time agents are a legitimate design. Memanto is for teams who keep the agents and frameworks they already have and want one memory agent across all of them.

The end of the argument

Follow the logic one step further. If memory is a job, and the job belongs to an agent, then an agent should be able to hire that agent itself.

That’s where we’re going next. In the next few weeks we’re releasing Memanto Cloud: a one-line install, and the ability for an AI agent to sign itself up and set up its own long-term memory, with no keys to wire and no backend to run. So many of you asked for it in the survey on memanto.ai that it jumped to the top of our list. Stay tuned.

For two years we’ve measured agents by what they can do inside one context window. The next stretch will be measured by what they carry forward, and by whether what they carry forward is still true.

That isn’t a retrieval problem. It’s a job: keep, revise, retire, escalate, brief. Give it to something whose only job it is, hold it to a contract you can test, and memory stops being the thing that quietly makes agents worse. It becomes the thing that makes them a little better every week.

The pieces are here. The research is pointing the same way, our competitors’ recent designs are converging on it, and every team that gives its agents a memory worth trusting moves the whole field a step closer.

“Your agents focus. Memanto remembers.

Docs · GitHub · Discord · r/Memanto

Sources

Research

• Zhou, Ouyang, Zheng and Xiang. TEPA: Revoking Stale Memories for Conflict-Robust Language Agents. arXiv:2608.07429, August 2026.
• Hu, Wang and McAuley. Evaluating Memory in LLM Agents via Incremental Multi-Turn Interactions (MemoryAgentBench). arXiv:2507.05257.
• Xiong et al. How Memory Management Impacts LLM Agents: An Empirical Study of Experience-Following Behavior. arXiv:2505.16067.
• Dong et al. A Practical Memory Injection Attack against LLM Agents (MINJA). arXiv:2503.03704.
• Hong, Troynikov and Huber. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma, July 2025.
• Wu et al. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. ICLR 2025.
• Abtahi et al. Memanto: Typed Semantic Memory with Information-Theoretic Retrieval for Long-Horizon Agents. arXiv:2604.22085, April 2026.
• OWASP Top 10 for Agentic Applications, summarized by AHEAD. December 2025.

Vendor documentation

• Mem0: Platform v2 to v3 migration
• Zep: Facts and Check data ingestion status
• Letta: Stateful agents and Sleep-time agents
• Memanto documentation and changelog

Other

• Mukesh. Mem0 auto-resolves memory conflicts for you, until it silently deletes one you still need. DEV Community, August 2026.