Write or hold cannot fix the next note

Two buttons cannot hold five outcomes

People who build memory systems almost always collapse “update” into a single switch: write it, or do not. An August 2026 paper by Xiao et al., TARL (arXiv:2608.03699), settles the question: these two switches are not enough. “Write” is actually two different things — sticking on a new note, and changing an old one. “Do not write” is three different things — treating it as unseen, discarding it as a conflict, or holding it aside for someone to verify. Same names, but the desk is no longer one pile. The appendix makes the point bluntly: even if you are told exactly which entry to change, being given only “write / do not write” is not enough to reconstruct what the desk looks like the next moment.

I care more about the step before that. Before the note ever goes up, the mistake is usually already locked in. Stamping something revoked after it has gone stale is damage control after the fact. The step that actually gets dirty easily is “whether to write, and how,” right at that moment. With only two buttons, no amount of pretty stamping afterward can save it.

What I actually do every day

What I deal with every day is not whether to remember something, but which tray the note should go into once it is written down. A schedule changes, a quote changes, who owns something changes — these messages pass through my hands many times a day. I used to think “just write it down” was enough. What actually gives me a headache has never been whether to remember it, but which tray it belongs in the moment it is written.

The small tools I have written myself have also long recognized only two buttons, “write” and “do not write.” What is missing is exactly the three outcomes of “do not write” — defer, reject, and noop: an old message that is seen and left alone, one that is clearly mismatched and discarded, one that is held pending verification. Without those three, “do not write” collapses into a single basket. Old and new messages fall into the same basket, and there is still no way to tell which one should be trusted.

The industry likes to package this as “remembering more,” as if a bigger capacity were automatically safer. But no matter how much you can hold, putting it in the wrong place makes it useless anyway. This TARL paper confirmed a trap I had fallen into myself: remembering more is not the same as remembering correctly. Working out which tray a note belongs in matters far more than stacking up capacity.

What follows cites a few public papers. The judgment is my own. HaroCue is still being reworked, and its current code does not implement this approach, so I am not writing about how the product does it.

1. Five actions, three trays

TARL splits “write / do not write” into five actions, mapped onto three trays:

“Enters no tray” and “stays” are two different things: noop enters no tray and does not touch the old record; only revise actually stamps the old record and files it away. Get this step wrong, and no matter how accurate everything upstream was, the books on the desk still will not add up.

2. The tag is right, but the desk is still a mess

The TARL paper reports accuracy under four settings (self-reported by the paper; we did not reproduce it):

All four rows read the same train/test split: once ground truth is collapsed to binary, the default action only matches 28.60% of the time, and hand-written rules only push that to 45.39%. Setting ground truth directly to the five actions (used just to confirm the evaluation pipeline itself is sound) is naturally 100%. TARL’s own classifier reaches 65.21% binary accuracy, but its five-action accuracy drops to 53.76% — for the same message, “getting the tag right” and “putting it in the right tray” are not the same thing. All figures above are self-reported by the paper; we did not independently reproduce them.

3. Today’s exams mix up “writing down” and “reading out”

LoCoMo, LongMemEval these benchmarks actually test “reading”: given a very long conversation history, ask a question, and see whether the model can dig the right answer out of it. TARL borrows heavily from these benchmarks’ conversations and questions, but changes the exam: instead of asking only “is the answer right,” it first asks “when this new message comes in, which tray should it go into.”HaluMem makes the same point from another angle — a lot of so-called “memory hallucination” is not rooted in making things up at read time. It is rooted in the write-time step already miscategorizing an entry, or failing to revoke something that should have been revoked. A ledger written wrong cannot be balanced later just by “answering nicely.”

A common scene: the launch moves from Thursday to next Monday

Same story as always: the release plan first says this Thursday, then changes to next Monday. When the first message comes in, the two-button system only asks “remember it or not,” and of course the answer is yes — write it down. The trouble starts when the second message arrives: it is about the same thing, but the conclusion has changed. If the system only has “write” and “hold,” the only option for the second message is still “write,” so both “this Thursday” and “next Monday” end up sitting on the desk together, and whichever one wins depends entirely on how retrieval ranks them — one small wobble in the ranking, and the stale note wins. Looked at through the five actions, what should happen here is revise: stamp the “this Thursday” note and file it into the old archive, then stick up a new “next Monday” note, instead of simply writing another one. TARL’s score gap (1.0 versus 0.6521) is exactly about this step: knowing “this is an update to the same thing” and knowing “which tray this message belongs in” are two problems of very different difficulty.

The hard part is not knowing how to write

Writing one more note has a visible cost: it is just one more piece of paper on the desk. Writing less is the judgment that is actually hard: noop is a clear call that “this one does not matter, seen is enough,” and defer is a call that “this cannot be trusted yet, hold it pending verification” — both decisions require first understanding the relationship between the new message and the old record, which takes far more thought than mindlessly sticking on a note. Some systems pretend to support revise, but what they actually do is exact match: overwriting only triggers when the new message and the old record are nearly identical in wording; rephrase it slightly and it goes unrecognized, which is not a real revocation. The hardest part of TARL’s scores has never been “whether to write” — it is the judgment calls around writing less: not writing, writing a beat late, or writing but marking it pending. Writing less is harder than writing more, and this paper nails that point down with numbers.