A memory is not a record
· Prabhu Eshwarla
Why memory and evidence have opposite requirements, and why the thing an agent remembers should not be the thing you answer with.
A new kind of product has appeared over the last few months: portable memory for AI agents. Walrus Memory is the clearest example I have looked at. Your agent's memory is encrypted, stored on decentralised storage, and owned by a keypair rather than by whichever vendor you happened to start with. Access rules live in a smart contract instead of in terms of service, so nobody can change them on you or lock you out.
That last part is a genuinely good idea and I have not seen it anywhere else. It also made me go back and reread something I wrote in July, where I said that the memory a personal agent needs is the memory a business agent cannot have. I still think the argument in that piece is right. I drew the line in the wrong place.
What I got wrong
The July position was that accumulating memory is the wrong design for a business service, and that Forge deliberately does not do it. Stated that flatly, it sounds like a business agent should not remember anything, which is both impractical and not what I meant.
An agent doing real work accumulates all sorts of things. Where it is in a task. What it already tried. That this particular customer prefers email. That the file it needs is named oddly. Which approach failed last time. None of that is dangerous and all of it makes the agent better. Telling someone their agent cannot have a scratchpad is not governance, it is just an unhelpful product.
The honest version of the argument is narrower, and it turns on a distinction I did not have language for in July.
Memory and record are different artifacts
A memory exists for the benefit of the thing that holds it. The agent remembers so that it works better next time. Everything about a good memory follows from that: it can be summarised, compressed, reorganised and partly forgotten, and usually those are improvements rather than losses. Nobody minds that you remember the gist of a meeting rather than the transcript. The gist is more useful.
A record exists for the benefit of somebody else, usually later, usually under pressure. It is how an organisation answers for what happened. Everything about a good record follows from that too, and it is the opposite list: it cannot be summarised, cannot be compressed, cannot be reorganised after the fact, and the moment any of that becomes possible it stops being evidence and becomes a story about the evidence.
Put those two lists side by side and it is obvious they should not be the same system. One is optimised for useful recall. The other is optimised for completeness and for being hard to change. A system that does both well is not a clever synthesis, it is a system that has quietly stopped doing one of them.
This is also why I would be careful with a product that offers to be both. The features that make a memory good are precisely the ones that would make a record inadmissible.
So where is the line
The question that sorts anything an agent touches is: who is this for?
If it is for the agent, so that it does the work better, it is memory. Keep it wherever is convenient. Keep it in a portable layer if portability matters to you, and the case for portability is real: engineers do move between providers, and rebuilding context every time is a waste.
If somebody might one day have to answer with it, it is a record. That belongs somewhere the organisation controls, and it has a much shorter list of requirements than people expect. It needs to be complete, it needs to be hard to alter, and it needs to say where every claim in it came from.
What that means in practice is that the governed part of an agent's working life is smaller and more specific than the phrase "agent memory" suggests. Two things, really.
The first is the material the organisation is accountable for. Client files. Case notes. Employee records. Contracts. The things that belong to somebody who did not choose to be in your system. The agent should reach those through something that decides what it may see and records every time it sees it. Not because the agent is untrustworthy, but because the organisation is accountable whether or not the agent was.
The second is the record of what was done to that material. Not the agent's internal reasoning, which is its own business, and not its prompts, which are the developer's. What was read, what was computed, what was produced, and who approved it before it went anywhere.
Everything else the agent can keep where it likes.
Why this is not a smaller claim than it sounds
It would be easy to read this as a retreat. Agents get memory after all, and the governed part shrinks to a corner.
I think it is the opposite. The reason "agent memory" is hard to reason about is that the word covers four or five unrelated things, and the moment you separate them the hard part gets small enough to actually solve. The scratchpad does not need governing. The preference that this customer likes email does not need governing. What needs governing is a short list, and a short list can be done properly.
It also means the two kinds of product can stop pretending to compete. A portable memory layer and a governed record are solving different problems for different people, and an agent will sensibly use both. The memory makes it work well. The record makes it something an organisation can let near real material.
The test
If you are building agents inside an organisation and want one question to sort this with, I would use this one.
Would you be comfortable if this were summarised?
If yes, it is memory, and summarising it will probably make it better. If the thought makes you uneasy, you are looking at a record, and it needs to live somewhere that cannot summarise it.
