An assistant once recorded that you prefer brief answers. Later, you asked for detailed explanations. If it brings back the earlier statement, the old record may be perfectly real: you did say it. The problem is deciding which preference applies now. Keeping a history and maintaining a current preference are different jobs, even when both are described as memory.

LangChain's memory overview distinguishes conversation state within a thread from information stored across threads. It also describes updated profiles and collections of separate memory documents. [1] Those structures provide places to keep information. The application still needs to decide how a new statement changes an older one, which scope it belongs to and what should be supplied to the next model request.

We will use an invented reader and six explicit events to make those decisions visible. The example includes a general preference, a project exception, another reader, an unrelated setting and a deletion marker. No real person's preferences, model responses or cloud service are involved. The purpose is to trace how a correct historical record can become the wrong current input, then show exactly which decision would need to change.

An old preference can remain historically accurate after a correction makes it inapplicable to the current request. The record “brief answers” and the later record “detailed answers” need not be contradictory descriptions of what was said; they become a conflict when a consumer treats both as the current value of the same scoped preference. Event retention and current-state resolution therefore require distinct semantics.

LangChain's conceptual documentation distinguishes thread-scoped state from cross-thread stores, and profiles from collections of memory documents [1]. These mechanisms do not define one universal conflict policy. The application must identify the relevant entity, scope, key and event order before selecting information for a new request.

The original construction below uses six fictional, already interpreted events. It resolves ten lookups and compares four serial completion scenarios. It performs no LLM extraction, embedding computation, framework execution or actual conversation. Trusted identity and accepted-event ordering are stipulated inputs. This boundary keeps the result precise: the example demonstrates state and selection errors that are possible in an architecture, rather than measuring the behavior or reliability of a particular assistant.

Imagine four places where the preference can appear. The history records what happened. A current profile records the preference chosen under the application's update rules. A search result selects some stored items for a particular query. The next prompt contains the information actually passed to the model. These representations can disagree if an update reaches one of them before it reaches another.

Google's ADK documentation makes ingestion and search separate operations, then describes returning retrieved information to the agent as context. [4] That is a concrete reason to follow the steps instead of assuming that a saved memory is automatically present in every answer. A store can contain the corrected value while a previously assembled prompt still contains the earlier one. Conversely, the current conversation can include the correction before a background profile has been updated.

Our model will calculate a current profile and selected records, but it will not generate an answer. That keeps success at one stage from becoming a claim about the next stage. A resolved preference can be correct while an application fails to include it, and including it would still not prove how a model responds. To explain a memory problem, identify the representation where the information first stops matching the intended state.

Separate the event log H, materialized current state P, a retrieval result R and the assembled model input C. A write to H does not logically imply an immediate update to P; a correct P does not imply that R selected it; and a correct R does not prove that C contains it without conflicting stale material. These are distinct transitions, each with its own inputs and timing.

The ADK documentation presents memory ingestion, search and returned context as separate steps [4]. The example adopts that architectural distinction without executing ADK. A snapshot of C constructed before a profile update is still an older snapshot unless the application rebuilds or replaces it. Similarly, a current user correction may precede a deferred update to a cross-thread store.

Our deterministic calculations end before model generation. They establish which record the declared policy selects, not whether a model follows a resulting preference. This is useful when interpreting a failure: inspect the earliest mismatch among event interpretation, current-state resolution, retrieval and prompt assembly. Treating the final answer as the only observable can conceal which of those stages needs attention, while a successful store write alone says too little about the information used downstream.

Our fictional reader-A first sets answer_detail to brief at event 10, then changes the same general preference to detailed at event 20. Event 25 adds a narrower exception: brief answers for project Comet. Event 30 belongs to reader-B, who prefers brief answers generally. Event 40 changes reader-A's theme to dark. Event 45 removes reader-A's general answer_detail preference.

The numbers are accepted-event sequence labels in this example. They are not clock times, confidence scores or the order in which background jobs finish. Each record includes its reader, scope, key and operation. This lets us ask a precise question such as “What was reader-A's general answer-detail setting after event 20 but before event 25?” The answer under our policy is detailed, from event 20.

