Before an agent remembers for you, make it forget on purpose

The support agent tells the customer, helpfully and with a citation, that the card on file is the Amex ending 4022.

The Amex was cancelled in April. The customer called in May to put a Visa on the account, and a human updated the billing record while they were on the phone. But the agent's memory of "preferred card: Amex 4022" was written back when it was true, tagged with a source, and never told otherwise. So it surfaces, confidently, three months later, on a refund the customer is now watching happen to a card that no longer exists.

Nothing broke. Recall worked perfectly. The agent retrieved exactly what it had stored, returned it fast, and showed its work. That is the part that should make you uncomfortable. A memory system doing its job is not the same as a memory system being safe, and the gap between those two is where a customer-facing agent quietly goes wrong.

What a memory bounty is actually testing

The reason this scene is worth dwelling on right now is that "give your agent persistent memory" stopped being a research project and became a package you install.

Memanto is one of the visible ones. It bills itself, in the repo's own words, as "Memory that AI Agents Love!" — a companion memory layer for Claude Code, Cursor, Codex, and a list of other agents. It runs fully local with no account and no API key, or in the cloud, and it exposes the lifecycle as plain commands: memanto remember, memanto recall, memanto answer, memanto edit, memanto forget, memanto upload, plus a daily-summary and a conflicts view. MIT-licensed, created in March, and moving fast enough to be pushing changes the same week I am writing this. The important shift is not Memanto specifically. It is that the memory layer is now a dependency you add, the way you would add a database, and people are starting to operate it like one.

Which is why the more interesting artifact is not the README. On June 24 the maintainers opened an issue titled, exactly, [BOUNTY $100] The Memanto Bug & Exploit Challenge. The body explains that a previous bounty asked the community to benchmark Memanto against the competition, and this one asks engineers and red-teamers to do the opposite job: break memory management. The named scope is worth reading slowly, because it is a list of the ways memory fails — memory integrity, context window stability, retrieval accuracy, logic loops, memory inconsistencies, and security vulnerabilities. The issue quickly drew submissions.

Read that bounty scope again and notice what it is not. It is not "can the agent remember." Everyone already knows it can. It is "what happens to the work when the remembering goes wrong." That is the question a team adopting persistent memory has to answer for themselves, and a public bounty is just the loud version of a drill every operator should run privately first.

"Recall worked" answers the wrong question

A successful recall proves the agent found a stored fact and returned it. It does not prove the fact is true now, that it belongs to this customer, that it was extracted confidently, or that nothing else on the record contradicts it.

Watch how those come apart in the bounty thread, because the submissions are basically a field guide to memory misfires:

• Stale-but-valid-yesterday. One submission (PR #823, reported in the thread) describes a time-travel query, search_as_of, dropping memories that expired today even when they were valid at the historical timestamp the caller actually asked about. Freshness logic is subtle: "expired now" and "expired as of the date in question" are different facts, and conflating them is how you either leak a dead fact or hide a live one.
• Low-confidence, dressed as fact. Another (PR #801, reported in the thread) reports that numeric min_confidence thresholds were being translated into categorical keywords the stored memories did not actually use — so memories the caller meant to filter out by confidence could slip back in. A confidence threshold that does not bite is not a threshold.
• Cross-agent and session bleed. The boundary between whose memory is whose is its own failure surface. The merged PR #820, "Fix session mismatch status codes," shows at least one session-and-authorization behavior moving through maintainer review. Separately, a batch of security submissions in the thread (this comment) tested path traversal, unauthenticated UI endpoints, reflected-origin CORS, and arbitrary file write — the plumbing failures that decide whether a memory store can be read or written by something that should never touch it.

A fair caveat, and it matters: most of those pull requests were open and unmerged when I looked. Treat them as submissions that allege and reproduce behavior, not as adjudicated facts about the shipping product. The confirmed signal is the v0.2.4 release on June 26, which ships an official TypeScript SDK, lifecycle hooks, a memanto edit command, v2 memory response models, and — in the maintainers' own release notes — security hardening that names cross-agent authorization, upload path traversal, and secret leakage in the UI config endpoint. The previous v0.2.3 release had already added provenance metadata across the recall path, dry_run candidates that propose memories without persisting them, and prompt-level exclusion of secrets and API keys. The current package is on PyPI at 0.2.4.

So the tool is hardening in public, which is the good version of this story. But notice the shape of every misfire above. None of them is "the agent couldn't remember." Every one is "the agent remembered, and the remembering was wrong in a way that recall alone will never catch." That failure class is the one your own workflow inherits the day you turn memory on.

The memory misfire drill

So here is the artifact. Not a governance checklist, and not a security audit. A short drill you run against one workflow before its memory is allowed to drive a real customer interaction. You take a single remembered fact — a real one, the kind your agent would actually store — and you walk it through the ways memory goes bad on purpose, before it does it by accident.

Run one fact down this column. Each row is a way the fact can be true and still wrong.

Scroll sideways to see all 3 columns.

Drill row	The misfire it catches	What to write down before you trust the recall
Remembered fact	The thing itself, stated plainly	The exact fact as the agent would surface it to a customer or a colleague, in its own words. If you can't write it in one sentence, the agent shouldn't be storing it.
Source	A fact with no traceable origin	Where this came from — a specific message, document, or human edit — captured as provenance, not as a vibe. A fact you can't trace is a fact you can't defend or delete cleanly.
Scope	Wrong customer, wrong project, wrong account	Whose fact this is: the customer, account, or project it belongs to, and an explicit rule that it never surfaces outside that scope. One namespace per blast radius.
Freshness	True yesterday, dangerous today	A valid-until date or a superseded-by rule, and the behavior when a fact is asked for "as of" a past date versus now. Decide what happens to a fact that was valid then and is expired now.
Confidence	A guess wearing a fact's clothes	The minimum confidence required for this fact to be recalled at all, and proof the threshold actually filters — that a low-confidence extraction stays out instead of slipping back in.
Contradiction	Two true-looking facts that disagree	A worked example of the conflicting fact (cancelled card vs. card on file) and the rule for which one wins. Newest? Highest-confidence? Human-edited? Pick, and write it down.
Boundary	One agent reading another's memory	The cross-agent and cross-session line: which agent or session may read this, which may not, and what the system returns when the wrong one asks.
Edit and delete	A wrong memory you can't take back	The exact route to correct or remove this fact — the edit and forget equivalent for your stack — and who can run it under pressure, fast, without a redeploy.
Pass or fail	"It recalled" mistaken for "it's right"	The single rule that decides whether this fact is safe to use: not "the agent returned something," but "the agent returned the right fact, in scope, fresh, above threshold, with no live contradiction."

The two rows that catch people are Freshness and Contradiction.

Freshness, because a stored fact does not announce that it has gone stale — it was true when written, it carries a source, and it looks exactly as trustworthy as a fact that is still correct. Contradiction, because the dangerous case is not a blank record, it is a record holding two confident facts that disagree, where recall happily returns the older one because nothing told it the account moved on.

This is the memory cousin of an idea I keep coming back to: an agent needs a durable state ledger before you give it more context, and memory changes should leave receipts you can read later. The drill is where those two meet. It turns "the agent remembers" into a fact you can interrogate one row at a time.

Why this is now an operations primitive

What changed is not that agents got smarter. It is that their memory got durable, and durable memory is an operational surface, not a feature.

A stateless agent forgets honestly. Every run, it starts from the conversation in front of it, and if it needs a customer's preference, it has to look it up or ask. That lookup is a checkpoint — a moment where the current truth gets fetched fresh. Persistent memory removes that checkpoint by design. That is the entire value proposition, and it is a real one: the agent stops asking the same question twice. But the moment you remove the fetch-fresh checkpoint, you have taken on responsibility for the thing the checkpoint used to do, which is make sure the fact is still true before acting on it.

The maintainers building these tools clearly see it. A bounty that explicitly scopes "memory integrity" and "memory inconsistencies" alongside the usual security vulnerabilities is a team that expects this to run in production and wants the failure modes surfaced while they are still cheap. Provenance metadata, dry_run candidates that propose without persisting, an edit command, a conflicts view, confidence thresholds, time-travel queries — those are not memory features, those are memory controls. They exist because someone realized that storing a fact and trusting a fact are different operations that need different gates.

That lesson holds even if you never touch Memanto. Whatever stack you use, the day you turn on persistent memory you have added a system that can be confidently wrong, and recall metrics will not warn you. The AI workflow controls worth having are the ones that make freshness, scope, and contradiction into steps the agent passes through, not assumptions it carries. The same instinct shows up in how you should eval the workflow and its evidence, not just the model's answer — because "the model recalled the right-looking thing" is exactly the test that passes while the customer gets the wrong card.

None of this is a knock on persistent memory, or on the tools shipping it in the open. Building this in public, with a bounty inviting people to break it, is the responsible version. What lands narrower, and on you: the agent will remember whatever you let it, for as long as you let it, and it will sound just as sure about a dead fact as a live one. Making it forget on purpose — on a schedule, on contradiction, on command — is the part nobody else can do for you.

Your next move

Take one workflow where an agent already remembers something about a customer, an account, a project, or a support history. The real one. Pick a single fact it would store, and run that fact down the nine rows above before its memory drives another live interaction.

You do not need all nine perfect to start. You need to know which rows are blank. The AI workflow security review worksheet covers the adjacent ground for sensitive-memory and source-access boundaries, and the AI workflow controls page shows where the drill sits in a larger process.

If a row comes up empty and you want a second set of eyes, bring one workflow and we will run the memory misfire drill with you — mapping memory scope, the freshness and supersede rules, the confidence threshold, the cross-agent boundary, and the edit and delete route before recall touches a real customer. That is also how we scope process automation: get the forgetting right first, then let the agent remember.