A user revises a fact you already stored in memory — how do you resolve the write?

## Append-only memory is the default mistake The naive memory write is "extract facts, insert rows." It works for a week and then rots, because users revise themselves constantly: budgets change, job titles change, preferences reverse, a stated constraint stops applying. An append-only store accumulates every version of every fact with no marker saying which is current. The damage shows up later, in the context window. Retrieval brings back some subset of the stored facts; if that subset contains both "monthly budget is 2,000" and "monthly budget is 3,000", the model is holding two contradictory statements at once — the *context clash* failure mode. There is no principled way for it to choose, so the answer depends on ordering, phrasing and luck. A memory store that produces confidently inconsistent answers is worse than no memory at all, because users trusted it. ## The four-way decision The accepted shape resolves each candidate fact against what is already stored: - **ADD** — the fact is new and does not contradict anything. Insert it. - **UPDATE** — the fact concerns the same subject and attribute as an existing entry but carries a different value. Replace the value in place, keeping one current entry for that attribute. - **DELETE** — the fact invalidates an existing entry without replacing it ("I no longer have a car", "we cancelled that account"). Remove the stale entry. - **NOOP** — the store already carries this. Do nothing. The budget example: `"my budget is now 3000"` against a store holding `budget = 2000` is an UPDATE. Getting this wrong in either direction is instructive. ADD gives you the contradiction above. DELETE-then-ADD churns the entry and loses whatever history the row carried. NOOP silently ignores the user's correction, which is the most annoying failure of the four because the user watched themselves say it. ## Why NOOP is the interesting one In a long-lived assistant, most candidate facts extracted from a turn are things the store already knows — the user restating their situation, the extractor re-firing on the same sentence in a re-read transcript. Systems without an explicit NOOP path write anyway, and the store grows with near-duplicates that all say the same thing in slightly different words. That inflates the store, dilutes anything ranked against it, and multiplies the surface for future contradictions. NOOP is not a degenerate case; it is the modal outcome and it must be cheap. ## How the decision is actually made Resolution needs comparison against the *relevant* existing entries, not the whole store. In practice: pull the small set of stored facts about the same subject or attribute, then have a model decide the operation for each candidate against that set. This means a write costs an extra model call and some latency. That cost drives the timing. Doing resolution inline, before responding, taxes every user turn for a benefit that is only felt later. The common design is to resolve at end of turn or end of session, or fully asynchronously in a background consolidation pass. The tradeoff is a window where a just-stated correction is not yet reflected — usually acceptable, occasionally not (a user correcting a safety-relevant constraint should take effect immediately, which argues for a fast path on explicitly-flagged corrections). ## Structural aids A few design choices make resolution tractable rather than heroic: - **Give facts a subject and an attribute.** "user / monthly_budget / 3000" makes the collision detectable by key. Free-text-only memories force the model to notice contradictions by reading, which it does imperfectly. - **Distinguish superseding from coexisting.** "Prefers window seats" and "prefers aisle seats" conflict; "speaks Spanish" and "speaks Portuguese" do not. Attribute cardinality — single-valued versus multi-valued — encodes this so the resolver does not have to guess. - **Keep one current row per single-valued attribute.** If you need the prior value for audit, keep it out of the retrieval path so it can never re-enter a window as a live fact. ## What to say in the interview Name the four operations, insist that NOOP is a first-class outcome, and explain the failure you are preventing: two live versions of one fact producing non-deterministic answers. Then show the engineering judgement — resolution costs a model call, so it runs off the response path, and the schema should make same-attribute collisions detectable rather than leaving them to prose comparison.