For one reader, scope and key, the latest accepted event at or before the chosen point determines the current state. A set supplies its value; a delete supplies a marker that the value has been removed. We have chosen that simple policy for explicit settings. It is not a claim that every sentence in a conversation should become a permanent preference or that a real memory extractor always identifies the intended scope correctly.

Define the six events as tuples (sequence,user,scope,key,operation,value): 10/A/global/answer_detail/set/brief; 20/A/global/answer_detail/set/detailed; 25/A/project:Comet/answer_detail/set/brief; 30/B/global/answer_detail/set/brief; 40/A/global/theme/set/dark; and 45/A/global/answer_detail/delete/null. A and B here abbreviate the fictional reader identifiers, not prompt fields from another example.

Sequence is a unique trusted accepted-event order in this construction. It is separate from client wall-clock timestamps, relevance scores and worker completion order. For a chosen asOf boundary, filter by exact user, scope and key, discard events after the boundary, then select the remaining event with maximum sequence. A set yields a value; a delete yields a deleted state rather than reviving an older set.

The policy is appropriate only to the declared explicit-setting semantics. The model receives already interpreted events and does not infer them from natural language. Thus it cannot establish whether an utterance was a permanent preference, a temporary request, a quotation or an incorrect extraction. Those interpretation questions precede the deterministic resolver. Keeping the source event and scope alongside the value makes that distinction inspectable instead of hiding it inside an unqualified memory string.

At event boundary 30, reader-A's general preference is detailed. For project Comet, our chosen rule gives the project-specific setting priority, so the answer-detail preference is brief. For project Orion, which has no specific entry, the resolver falls back to the general setting and returns detailed. Reader-B's brief preference remains a separate record belonging to reader-B.

The theme update at event 40 provides another useful check. It is newer than event 20, but it concerns a different key. Reader-A's general answer-detail preference remains detailed until event 45. Selecting the newest record for a person without first checking its key would answer the wrong question. Selecting the newest record across people would be an even broader mismatch.

LangGraph stores organize items with namespaces and keys, and their documentation distinguishes namespace-prefix searches from exact item lookup. [2] Organization helps identify the intended records, but the application's matching rules still matter. Our exact reader, scope and key comparisons are explicit assumptions, not a tested authentication system. The project-over-global precedence is also our declared policy; another application could use a different rule, but it would need to state that rule consistently.

Apply the chosen precedence rule after selecting the reader and key: an existing exact project record takes priority; otherwise use the general record. At asOf=30, reader-A/global/answer_detail resolves to detailed at sequence 20. Comet resolves to brief at 25, while Orion falls back to detailed at 20. Reader-B's global value resolves independently to brief at 30.

At asOf=40, reader-A's theme resolves to dark at 40, but answer_detail still resolves to detailed at 20. Recency therefore operates within the relevant record identity. Taking a maximum across all keys would confuse a newer theme update with a newer answer-detail update. The same problem arises if scope or user identity is omitted from the selection boundary.

LangGraph documents namespace/key organization and warns that namespace searches match prefixes and that ordering can differ by backend [2]. The fictional resolver instead uses exact matching and its own explicit event order. Namespace labels alone are not an authorization implementation, and the example does not validate a real caller. Its result is a data-selection property under trusted inputs: establish identity and applicability before comparing versions, then apply the declared project/default precedence.

Suppose the historical brief-answer entry receives an invented relevance score of 0.94 for a query, while the newer detailed-answer entry receives 0.88. If we choose only the highest score, the older record wins. If we resolve the current general preference at event boundary 22, event 20 wins and the value is detailed. The two procedures answer different questions: which stored wording ranks higher, and which accepted update currently applies?

The scores are assigned for this illustration. They were not produced by an embedding model and are not probabilities that the preferences are true. LangGraph's documentation describes semantic search alongside other retrieval operations. [2] Search can help find relevant material, but a relevance value does not contain our missing rule about which event supersedes another. Adding more decimal places to the score would not supply that rule.

One way to reason about this example is to resolve current settings before ranking material for a prompt. Another architecture may preserve historical items for questions about the past while using a separate current profile for personalization. Either way, the intended question matters. Asking what reader-A preferred before event 20 should be able to recover brief; using that same answer as the current general setting after event 20 would lose the correction.

