Notes

Decisions, dead ends, and things that only show up once you build it.

Shorter writing than the papers. Each note argues one point, usually a decision we had to make and the reasoning that survived contact with the implementation.

9 notes
2026.07 Replay that never calls the model Learning from past runs normally means re-running them, and re-running an agent means paying for inference twice. Ours replays only the local retrieval and compilation pipeline — the frontier model is never called a second time. Also: why naive TD-error priority spends its budget on irreducible noise, and what recurrence-awareness changes. Teaser for the paper. notein progress
2026.07 Why the controller starts with an opinion Given sparse feedback, an unregularized learner overcommits to whatever it happened to see first. A G-learning-derived free-energy policy pulls early plan choices toward a prior via a KL penalty — so the opening behaviour is conservative and, more importantly, inspectable. You can read the prior. For a memory system you are being asked to trust, that matters more than the regret bound. Teaser for the paper. notein progress
2026.07 Valid time, observation time, transaction time A memory system needs three clocks, not one. When a fact became true, when we found out, and when we wrote it down — and why conflating any two of them corrupts recall. notein progress
2026.07 Tantivy versus a custom sparse index We evaluated using an existing search library against writing our own. What the off-the-shelf option costs you when your documents are agent traces rather than prose. notein progress
2026.06 Tokenizing code paths, email addresses and spreadsheet formulas Standard tokenizers destroy exactly the strings this system needs to match on. What we changed and what it cost. notein progress
2026.06 Event journal framing The append-only format underneath the store, and why the framing decision constrains everything built on top of it. notein progress
2026.06 Locking and multiprocess semantics Four agent harnesses may read the same store at once, and one of them may be writing. What we guarantee and what we refuse to. notein progress
2026.05 Durability and fsync How much we are willing to lose on power failure, stated precisely, because "it persists" is not a specification. notein progress
2026.05 Why the core is Rust A signed binary that runs beside four other people's tools has constraints a scripting language does not meet. The argument, including what we gave up. notein progress

Why we publish these

A decision record is more useful than a changelog. The papers say what we set out to prove; the notes say what we actually ran into, including the parts where the first answer was wrong. Both are part of the record.