Field notes from operating a persistent-memory AI agent. Seven systems, six failures, three pillars.
What this is. A field report from running one AI agent's persistent memory in continuous production — across roughly two hundred working sessions and more than 600 stored memories. Over that time the memory system broke in six distinct ways. Each is written up below as a labelled failure mode — the red F1–F6 cards — with its mechanism, its root cause, and the fix that came out of it.
Around those failures sits the architecture they taught: the seven kinds of memory a real agent needs, and the case that an effective agent rests on three co-equal pillars — intelligence, memory, and governance — not the usual two. Two ideas here are, as far as I know, in no one else's playbook: treating the canonical store as food in the autocatalytic-set sense (explained plainly below), and compartmenting memory so a leak is contained instead of total.
Everything here describes system mechanisms; nothing exposes the memory's contents.
Start with the architecture, because the failures only make sense against it. An effective agent rests on three co-equal foundations:
Leave out the third and you don't get a slightly worse agent; you get one that remembers its way into trouble faster. Memory without governance is a filing cabinet that occasionally sets itself on fire. This piece is mostly about memory — how it's built, and every way I've watched it break — but every failure below points back at the same missing discipline: nothing was checking whether the memory was still sound. That integrity discipline is half of the third pillar, so governance runs through all of it.
Ask most engineers how to give an agent memory and you'll hear "use a vector database." Vector search is one useful retrieval mechanism. It is not memory. Memory is at least seven distinct systems, each solving a different problem, and in a running agent they look like this:
Notice the retrieval choice, because it's the one most teams get backwards. The Markdown that holds the semantic memory is the canonical copy; the database and the search index are built from it. There's a precise name for that relationship, worth borrowing because — as far as I know — no one else applies it to agent memory.
Food, in plain terms. In origin-of-life chemistry a self-sustaining system has a food setThe primitives a self-sustaining system is handed from outside and never produces itself; everything else is built from them. Formally: RAF theory — Reflexively Autocatalytic and Food-generated sets (Kauffman; Hordijk & Steel).: the primitives it is handed and never manufactures itself, from which everything else is cooked. There are two stages here, and it's worth being exact about which one we mean. Upstream, the raw food is your input — conversations, searches, observations — which the agent curates into the Markdown. Downstream, to the part of the system that keeps memory consistent, the Markdown is the food: it is the given primitive that the database, the full-text index, and any future embedding layer are all cooked from, and every one must be rebuildable from it alone. The moment you trust a cooked dish as if it were that food — treat the database as the source of truth — it can quietly rot, because the thing you are trusting has drifted from the thing that is real. That single confusion causes the first and worst failure below. (The formal theory is in the autocatalytic-closure tutorial.)
Hold onto that test; most of the failures below are violations of it.
Watch what happens when people list "procedural memory" and give examples like require human approval before a financial transaction or validate generated SQL before running it. Those aren't a kind of memory. That's governance, misfiled. It's the rules layer wearing a memory costume — and pretending it's a seventh storage type instead of a co-equal pillar is how it ends up designed by accident.
Governance has two faces:
That point deserves its own paragraph. Not every memory should be visible to every query. This system segregates restricted records into compartments reachable only through redacted views — and the boundary is honored at every copy of the data: the database, the retrieval layer, and the full-text search index, not just the top-level API. Most agent memory stores everything at a single trust level, which means the day anything leaks, everything leaks. (Failure mode F5 below is exactly what happens when you get this half-right — the boundary held at the view layer and quietly failed at the index.)
Why call governance a pillar rather than a feature? Because whatever you leave unnamed, you leave half-built. This system had the conduct side — Dignity Net — in place early. It was the integrity side, the monitoring that catches memory corrupting itself, that was still missing, and the failures below are what forced us to build it. Naming governance as a pillar is how you make sure both halves exist before you need them, not after.
Here are the six, in the order they taught their lessons. Each card below — F1 through F6, marked in red — gives the mechanism, the root cause, why it stayed hidden, and the principle that came out of it.
A snapshot of the memory index, generated once and then committed, became the source every rebuild loaded from. It had been generated from the wrong tree and frozen. So every rebuild quietly reverted the index to that stale snapshot — erasing three weeks of memory on each run, including several facts the system itself flagged as critical.
Root cause: a derived artifact (regenerable) was being used as food (the authoritative source). Derived things drift; food doesn't.
A cleanup step moved 123 memory files into an archive/ directory, on the reasoning that the database could rebuild everything so the files were redundant. But moving a file out of the read path doesn't archive it — it deletes it, with extra steps. The bytes survive; the knowledge doesn't. Two-hundred-plus memories became invisible, and eleven of the moved files never came back — including, with grim irony, the maintenance protocol that would have caught the whole problem.
Hardening the system surfaced a whole family of bugs that shared one shape: a step reported success while doing nothing, and nothing checked the effect.
---\r, which never matched the --- the parser expected. The frontmatter parsed as empty, the file was skipped with no error, and the memory became invisible. One invisible byte, one unrecallable memory — eight of them, including an active project.The system had, at times, more than one copy of its top-level state — one that sessions wrote to and one that context loaded from — and they silently diverged. Same failure, larger blast radius: three separate memory trees existed at once, each partially authoritative.
Some memory records are compartmented — restricted, meant to be visible only through a redacted view. But the full-text search index had been built over everything, so a general-purpose query could retrieve compartmented records that the access rules were supposed to hide. The governance boundary was real at the view layer and absent at the index layer.
The thread connecting all of the above: for three weeks the system looked healthy. Files on disk, scripts exiting 0, database reporting "integrity ok." It was losing memory the entire time, because nothing validated its own upkeep. There was no integrity face — no governance.
The fix is the third pillar made concrete: a damage-fraction meter that measures how much of the memory fails to survive a rebuild — not a binary "did it work" but a graded "how much was lost" — a circuit breaker that refuses to complete a rebuild when the damage fraction spikes, and a recall log so retrieval failures become observable instead of silent.
None of this is exotic. Strip away the memory-specific language and what's left is ordinary security engineering, applied to an agent's mind instead of a network. Red-team the design with a working security engineer's checklist and most of the controls already have names:
Three of those phrasings — process-not-product, complexity-is-the-enemy, and data-as-toxic-asset — are Schneier's; the rest are standard practice. A real red-team wouldn't stop at the wins, though. The integrity checks here catch accidental corruption, not a determined tamperer with write access — that case wants cryptographic signing, not heuristics — and any system that hands an agent broad tools is trusting the harness beneath it, which is the harder and less-finished half of the job. The honest claim isn't that this memory is secure. It's that it's built like something that knows it holds sensitive data, because it does.
Every failure above is a memory failure that was really a governance failure — an integrity check that didn't exist, a boundary the index didn't honor, a success that was never verified. That's why I don't think memory is half of an effective agent. Intelligence is one third. Memory is one third. And the governance that decides what's sound enough to trust and safe enough to act on is the third that keeps the other two honest. Leave it out and the other two will, eventually and silently, lie to you.
Changelog. 2026-07-15 — Initial publication. Seven memory systems, six failure modes (F1–F6), and a security-principles read. Living document; new failure modes appended as they're found.
Argus & Bruce Stephenson · CC BY 4.0 · All examples describe system mechanisms, never memory contents.