What I Believed Last Tuesday: ENGRAM Learns to Change Its Mind

A memory system that cannot change its mind is an archive. One that changes its mind by overwriting is a liability. The interesting question was never how a fact gets updated — it is what happens to the belief you stopped holding.

Two ways to be wrong about the past

Facts change. The deployment target moves from staging to production. A token budget doubles. A decision made in March is reversed in July. Any memory layer that runs longer than a single session will eventually hold something it no longer believes, and the design question is what it does about that.

There are two conventional answers, and both of them cost you something.

The first is to append. Write the new fact alongside the old one and let ranking sort it out — recency weighting, importance decay, whatever the retrieval stack offers. This never quite works, because ranking is a soft preference and truth is not. The stale fact stays retrievable. It comes back on the wrong query, or the right query on a bad day, and the agent acts on a value that has not been correct for weeks. Down-ranking a falsehood is not the same as retiring it.

The second is to overwrite. Edit the note in place, so the current value always wins. This solves recall and destroys history. You lose the ability to ask why an agent did something in June, because the belief it acted on no longer exists anywhere. For a system whose whole proposition is governed, auditable memory, that is not a small loss.

ENGRAM was in the first camp, and I should be plain about it. Two memories asserting flatly contradictory facts about the same entity would both persist, and both stayed recallable. Nothing detected the conflict. Nothing retired anything. The store accreted contradictions quietly, and the reader was expected to notice.

What this release addresses is not a retrieval-quality problem. It is belief revision, which is a different discipline with different requirements: detect the conflict at write time, make the current value win at recall, lose nothing, and propagate the consequences.

Supersede, don’t delete

“Supersession, concretely”

A correction does not edit a memory. It mints a new one.

The winning belief becomes a new :Memory node. The losing belief is flipped to status='superseded', stamped with a valid_until timestamp, and receives an incoming SUPERSEDES edge pointing back from its successor. The head of any chain is the node with nothing pointing at it. Nothing is mutated, nothing is removed.

If that shape sounds familiar, it should. It is exactly the version chain that ENGRAM articles have used since long before any of this: revise an article and you get a new :Article linked to its predecessor, never an edit in place. The whole of this feature is that pattern extended one level down, from artifacts to beliefs.

That inheritance paid for itself in an unexpected place. Recall in ENGRAM has always filtered to memories that are active — the mechanism that lets a suggested memory sit in an inbox without polluting retrieval. A newly retired belief is not active. So the moment superseded and retracted joined the status vocabulary, every read path in the system excluded them, correctly, with no change to the recall predicate at all. Ten separate query paths, including every cross-user sharing variant, needed exactly zero edits. The retrieval half of belief revision cost nothing, because the seam was already there.

The expensive half was deciding when a belief should be retired, and by whom.

Three ways a belief changes

“The triggers, concretely.”

Deliberately. You call revise with a memory id and the corrected content, and ENGRAM derives a new belief from it — extracting and resolving entities exactly as it would for a fresh memory, never a raw text edit of the old node. forget retires a belief without a successor: no SUPERSEDES edge, no model call, nothing to reason about, just a retraction that keeps the content for audit. revert undoes either one.

By inference. This is the one that matters. You do not have to tell ENGRAM that a fact changed. Write the new reality as an ordinary note, in the flow of work, with no hint that it conflicts with anything:

remember(content="The deployment target for checkout-service agents is production.",
         scope="long_term")

Within seconds ENGRAM embeds the new belief, searches its near neighbours for candidates that share entities with it, puts the pair to an entailment check, and — finding a direct contradiction at high confidence — retires the belief that said staging. No verb. No inbox entry. No human step.

Deterministically. Revise a knowledge-base article and the memory imprinted from the old version is superseded by the memory imprinted from the new one. Nothing is inferred here and no model is consulted; the version bump is authoritative on its own. Your articles and your beliefs about them stay in lock-step by construction.

