Memory With a Chain of Custody
Your review agent learns something worth keeping: the API version has to match in three places, the client, the server and the docs. It writes that down where your other agents can read it. Months later a coding agent, on a different runtime, finds the note, bumps the client and edits two more files to match. Every edit follows the note exactly, and the note is word for word what was learned. What it never carried is where it was learned — a branch abandoned in April, in files that are gone. Nothing failed. The memory simply outlived its evidence.
Nothing gets lifted on trust alone
On a building site the lifting gear hangs on a rack: chains, slings, shackles. Each has a number stamped into a metal tag, and that number matches a certificate saying which steel it came from and which test it passed. Before a load goes up, the man rigging it reads the number and checks it against the register. Nobody grades a sling by eye. A sling that cannot be identified is not a doubtful sling; it is scrap, and it gets cut in half so it cannot find its way back onto the rack.
The stamped number is half the idea. A fact worth keeping across sessions is stored as a small discrete object under a stable key — one fact, its metadata, an address you fetch it by — rather than a sentence buried in the summary of a conversation. The agent asks for the object called deployment approval threshold and gets the current entry in one lookup. It also sits where summarisation cannot reach: accumulated constraints erode first every time a summary is folded again.
The certificate is the other half. A stored fact carries citations, the files and lines it was read off, and the runtime reads those lines again before the fact influences anything. Agree, and the memory is refreshed. Diverge, or find the path gone, and what gets written back is a correction. It runs on an asymmetry: curating a memory store perfectly offline is hard, checking three citations against live code is cheap.
A stale fact acts with full confidence
This is where memory stops being storage. A person reading an old note hesitates, checks the date, asks somebody. An agent does not hesitate. It acts. So the failure is not a wrong answer you can spot; it is a careful, correct action on behalf of a system that no longer exists. The note says the endpoint is on version one, the project moved to version two, and what you get is clean code doing the wrong thing on purpose.
The rules cannot live in the model’s good intentions, then. When two memories disagree, the tempting rule is that the newer one wins, and that is how a remark somebody dropped last week outranks a fact with three verified citations under it. Recency is evidence about time, not about truth. What settles it is provenance: who wrote the entry, off what, and whether the source still says so.
Custody has an edge, too. A memory learned inside one client’s repository and served to an agent working for another has crossed a boundary the code itself was never allowed to cross. Memories should inherit the permissions of what they were read off. What you are deciding is not how much your agents may remember, but what they may act on unsupervised, and how far it travels.
Facts have to be destroyed on schedule
The gear on that rack gets examined every six months, and whatever fails or is past its life is destroyed on the day, whether or not it looks fine. That is not a judgement about the sling; it is a rule that runs regardless of judgement.
Memory needs the same layer: explicit rules for retention, decay, conflict and privacy, enforced outside the weights and outside the model’s willingness to cooperate. When the project source moves to the new version, a rule revokes the old entry and stops it coming back as live knowledge, instead of letting it drift into every window that queries the store. Data a customer asked you to erase has to be erased where it is held, not left unmentioned. Telling a model to forget something is a request, not a deletion.
Which is why this belongs to a service outside the session, holding user, session and agent facts between runs, correctable and erasable by something other than the agent that wrote them. Once several agents read the same store, what a summary throws away stops being your largest risk, and what it keeps without a source becomes the larger one. A fact nobody can trace back is not memory. It is a rumour your system has learned to repeat.