Memory in files, not in chat
In May 2026 I started a Git repository called Work Memory. It's a folder of Markdown files that my agents read and write, and five months later it has about eleven hundred pages and fifteen hundred commits, nearly all of them made by Codex or Claude. It's the single most useful thing I've built for working with agents, and the reason is boring. It's files.
The problem it solves
I run a lot of work in parallel. On a normal week there are somewhere between fifteen and twenty streams open at once, each in its own pinned Codex thread or Claude Code session, and I move between them constantly. The problem with a chat is that it’s an unreliable place to keep anything durable. You come back to a thread three days later and the agent has lost the context, or you’ve lost it, or the thread has been compacted and the decision you made on Tuesday is now a one-line summary that says the opposite of what you meant.
The rule I set for my agents early on was blunt: assume Donal will remember nothing from the previous session. If that’s true, then anything worth keeping has to be written somewhere a fresh agent can find it, in a form I can read and diff.
What it is
Three kinds of file, in order of trust.
Raw sources are things captured from outside: papers, vendor docs, meeting notes, scraped pages. They’re treated as immutable. You add to them, you don’t rewrite them.
Wiki pages are the compiled layer: runbooks, architecture notes, research syntheses, and a ledger per active stream of work. These are the pages an agent is allowed to maintain, and they cite the raw sources.
Everything else is derived. Indexes, search results, pointers, briefings. If a derived view and a file disagree, the file wins and the index gets regenerated. That rule is decision number one in the repo and it has held up.
On top of that there are three lifetimes. Scratch lives in a tmp folder and is not memory. Current work lives in a dated folder with a review date thirty days out, and at review it gets promoted to durable, archived, or deleted. Durable pages are runbooks and decisions that are meant to last. The middle lane was the important one to get right. Without it the wiki either loses the context of live work or turns into a junk drawer.
The rules that made it work
The first rule is progressive disclosure. The wiki is meant to make agents more capable, not heavier. An agent does a cheap relevance check first, opens one narrow page if there’s a clear match, and otherwise gets on with the task. It does not load the index, the status page and five wiki pages at the start of every session. Missing a marginal note is better than putting thousands of irrelevant tokens into every run.
The second is that every write is a transaction. When an agent saves something durable it routes the file, validates the frontmatter, regenerates the index, makes a scoped commit containing only the paths it owns, and pushes if it safely can. If it can’t push it records that and moves on. I don’t maintain the index, the inbox folder, the logs or the commits. That’s the agents’ job, and the skill that does it is the same one in Codex and Claude.
The third is that private memory stays private. Work Memory is mine. It never gets linked from a shared issue or PR. If a finding needs to go to the team, the agent extracts the relevant non-sensitive part and writes it directly into the shared place.
The Chief of Staff
Once the files existed, the obvious next step was something that reads them for me. The Chief of Staff is a pinned Codex task whose job is stand-up: read the stream ledgers, say what moved, what’s waiting on me, what’s gone stale, and what the next coherent move is on each stream. It writes nothing to GitHub. It reads the organiser that the other agents maintain and gives me a short attention list.
That’s the shape I’ve come to trust. Working threads do work and write files. One thread reads the files and tells me where to look.
Dropping the clever bit
For most of the year Work Memory also had a hosted semantic layer beside it: a database, embeddings, a delivery queue, the whole thing. In October I asked whether it was earning its place. Two fresh agents answered the same six practical questions, one with plain file search and one with the semantic layer as well. They got the same five answers. The semantic layer gave useful starting pointers in three cases and no extra verified information in any of them, and four of its cases still ended in a file search.
So I took it out. Small trial, not a proof about vector search in general. But it was enough to stop paying for a service that a grep was matching.
What I’d say about it
Most of the value came from two decisions that cost nothing: files are canonical, and agents own the housekeeping. Everything after that was tidying. The system is inspired by Jason Liu’s idea of durable threads with memory as files, and Karpathy’s LLM-maintained wiki, and the thing both of them got right is that text in Git is the cheapest memory a human and an agent can both reason about.