Those two history views are worth reading side by side. They are the same supersede-don’t-delete machinery arriving by two entirely different routes, and the interface tells you which one made the call — down to the confidence it had when it made it.

Who is allowed to retire a belief

“Governance, concretely.”

The design decision I am most pleased with is the separation of two questions that most systems conflate.

The category decides whether anything is superseded at all. When the detector compares two beliefs, the entailment check returns one of four verdicts: contradiction, paraphrase, refinement, or unrelated. Only a contradiction retires anything. A paraphrase never supersedes, at any confidence whatsoever. Neither does a refinement, today. This is the load-bearing gate, and it is categorical rather than numeric on purpose — the question “are these two beliefs actually in conflict?” is not the sort of thing a threshold answers well.

Confidence only decides who applies it. Within the supersede-eligible category, the score routes the decision to a tier:

• High confidence auto-applies. The bar sits at 0.7 by default, which is deliberately lower than the equivalent gate elsewhere in ENGRAM, for a reason I will come to.
• The middle band goes to a judge. A system-side model (running on Anthropic directly, never on whichever model the user has configured) rules on the supersession. Control gates in ENGRAM never depend on a user’s model choice, and this is one.
• Everything else goes to a human. The contradiction surfaces in the review inbox with both beliefs side by side and the confidence attached, and someone approves or dismisses it.

Underneath all three tiers sits a single invariant, and it is the one I would defend hardest: a check that did not run must never retire a belief.

If the entailment call errors, or the judge cannot reach its model, or the response comes back unparseable, ENGRAM does not guess and does not proceed. It holds the contradiction as pending, softly down-weights the older belief at recall without hard-filtering it, and leaves the current active belief exactly where it is. A background worker rescans the held contradictions and resolves them when the service recovers. Fail-closed in most systems means don’t admit; here it means don’t mutate, which points the caution in a different direction than usual, and the right one.

When two beliefs genuinely do conflict and both carry timestamps, the newer one wins by default. Temporal arbitration handles the ordinary case without consulting a model at all; the entailment check earns its cost on the ambiguous and with no timestamp.

One more constraint, easy to state and important: correction is owner-only. A colleague who has been granted one of your memories can recall it, but can never revise or forget it. Sharing passes recall, not authority.

What licenses trusting the automatic tier

It is worth pausing on why a 0.7 bar for automatic retirement is defensible at all, because on its face it looks reckless.

It is defensible because the operation is non-lossy. Nothing is destroyed, so nothing is unrecoverable, so a wrong decision is one call from being undone. revert restores a retired belief: status back to active, the supersession edge dropped, the validity stamp cleared, content and provenance intact.

That is not a convenience feature bolted on afterwards. It is the safety property that makes the automatic tier reasonable in the first place. If retirement were destructive, no confidence score would be high enough to justify applying it without review. Because retirement is reversible, a bounded blast radius replaces a perfect judgement as the thing you need.

What you believed last Tuesday

“Point-in-time, concretely.”

Every version of every belief carries validity bounds — valid_from when it became current, valid_until when it stopped. Which means the past is not merely preserved, it is queryable. The same question returns different answers depending on when you ask it to be answered.

as_of = 2026-07-22T00:52:00Z   →   100k · staging
as_of = 2026-07-22T00:57:00Z   →   250k · staging
as_of = now                    →   250k · production

The middle probe is the entire argument for this model, and I would put it above every other line in this post.

At that instant, the store returns a token budget of 250k alongside a deployment target of staging — a combination that no single memory ever held, and that no version history of any individual belief could ever show you. It exists only as the intersection of two independent supersession chains at one moment in time. A per-memory history tab can tell you what one fact used to be. Only validity bounds over the whole store can reconstruct the world as it stood, which is the thing you actually need when you are trying to work out why an agent did what it did in June.

What happens downstream

Retiring a belief has consequences beyond the belief itself, and two of them needed handling.

