Weight updates within a context do not establish personal memory
TTT-E2E demonstrates a way to process long contexts by learning from them. Persistent user memory needs a separate test of retention, isolation and what happens when information changes.
A model updating weights while reading a context is interesting. I would not use that fact alone to promise that an agent will remember a user correctly next week.
End-to-End Test-Time Training for Long Context describes learning through next-token prediction on the context being processed, compressing information into weights. Its reported experiments include a 3B-parameter model trained on 164B tokens and a 2.7-times latency advantage over full attention at 128K context.
Those are results for a particular long-context method and comparison. They do not demonstrate a production service managing persistent, separate memories for millions of users. The official repository provides implementations and experimental checkpoints, not evidence that such a user-memory service has been validated.
My dividing question is what survives the end of the sequence. A technique can be valuable for processing current context while leaving the product problem of durable memory unresolved.
Persistence changes the object we are operating
Consider a hypothetical assistant reading a long project packet. It adapts internal state while processing the packet and uses that state to answer questions. If the state is discarded afterward, the application has handled a request with an adaptive mechanism.
Now suppose the application keeps the adapted state for future sessions. It must decide whose information that state represents, which new material may change it and how to respond when a fact becomes obsolete. Those are additional product decisions, not consequences that follow automatically from the ability to update weights.
The distinction is not an argument against learned memory. It identifies the evidence needed before replacing an existing memory service with it. A promising substrate deserves a test matched to the job it is being offered.
I would ask the designers to describe the unit of state and its lifetime. Is it per sequence, task, project or user? What is reset, retained or shared? The answer should be visible in the serving design rather than inferred from the word “learning.”
Test across sessions, then across boundaries
For a proposed personalised assistant, I would construct a longitudinal evaluation with ordinary changes: a preference is added, corrected and withdrawn across separate sessions. Check whether the agent uses the right version and can explain the basis for a consequential recommendation.
Then test separation between authorised users or projects. Information learned for one context should not become available in another merely because they share a serving process. The mechanism used to persist state must support that boundary.
Operational recovery also matters. If an update degrades behaviour, can the service restore a known version? If a base model changes, what happens to the retained state? If information must be removed, what operation actually achieves the required result and how is it checked?
These are proposed requirements for a durable memory product. I am not asserting that the research implementation fails them; they are outside the demonstrated long-context result I am citing.
The paper can improve how we think about inference without already answering every question about personalisation. Keeping those contributions separate makes it easier to evaluate both fairly.
Treat test-time learning as a mechanism, and ask persistent agent memory to prove its lifetime, isolation and correction behaviour in a separate evaluation.