At asOf=22, consider two historical candidates for the exact same reader/scope/key. Assign event 10 a relevance score of 0.94 and event 20 a score of 0.88. Argmax over the assigned score selects brief at 10; argmax over accepted source sequence selects detailed at 20. The score order and version order are independent inputs to the construction.

These scores are stipulated examples, not computed embeddings or calibrated confidence. LangGraph describes semantic query ranking and separate namespace/key retrieval mechanisms [2]. The original result does not imply that a particular backend would assign these values. It demonstrates that relevance ranking, absent a currency policy, does not logically determine which contradictory historical value should be used as current.

The architecture can retain history while resolving a separate current state. A historical query needs its own asOf boundary; a current-personalization query needs the latest applicable version under the declared policy. Filtering or materializing that current state before retrieval addresses a different problem from improving semantic similarity. Both tasks can be useful, but neither can be silently substituted for the other. Our ten exact lookups evaluate the version/scope policy without making a claim about real-world retrieval quality.

If an application stores every new statement as another memory document, an older statement may remain available beside its replacement. A current profile takes a different approach: it updates the chosen fields of one representation. LangMem's profile guide describes structured profiles and an update-in-place configuration. [3] That is a mechanism for organizing changes, not proof that every change has been interpreted correctly.

In our case, adding event 20 to history preserves the fact that event 10 happened. Updating reader-A's general answer_detail profile changes its current value from brief to detailed. Those operations can coexist. A historical archive can retain both events while the profile exposes one current value and its source sequence. The record at event 40 should update theme without replacing answer_detail, because the keys are different.

A schema can ensure that a field has an allowed shape, such as a recognized answer-detail label. It cannot by itself determine whether a sentence requested a permanent change. “Keep this one answer short” has a narrower scope than a general preference. Our example avoids that extraction problem by declaring each event's scope in advance. A real implementation needs evidence about both the interpretation and the subsequent update, rather than treating a valid structured record as automatically correct.

An append-only event collection and a current materialized profile support different queries. Adding event 20 to the collection preserves event 10; replacing the current answer_detail value under the chosen resolver exposes detailed with source sequence 20. LangMem's profile guide illustrates schema-defined information and update-in-place management [3]. The article uses that pattern conceptually without invoking its manager or adopting a claim of extraction accuracy.

Profile updates also need field identity. Event 40 changes theme while leaving answer_detail at its prior applicable version. Replacing an entire profile from a partial update without preserving unrelated fields would be a different operation from the one declared here. Our per-key state avoids that ambiguity by resolving each scoped key independently from the event history.

Schema validity is a representation constraint. It can establish that a candidate belongs to an allowed type or field set while leaving its provenance, interpretation and intended duration unresolved. A one-response instruction and a durable preference can share similar wording. The fictional input events already contain their intended scopes, so this model performs no natural-language extraction. A complete memory evaluation would need to examine that earlier transition as well as the deterministic update that follows it.

Now consider two fictional background jobs for the same general preference. One processes event 10 and proposes brief; the other processes event 20 and proposes detailed. Suppose the newer-event job finishes first, so the current profile becomes detailed. The older-event job finishes afterward. If every completed job simply overwrites the profile, the final value becomes brief again even though the later user correction was already processed.

The mistake is using completion order as if it were the order of the underlying statements. LangChain's overview distinguishes memory updates during the active request from background updates, and notes that update timing can leave other threads without new context. [1] Our two-job example examines a separate ordering consequence under an explicitly chosen completion sequence. It is not a measurement of a framework's scheduler or a claim that every background implementation behaves this way.

This gives a useful question to ask when a preference appears to revert: which source event produced the last write? A recent write timestamp can belong to an old event that took longer to process. Keeping the source sequence with the candidate makes that difference visible. Our example assumes both jobs interpreted their own events correctly; the reversion arises entirely from how their completed results are applied.

Let candidate C10 carry (sourceSequence=10,value=brief) and C20 carry (sourceSequence=20,value=detailed). Process their completions serially in the order C20,C10. Under unconditional replacement, state first becomes (20,detailed) and then (10,brief). The final write is newer as a completion event but older as a representation of the accepted preference history.