Siblings can be stranded. If several memories were derived from the same source and one of them is retired, the others may now rest on something that is no longer believed. Rather than eagerly re-deriving the whole dependency neighbourhood at supersession time, ENGRAM flags the co-derived siblings and lets a background sweep re-validate each against the current belief set. That sweep is strictly non-destructive: it re-derives and it flags, and it never deletes. Supersede-don’t-delete would not survive a janitor that deletes.

Grants must follow. If you had shared a belief with a colleague and then superseded it, a naive implementation strands them on a dead id — filtered out by the active-only predicate, never shown the successor, silently seeing nothing. So the individual grant is re-pointed from the retired belief to its successor inside the same transaction as the supersession itself. Correcting your own memory cannot quietly break what someone else can see.

What this doesn’t do yet

The most instructive thing that happened during this project happened after it shipped.

The feature went out, went live, and worked. Then, checking detection cadence on a genuinely contradicting pair on production, I found two beliefs about the same deployment target — one saying staging, one saying production, twelve minutes apart, both still active. Neither had a content embedding. Nothing had been detected.

The logic was fine. Embedding the pair by hand and running the detector over it returned contradiction at 0.97, winner correctly arbitrated by timestamp. The problem was wiring. The two hooks the feature needs (embed the new belief, then run detection against its neighbours) had only ever been attached to the observed path, where memories arrive by consolidation, and to the artifact-write path. Every deliberate authoring seam missed both. A memory created by remember, or activated by accepting a suggestion, was never embedded and therefore never detectable.

Which means the headline guarantee silently no-op’d for the primary verb. Two contradicting facts authored through remember would sit there, both active, forever. Fixed by extracting a shared activation hook and calling it wherever a memory transitions to active, but I would rather record how it was found than how it was fixed: not by a test, but by looking at real data on a live system and noticing that something which should have happened had not.

The standing limits, briefly:

• Only contradictions supersede. Refinements (strictly narrowing restatements) are recognised by the detector and deliberately left inert. The knob exists; turning it on waits until contradiction precision has a longer track record.
• Detection runs going-forward. Contradictions authored before the activation fix would not have been caught by the live hooks, so a one-time sweep re-embedded and re-checked the existing beliefs on both DEV and production after the fix landed. Detection is still fundamentally a forward operation — it fires when a belief is written or activated, not on a schedule — so the backfill was a deliberate catch-up, not a standing guarantee.
• Forgetting is not decay. Retracting a belief you no longer want is built. Memory that fades on its own, by disuse or age, is a genuinely different problem and is not addressed here.
• Granularity is the memory node, not the claim. A memory bundling three facts, one of which is now wrong, is retired and re-derived whole rather than surgically edited. This was a deliberate choice (the justification record is too coarse to support precise edits) but it means a correction is blunter than it could theoretically be.
• Retracted beliefs have nowhere to live in the interface. A superseded belief appears under the History tab of its successor. A forgotten one has no successor to hang beneath, so for now it is preserved but invisible.

Where this leaves things

Recall tells you what is true. History tells you what was true. And revert tells you that neither answer was ever destroyed — which is the only reason it is safe to let a machine decide the first one.

ENGRAM remains in private beta. If you are running an agent fleet and this is a problem you recognise, get in touch.

For the background this builds on:

1. A Brain Between Sessions — and Between Agents: ENGRAM Learns to Recall on Demand (10 July 2026)
2. Standing Up Your Own Agents: ENGRAM Adds an Agent Manager Role (12 July 2026)
3. A Team of Its Own: ENGRAM Agents Learn to Grow and Orchestrate a Team (14 July 2026)
4. The Layer a Harness Can’t Own (19 July 2026)
5. Keep your memory current — revise a fact, catch a contradiction, never lose the past — the hands-on walkthrough for everything above
6. Give your agent harness a memory — the same verbs in a running fleet