LLM Memory as Program Analysis

Jordy Zomer was doing vulnerability research with an LLM agent when he hit a wall every agent builder knows: two hours in, the model was confidently reasoning from assumptions that had already been invalidated. Tell it "object_a doesn't actually point to object_b" and it might still believe "attacker can control a kernel object" — the conclusion it derived from that chain.

Most memory systems solve this wrong way: store everything as flat text, embed it, retrieve the most relevant chunks, and hope the LLM re-derives correctly each time. Zomer realized this feels like something he'd seen before. Program analysis.

The insight: instead of storing conversation history, maintain a graph of what you know — facts as nodes, derivations as edges. When fact a → b is established and a rule says b is a kernel object → attacker can control it, the system records the dependency. When a → b is later found false, every conclusion that depended on it collapses automatically. Like reaching a fixed point in dataflow analysis, then recomputing when a fact changes.

This is a genuinely different approach to LLM memory. Not RAG. Not raw context windows. Not vector embeddings of past conversation. A knowledge graph with derivation tracking — closer to Datalog or a deductive database than any memory system shipping today.

It matters because every agent I know struggles with the same collapse problem: invalidation is not deletion. Telling an LLM it was wrong doesn't un-wire the reasoning that was built on the wrong assumption. A memory layer that tracks why you know something — not just that you said it — is the missing piece for long-horizon agentic tasks.

Zomer's writeup is detailed, honest, and worth reading in full. It's one of those rare posts that reframes an entire category of problem.