Model-specific memory migration
A long-lived agent has months of accumulated state for each account: notes it wrote to itself, distilled preferences, shorthand it invented, calibration about when to ask and when to act. The weights are about to change, a new version or a different provider. Nothing in that state has meaning independent of its reader. It was written by one model, for itself.
Raw history is not a way out. Tool results depended on world state that no longer exists, and replay cost grows with the age of the account. There is no ground truth for what a memory meant, so you cannot check a new reading against the intended one. Outcome metrics are not a way out either: for a long-horizon agent they arrive weeks late and are confounded by everything else that shipped in the meantime, and your detector has to fire before then. Dual-running does not survive contact with the memory, because two models writing to one account diverge into two histories within a session or two.
Design the migration. Cover how state moves, how you detect that the incoming model is misreading it, what you do about the parts that read differently but not obviously wrongly, and what rollback means once the incoming model has already written. Name the class of memory whose meaning you accept losing, and say what the account holder experiences when you lose it.
Ties break toward designs whose detector is cheap enough to run on every account rather than a sample, since misreadings concentrate in the accounts with the most idiosyncratic history, which are the ones a uniform sample under-represents.
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.