Jared Frieden · AI Systems Architect & Engineer
jared / engine / memory-architecture

Persistent Memory and Curation

A file-based memory system that survives context death, plus a dashboard that treats memories like production data, with freshness contracts, drift sweeps, and a git-backed curation layer.

in daily use System · 2026, ongoing MarkdownNode.jsSQLiteSVGGit
Memory files one fact per file, git-backedrules · projects · workarounds Index one line per memory,loaded every session Session context recall at start,persist at the end Freshness contracts last-verified dates +invalidation triggers Curation dashboard drift queue · graph viewaudited like prod data indexed recalled stale? verify first prune · correct new lessons written back, one fact per file

The problem

Agents forget everything between sessions, and the obvious fix, dumping notes into an ever-growing context, actually makes them worse: recall degrades as the window fills up. What I wanted instead was a memory that lives outside the context window, loads only the part a session needs, and can be audited and corrected like any other production data.

One fact, one file

Each memory is a single markdown file holding one fact, typed by its frontmatter as a user profile, a feedback rule, a project state, or an external reference. Files link to each other with wikilinks, so what I end up with is a graph rather than a flat pile of notes. A compact index file is the only thing loaded into every session; everything else is pulled on demand. As of July 2026 the store holds 145 memories, and the whole directory is its own git repository, so every change to what the system believes is versioned.

Freshness as a contract

Project and reference memories carry two fields: when the fact was last verified, and a named event that would invalidate it. A memory older than 14 days has to be re-checked against ground truth, the actual files, the git log, or the live endpoint, before it can be stated as fact. Once the named event has fired, the memory is treated as stale straight away. A snapshot from the past does not get to override what is true now.

Staleness is enforced by sweeps as well: worker agents periodically re-verify old memories against reality. The first full sweep checked 19 stale memories and found 15 of them had drifted, and all 15 were corrected at the source. That result was what convinced me the sweep was worth building.

memdash: the curation surface

A companion dashboard, a zero-dependency Node server on the native SQLite driver, renders the memory graph and the observation log of every agent session. A few parts earn their keep:

  • A force-directed mind map of the wikilink graph, with hub sizing, orphan detection, and ghost nodes for memories that are cited but not yet written.
  • Blast radius: pick a memory and see everything downstream that becomes suspect if it turns out to be wrong, worked out by walking the inbound links.
  • A review deck that surfaces stale memories one card at a time to approve, edit, or retire.
  • A git-backed curation overlay. The underlying observation database stays read-only by doctrine, since it belongs to third-party code. Every curation act appends to an event log in its own git repository instead: retiring a memory puts it on a seven-day death row first, pardons are possible, and nothing is ever hard-deleted. Undo is just a git operation.

What it taught me

Memory quality turned out to be a data-engineering problem more than an AI one. The parts that made the difference are the unglamorous ones: typed records, freshness contracts, drift detection, audit trails, and deletes you can walk back. A model working from a small, verified memory does better than one working from a bigger, unchecked pile.