Does a corrected memory stay corrected?

When a decision changes, an agent with memory has two jobs: learn the new answer, and stop using the old one. The second job is the one that fails quietly. An agent that recalls last month's rule as confidently as today's will act on it.

In September 2026, researchers published a study of exactly this failure: Revoked but Still Authoritative: An Empirical Study of Revocation Enforcement in Agent-Memory Systems (Shen, Toyoda and Leung). They loaded five memory systems (Graphiti, Zep, mem0, LangMem and cognee) with a policy, then revoked it and stored its replacement. Then they checked whether the revoked policy came back at retrieval time. In their words, "the revoked fact is returned wherever the revocation label is visible to the retrieval layer, outranks its replacement, and leads agents to the unsafe action." When the revocation was entered explicitly, mem0's default setup filtered the revoked record out, and LangMem and cognee deleted it outright. But when each system had to work the revocation out from plain text itself, none of the five recorded or enforced it.

The authors released their harness as open source (VulcanLab/Memory-Rebirth-Attack, Apache-2.0). Kijito wasn't in the study, so we ran the harness's nine situations against Kijito ourselves, using its adapter protocol and its own check for a revoked fact.

What we ran

• The harness's nine situations, unchanged: a deploy approval, a PII export, a backup deletion, an over-limit transfer, an MFA waiver and four more. In each one an old policy (v1) is revoked and replaced by a new one (v2).
• Three ways an agent revokes a memory in Kijito: correct (the old memory is kept, marked believed-false and linked to its replacement), fade (retired as no longer relevant, without being marked wrong) and an in-place update (the old text is overwritten, so no history is kept).
• One question per situation: after the revocation, does a normal recall bring v1 back?
• Retrieval only. No model was in the loop, so this measures what an agent would be handed, not what it would then do. We ran it on a local copy of Kijito with throwaway accounts, never production: first the engine as it was on 6 October, then the same engine with the fix described below.

What we found

After correct, fade or update, the revoked policy never came back: 0 of 9 situations for each method. The replacement ranked first every time.

That puts Kijito alongside the systems in the study that delete revoked records, with one difference: correct doesn't delete anything. The corrected memory stays in your account, marked believed-false and linked to its fix, so you can open it in the web app and see what changed and when. It just stops coming back in recall, for every agent on your account.

What we found that wasn't fine, and fixed

The study's authors note, in their harness's documentation, that a status filter at the store works "until the mark is hidden or laundered away". So we went looking for ways around ours, and found two.

• Merging a live memory into a corrected one.
• Raising one of a corrected memory's saved history versions.

In both cases the corrected policy came back into recall in all nine situations: through a saved copy of its text for history versions, and for merges in one situation straight away and in all nine once the server restarted. Each took a deliberate call on a corrected memory, though an agent tidying up its memories could plausibly make the merge one.

We closed both. Kijito now refuses to merge into a corrected memory, and saved versions of a corrected memory now carry the same believed-false mark, so raising one is refused too, unless someone deliberately restores it. After the fix, all nine stayed out of recall, including after a restart. The fix went live on kijito.ai on October 8, 2026.

What Kijito doesn't do yet

All of this depends on a revocation actually happening. If two contradicting memories are saved and nobody calls correct, Kijito keeps both, and recall returns both in all nine situations, with the old one ranked first in seven of the nine. With default settings, Kijito flagged none of these nine contradictions, and it never retires a contradicted memory on its own. An experimental detector, off by default, caught 4 of the 9 pairs when we switched it on, and it flagged unrelated memories too (partly because all of our test projects shared one account). Until that changes, the correction is your agent's job, or yours.

Limits of this test

• It was our run, through our own runner and adapter. The situations and the revocation check are the study authors'; the run is not an independent audit.
• Retrieval only, one run per engine build, nine situations, on a local engine rather than production.
• The study measured more than this, including whether agents act on what they retrieve. We tested only the retrieval step, which is where memory systems differ.

What this means if you use Kijito

When your agent corrects a memory, the old answer stops coming back, for every agent, and the correction keeps the history. If a decision changes and nobody corrects it, both versions stay in play. So tell your agents to correct, not just add.

You can watch a corrected decision stay out of recall, without signing up, at kijito.ai/demo.

Kijito is built by Arcada.