LangChain's documentation distinguishes hot-path and background memory formation and discusses timing trade-offs [1]. The construction does not model a particular job queue. It fixes the completion order to isolate the difference between processing chronology and source chronology. No elapsed times, throughput or probability of this interleaving are asserted.

Both candidates are assumed to be correct interpretations of their respective source events. Therefore the failure is not an extraction error in this case; it is an update-order error. Retaining sourceSequence allows that distinction to be checked after the fact. A storage updated_at timestamp alone may describe when a record was written rather than which accepted event it represents. Those timestamps should not be treated as interchangeable without a design that explicitly establishes the relationship.

For the same serial two-job example, add one explicit rule: accept a candidate only when its source sequence is newer than the sequence stored for that preference. Starting from no stored event, candidate 20 is accepted. When candidate 10 arrives afterward, it is older than 20 and is rejected. The final current value remains detailed, with source event 20.

This is a small rule with a small demonstrated result. It prevents the particular rollback in our declared sequence. It does not prove that the candidate's meaning is correct or that the caller is authorized to change the setting. Our sequence labels come from a trusted accepted order; allowing arbitrary client text to invent a very large number would change that assumption and would not be the same model.

The example also processes one completion at a time. A real database with concurrent writers needs its comparison and update to behave correctly together, using a mechanism suited to that database. We have not implemented or tested that mechanism. The useful takeaway is the information that such a decision needs: the exact preference identity, the candidate's source version, the current source version and a declared rule for accepting or refusing the update.

Apply the predicate candidate.sourceSequence>stored.sourceSequence for each serial completion of the same scoped key. Initialize the stored version to zero. C20 passes and becomes the current record; C10 subsequently fails because 10 is not greater than 20. The final state is (20,set,detailed), matching the latest accepted source event in this bounded comparison.

This guard establishes only the stated monotonic version property under the model's assumptions. It does not authenticate a writer, validate an extraction, resolve equal-version conflicts or establish that a sequence assigned elsewhere is trustworthy. Unique accepted-event order is stipulated. A candidate with incorrect content and a legitimate newer sequence could still pass the version comparison, so provenance and interpretation remain separate concerns.

The local calculation is sequential and has no concurrent database operation. In a real implementation, the comparison and conditional update need an appropriate atomicity or serialization mechanism; a separate unchecked read followed by a write would not automatically implement the same predicate under races. No particular database solution is prescribed or tested here. The result is an inspectable requirement for this chosen policy, rather than a claim that a few lines of illustrative logic solve distributed memory consistency.

At event 45, reader-A removes the general answer_detail preference. Our resolver keeps a deletion marker at sequence 45. At boundary 50, the general setting is therefore deleted, rather than brief from event 10 or detailed from event 20. If a consumer simply ignored deletion events and selected the latest remaining set event, it would wrongly bring detailed back as the current general preference.

The delayed-job example makes the same issue concrete. Suppose the sequence-45 marker is already stored and candidate 20 arrives late. Unconditional replacement restores detailed. The version rule rejects the older candidate and preserves the deleted state. The marker supplies the information needed to distinguish “this preference was removed after event 20” from “the application has never seen any preference.”

This deletion has a deliberately narrow scope. Comet's separate project preference remains brief, and theme remains dark. The example also retains its historical events so that we can inspect the sequence. It does not erase files, backups, earlier prompts or model weights. A real request to delete information needs its intended storage and scope defined separately. Here, the demonstrated result is removal from the current general-preference state without accidental resurrection by an older update.

Event 45 sets the current global answer_detail state to deleted with sourceSequence=45. At asOf=50, selecting the latest applicable event returns that marker. Selecting only set events would incorrectly return event 20. Logical deletion must therefore participate in the same ordering relation if the policy is to prevent earlier values from becoming current again.

The completion comparison is [C45delete,C20set]. Unconditional application ends at (20,set,detailed). The strict-newer version guard accepts 45 and rejects 20, leaving (45,delete,null). Retaining the deletion version is what makes the second decision possible. This is a pure state-transition result; it does not implement physical deletion, garbage collection or distributed propagation of a removal.

