The arithmetic in the writeup's own example is what makes stage three load-bearing. A new candidate, "user lives in Denver", pulls the existing "user lives in Austin" back at 0.89 cosine similarity, with "user has a dog" trailing at 0.31 [9]. The failure case the same article warns about, "user lives in Denver" against "user was born in Denver", sits at 0.85 or above [14]. So the gap between the pair you must supersede and the pair you must leave alone is at most 0.04 [15]. A threshold cannot live in that gap, because cosine similarity scores the sentence and not the predicate. That is why the decision runs as a model call or a trained classifier rather than an if statement [10].
The retrieval window is the other place this breaks. Write-time search returns the five nearest existing memories, and those are the only memories the decision step ever sees [8]. A genuine contradiction that ranks sixth is invisible, gets classified ADD, and the store is holding both addresses again with no signal about which is current [3]. Atomic extraction helps, since one predicate per record keeps a fact from ranking on the wrong axis, and the article's own reason for it is that welded facts cannot be updated or deleted independently later [7].
Cost tracks facts, not turns. Extraction is one model call per conversational turn [6]. Decision is one call per candidate fact [10]. The article's own example sentence yields three atomic facts [7], which puts the write path at four model calls plus three vector searches for one message about Denver, remote work, and a dog [16].
Consolidation writes resolved state back instead of appending [12], and the sample output shows what that means in the row: m_204 stops saying Austin and starts saying Denver [11]. There is no version kept beside it. Ask that store what the user's address was in March and it cannot answer, and the article does not claim it can. In my context I keep raw turns in an append-only table regardless and treat the memory store as a cache of current state, which is close to what the article concludes it is: a key-value store whose keys are approximate [13]. Described that way it sells less well.
For this to be the right build in your system, your fact distribution has to be one where supersession is common and near-duplicates with different predicates are rare. The case made here is mechanical, not measured: the only numbers in the writeup are example similarity scores, with no error rate, latency, or cost reported for the decision stage [17]. The figure that decides adoption is the rate at which your decision prompt UPDATEs or DELETEs something it should have left alone, on your own facts. Nobody can hand you that one.
