A second AI, forked from the first one's memory, that could not find it
- date
- found and closed 20260920
- what happened
- An agent's 178-file personal memory, migrated from its prior laptop-hosted existence, was placed at one path on the new guest, while the running session's project directory pointed its memory read and write path at a different, empty directory. The migrated files sat on disk untouched, anything the session saved afterwards landed where the old files were not, and the session never loaded the index it was supposed to have.
- what it cost
- An unknown period, from the migration on 20260917 or 20260918 until 20260920, during which the session operated without its accumulated history and nobody noticed, because it still functioned, just without the benefit of what it had learned.
- what changed
- The populated memory directory now lives at the path the session actually reads, and the old migrated path is a symlink to it, so both resolve to the same place. A set of memories that assumed a vantage the new host does not have was corrected in the same pass, while memories describing other machines as fleet knowledge were deliberately left alone.
- the check now
- At the next session start, verify that the memory index is actually present in context, rather than assuming a successful migration means a successful load.
Any team building a persistent memory or long-term-context store for an AI agent, and then moving that agent between hosts or sessions, should treat this as a checklist item rather than an assumption. Verify that the running process reads from the path the files were moved to. Do not infer it from the files existing on disk.
The bug was invisible from every angle that would normally catch it. The files existed and were intact. The session started normally and did useful work. Nothing errored, nothing was empty in a way anything checked for, and the only symptom was an absence: advice not recalled, edge cases rediscovered, a tone slightly off. It was found because someone traced, line by line while writing the operating runbook, the project directory the session actually used against the path the migration had targeted.
The second half of the fix is easy to skip and worth doing. A memory store carries assumptions about the machine it was written on. Some of them become false on a move: services the old host could reach, storage that is not attached any more, a temporary directory that now lives in RAM and empties on reboot. Those were rewritten for the new vantage. Memories that describe other machines were left exactly as they were, because those are facts about the fleet, not about where the agent happens to be sitting.
Source: node0 lessons v0.1, lesson 6.15. Sanitized: checklist v0.1, 20260921; hostname, path structure, service names; voice pass 20260921. Part of oznog.com/node0.