We keep building agent memory like a chatbot: store what was said, fetch something nearby later, hope the model is careful. That produces fluent recollection and wrong edits. The agent can retell the architecture and still patch the function you renamed last week.
Compilers already solved "a name that no longer points at anything". They parse, check kinds, bind names to objects, rebuild what changed, and refuse when the binding is dead. This talk walks through that pipeline applied to agent memory:
- Parse: split what a team writes down ("we use the App Router, server components by default") into separate claims that can be checked.
- Typecheck: architecture, convention, contract and anecdote are different kinds of claim with different rules.
- Ground: bind each claim to a symbol and file that still exists, with a hash of its body. A rename is an unresolved identifier, a move is a dangling pointer, and a same-name function with a new body is only caught by the hash.
- Recompile incrementally: dirty files, dirty nodes, dirty claims, a worklist instead of a full rescan.
- Report diagnostics, not narrative, and fail closed: do not load a claim that no longer resolves.
I will also say why embedding search is a different operation. Similarity is not reference, and it can return the right filename with the wrong function.
Where the memory lives matters as much. Kept in the repo and synced through Git, with no server, it is versioned and branched with the code and shows up in review next to the change that made it stale. A separate memory service turns into a second source of truth nobody reviews. The open-source mex project (MIT licensed) implements this; the talk stays on the technique and its tradeoffs, not a product tour.
Format: 25-30 minute talk, no demo.
