Two kinds of memory, two kinds of trust
Agent memory is usually discussed as one thing. It is at least two, and they fail differently:
- Working memory. The context window: the current conversation, the files in front of the agent, the immediate task. Complete and fast, and gone the moment the session ends or the window fills. Nothing survives here by accident.
- Recalled long-term memory. Summaries, notes, stored facts, and embeddings kept between sessions. This layer persists, but it is written by the agent about itself, it can be edited or overwritten, and every summary is a lossy retelling. A later session reads it and believes it, because believing is the only option it has.
- The execution record. One receipt per tool call, saved by the executing layer at call time: the tool, the arguments, the exact result bytes and their hash, the timestamp. This layer also persists, but with a property the other two lack: a later session does not have to believe it. It can recompute the hashes and check.
Recall systems answer "what does the agent remember?" The record answers the harder question underneath every continuity feature: which parts of that memory can be checked against the record made when the work ran?
What persistence actually requires
Storing text is easy; every chat product does it. Persistence that a later session can rely on has four requirements, and most memory layers meet only the first:
- Storage outside the session. The memory must live somewhere the session ending does not erase, and outside the agent's own control, so the system being remembered cannot rewrite its past.
- An open format. If the record is locked in one product's schema, persistence lasts exactly as long as the product does. Receipts in the AER-1 format, an IETF Internet-Draft (draft-zambo-aer1-23), can be read and checked by any tool, with public test vectors and independent implementations.
- Retrievability by a different reader. The next session may be a different AI entirely. The record has to be fetchable and checkable without the first AI's account, session, or cooperation.
- A verification step. Persistence without recompute is just old text. The later session recomputes each receipt's hash over its saved result, and only then treats the remembered work as done, the same procedure the receipt verifier walkthrough demonstrates on a live receipt.
How the record layer works across sessions
Concretely, with work running through Zambo's executing layer: session one runs its calls, and each call leaves a receipt as it executes. A multi-step run closes under a single workflow commitment computed from the step receipt identifiers, so the session's recorded work is one checkable set. Session two, whether it is the same AI tomorrow or a different AI in ten minutes, pulls the record, recomputes it, and starts from the recorded state: the calls on record, the results saved with them, unchanged since they were saved, and any claimed step the record does not contain, treated as not yet done.
That is the mechanism behind cross-AI memory and behind session continuity: the history of completed calls is carried by records rather than retellings, each result saved at call time in a form later sessions can check, so it survives the session, the product, and the switch.
Start the record your next session will inherit
- See one receipt: the live demo runs a real call and hands you its verifiable receipt, no signup. That receipt is still checkable in any later session, by anyone.
- Receipt a whole run: connect an agent over MCP at zambo.dev/mcp and every call leaves a receipt as it executes. A Day Pass ($0.99) keeps a full day of runs receipted and seals a closed run so its record stays put.
- Keep it portable: the receipts follow AER-1, an IETF Internet-Draft (draft-zambo-aer1-23), so the memory layer outlives any single AI, session, or tool.
AI agent memory across sessions: FAQ
What is persistent AI agent memory?
Persistent AI agent memory is whatever an agent can still access after the session that created it ends: notes, summaries, stored facts, and records kept outside the context window. The word persistent describes storage, not trustworthiness. A stored summary persists, but it can be edited, mis-summarized, or written by the agent about itself. Underneath whatever an agent recalls, the layer a later session can actually check is the execution record: one verifiable receipt per tool call, saved by the executing layer at call time, that any later session can recompute against what was saved. It persists as evidence, not just as text.
What is long-term memory for AI agents?
Long-term memory for AI agents is the layer that carries knowledge between sessions: user preferences, project facts, decisions, and the history of work done. It contrasts with working memory, the context window, which holds only the current conversation and is discarded when the session ends. Long-term memory is usually built from summaries the agent writes, which makes it useful and fallible in equal measure. Pairing it with an execution record gives a later session something to check that summary against for completed work: the summary says what happened, and the receipts hold the saved results of the calls, unchanged since they were saved at call time.
How do I keep memory across different AI assistants?
Keep the memory outside all of them. If your history lives inside one assistant's account, switching assistants means starting over or trusting an export of prose. The portable pattern has two parts: your context and preferences in files or stores you control, and an execution record in an open format that any assistant can read and check. Receipts in the AER-1 format, an IETF Internet-Draft, work this way: a call made while you were using Claude leaves a receipt that ChatGPT, Grok, Gemini, or Cursor can verify later, because verification is recompute, not access to the first assistant's account.
What is the difference between working memory and long-term memory for AI agents?
Working memory is the context window: the current conversation, the files in front of the agent, the immediate task. It is fast, complete, and temporary; when the session ends or the window fills, it is gone. Long-term memory is everything kept outside the window for later sessions: summaries, facts, preferences, and records. The design question is what earns a place in long-term memory and in what form. Facts and preferences can live as text. Completed work should live as verifiable receipts, so a later session checks what was done instead of re-believing a summary of it.
What is external memory for AI agents?
External memory is any memory stored outside the model itself: databases, files, vector stores, and record layers the agent reads from and writes to. All long-term agent memory is external in this sense, because model weights do not change between your sessions. The useful distinction is who controls the store and whether its contents can be checked. An external record layer that saves one receipt per executed call, under hashes the agent cannot rewrite, gives later sessions something stronger than recall: a record of the work they can verify. An external store the agent can freely edit gives them memory they can only trust.
What is the best persistent memory for AI agents?
Judge persistent memory by three tests. Survival: does it live outside any single AI's account, in a format that outlasts the tool? Control: can the agent whose work it describes rewrite it? Checkability: can a later session, or a different AI entirely, check a remembered claim about completed work against the record saved when the work ran, by recomputing it rather than re-reading it? Summaries and embeddings pass the first test and fail the other two. A verifiable execution record passes all three for the work it covers, which is why the record belongs underneath whatever recall system an agent uses.