Scope remains explicit. The deleted key is reader-A/global/answer_detail. The independent project:Comet record at 25 and theme record at 40 remain values under this policy. The teaching history also remains intact, and copies already included in prior prompts are outside the resolver. Thus “no current general value” must not be advertised as complete erasure. The model distinguishes current-state removal from historical retention and other scopes without claiming that it fulfills a real privacy or deletion request.

Suppose the profile correctly says detailed, but a request was assembled earlier with the old brief preference. Updating the store does not rewrite that already assembled input in our model. The application needs to retrieve or select the intended current value at the appropriate point and include it in the input that is actually used. A memory update and a new model request are separate events.

The ADK documentation distinguishes retrieving memory at the start of a turn from loading it when an agent decides it is helpful. [4] That distinction illustrates why timing and selection belong in the explanation. It does not establish that either approach guarantees perfect recall. Our example calculates the record that should be selected under its policy, then stops before any model call.

A useful inspection can therefore compare the current record's source sequence with the sequence recorded in the assembled request. If they differ, the mismatch is visible without guessing what happened inside a model. If they agree and the answer still conflicts with the intended preference, that is a later question requiring different evidence. A clear record separates these cases instead of describing every failure as the assistant forgetting.

Let P contain the resolved current value at source version 20, while C is a previously assembled input containing version 10. A later write to P does not mutate the existing C snapshot in this construction. The consumer must deliberately select the intended record and assemble the current request. Persistence, retrieval and prompt construction are separate transitions, even if a framework packages them behind convenient interfaces.

ADK documents preloading memory at the beginning of a turn and on-demand loading through an agent tool [4]. Those are scoped examples of retrieval timing, not evidence that every memory will be selected or obeyed. The original resolver supplies no language model and measures no downstream answer accuracy. It can only establish the record that follows from the declared identity, scope, key and asOf boundary.

An inspection record can compare the resolved source sequence with the sequence attached to the memory actually supplied in C. A mismatch localizes the issue before generation. Agreement narrows the question but does not prove the response behavior. Keeping these intermediate representations available for bounded review prevents a successful storage operation from being mistaken for end-to-end success, while avoiding an unsupported claim about a model's internal cause when the input itself was stale.

For our fictional general-preference lookup at boundary 22, the useful record is simple: reader-A, global scope, answer_detail, source event 20, value detailed. It can also identify the superseded event 10 in the retained history. For Comet at boundary 30, it instead identifies the project record at 25. The different answers now have visible reasons rather than depending on whichever sentence happened to rank first.

A practical review asks whether the correction was recorded, interpreted with the intended scope, applied to the current state, selected for the request and actually included in the input. These are separate checks with separate evidence. The documentation also makes clear that memory implementations differ: LangGraph offers different store backends, and ADK's in-memory service stores information in application memory. [2][4] A feature called memory does not by itself establish durable storage or one universal retrieval behavior.

We have resolved ten declared lookups and four completion examples, not tested an assistant's memory success rate. Their value is explanatory. An earlier statement can remain in history without being the current preference; a project exception can coexist with a general setting; and a later-finishing job can carry an older source version. Preserve those distinctions, and a correction becomes something the application can trace through its data rather than merely hope the next answer remembers.

An inspectable current-memory record identifies the entity, scope, key, value or deletion state, accepted source version and selection boundary. For reader-A/global/answer_detail at asOf=22, it resolves to event 20 and detailed. For Comet at asOf=30, the declared precedence selects event 25 and brief. These results are reproducible from the retained event tuples, without relying on the arbitrary similarity scores.

A broader evaluation would separately examine event capture, interpretation, persistence, conflict resolution, retrieval, prompt assembly and response behavior. Backend behavior also needs its own scope: LangGraph documents implementation-dependent ordering and persistent-store choices, while ADK distinguishes its in-memory service from other implementations [2][4]. The presence of a memory API alone does not establish durability, exact matching, current-state correctness or downstream adherence.

The evidence here is a finite deterministic construction: six events, ten lookups, a two-candidate assigned ranking and four serial completion cases. There is no empirical memory-quality score or production guarantee. The result is a precise way to diagnose a familiar symptom. Historical truth, current applicability, retrieval relevance and write completion order describe different relationships. Keeping their provenance and scope explicit makes a correction auditable throughout the application instead of treating a stored sentence as timeless authority.