Imagine you're running a large warehouse. The old system: every time someone asks for something, you send a worker to wander the aisles looking for boxes that seem relevant, based on how similar the label sounds to the request. The new system: you've organized the warehouse into a relational database — every item catalogued by type, relationship, and composition — and when a query comes in, you write a tiny program that navigates the catalogue directly. That's Memory as Code (MaC) in a sentence: stop treating LLM memory as a bag of embeddings to similarity-search; treat it as a structured, executable codebase you can query programmatically. The committed claim: a three-layer memory architecture — atomic functions, relational links, modular compositions — paired with declarative retrieval programs that translate natural-language queries into structured lookups, outperforms all existing long-term memory systems on two established benchmarks (LoCoMo and LongMemEval) by up to 15.91% relative accuracy, while also reducing token consumption. This isn't a new retrieval model or a new embedding trick. It's a different abstraction layer: memory items are code objects, and retrieval is program execution over those objects. The architectural family here is code-generation-as-reasoning, sitting in the lineage of program synthesis and structured tool use for LLMs. The three-layer construction — atomic (individual facts as callable functions), relational (edges between facts), and compositional (higher-order modules that compose atomics and relationals) — borrows from software engineering's module hierarchy. Retrieval isn't vector similarity; it's closer to SQL-over-a-function-graph, where the LLM generates a retrieval program that walks the structure. The method leans heavily on the LLM's own code-generation capability as the query compiler. On the ladder: the paper competes against memory systems on LoCoMo and LongMemEval, which are the current community benchmarks for long-horizon conversational memory. The 15.91% relative gain is over the strongest baseline in each setting, though the abstract doesn't name that baseline explicitly. Token reduction is claimed but not quantified with a specific number in the abstract. The result pattern — gains on both benchmarks, not just one — is meaningful, but without named baselines and exact deltas per setting, we're working with a headline number. Integrity-wise, the use of two established community benchmarks (LoCoMo and LongMemEval) is a positive signal — these aren't custom-built evaluation sets. The LLM-judge accuracy metric is standard but inherently noisy; LLM judges have known biases. The paper does not mention pre-registration or code release in the abstract, and there's no sign of independent replication. The dual-benchmark design reduces cherry-picking risk, but the 'strongest baseline in each setting' framing leaves open whether different baselines win on different benchmarks. The milestone question for this line of work is whether code-structured memory can scale to truly massive interaction histories — thousands of sessions, tens of thousands of facts — without the code-generation step becoming the bottleneck. Current benchmarks test long-horizon but bounded scenarios. The real unlock is agent memory that handles open-ended, years-long interaction logs while maintaining composability. That likely requires the retrieval-program compiler to handle ambiguity and partial matches, not just clean structured lookups. The obvious experiment not run: scaling to much larger memory stores (10×–100× the benchmark sizes) to see where the code-generation retrieval breaks down. My honest read: this is likely (a) — compute and dataset limitations at submission time. Building massive long-horizon interaction corpora is expensive, and the benchmarks that exist are the ones they used. A secondary gap: no ablation separating the value of the three-layer construction from the value of declarative retrieval — you'd want to know which component does the heavy lifting.
