A memory editor can give me meaningful control over what an agent remembers and still tell me almost nothing about what happens when I leave the provider.
That is the harder part of persistent memory for me. Preferences, corrections, project context, and working conventions can accumulate until the memory is part of the working environment. The surrounding model, agent, or provider can change while that accumulated state remains much harder to move.
I have already treated persistent memory as a user-controlled product surface: the user should be able to inspect, correct, remove, scope, or disable durable state that will affect later behavior. There is also an earlier admission problem: what is allowed to become persistent memory in the first place.
Custody starts after both of those decisions. Once the memory exists and has become useful, what control survives if the system around it changes?
I am using ownership as operational shorthand here, not as a legal conclusion. The question I care about is narrower: can the person relying on the memory inspect it, correct it, delete the relevant layer, copy it out, move it, and understand what changes during the move?
One word hides seven controls
Labels such as local, user-owned, editable, exportable, and portable are useful, but none is a complete answer on its own.
A local memory can still be difficult to inspect or move. A provider-managed memory can offer strong visibility and deletion controls. An export can be perfectly readable to a human and still fail to preserve the structure another system needs. A repository under the user's account can preserve historical versions after the current copy has changed.
I find it clearer to separate the controls.
| Dimension | Operational question | What does not prove it by itself? |
|---|---|---|
| Custody | Where does the durable artifact live, and who controls that storage or repository? | An edit button |
| Inspectability | Can the user see the remembered material and, when relevant, enough provenance to understand it? | A generated summary that cannot be checked against underlying records |
| Correction | Can a mistaken memory be changed directly and predictably? | Asking the model to behave differently without changing the durable record |
| Deletion | What exact object is removed, and which retained layers may remain? | Deleting the conversation that originally produced the memory |
| Export | Can the memory be copied out in a documented, usable representation? | Being able to view it on screen |
| Portability | Can another agent or runtime use that representation without depending on the original system? | Possessing a backup only the original service understands |
| Migration | What survives the transfer, what is recomputed, and what meaning or provenance may be lost? | Calling a copy-paste path "migration" |
The separation matters because persistent memory is not merely stored information. It is stored information that future systems will read and allow to influence later work.
Claude shows why strong controls and provider dependence can coexist
Anthropic's current consumer-memory documentation makes several controls unusually visible. Claude users can see memory topics, edit them, or delete them. Anthropic also documents a memory import and export flow for backup or migration.
The export is textual. A user can save the memory as Claude presents it and take that text elsewhere. The import path accepts exported text, extracts key information, and stores it as memory entries. Anthropic currently describes import as experimental and warns that imported material may not always be incorporated successfully.
That is real export and a practical migration path. It still does not establish that two providers share one memory schema, preserve identical provenance, or reconstruct the same downstream behavior.
A portable representation can be useful without being lossless.
Deletion exposes the same distinction. Claude's memory and chat documentation says that deleting or expiring a conversation does not automatically remove related memory entries generated from it. Those memories can be deleted separately.
So "delete the conversation" and "delete the memory" are different operations, and this is the reason the control needs to name the object it governs.
Funes makes artifact custody concrete
Funes exposes a different architecture. Its repository describes memory as a local dataset built from agent-session traces. Parsing, chunking, embedding, reranking, and the derived memory store run locally by default, with the memory held as a local Lance dataset.
The same memory can be used across supported agents, including Claude Code, Codex, pi, and Hermes. Funes can also publish the memory to a Hugging Face dataset repository owned by the user's account or organization, which gives another machine or supported agent a durable artifact to recall from.
This is a strong form of artifact custody because the memory has an identifiable storage location outside any single coding agent. Changing the agent does not necessarily require changing the memory artifact.
It still does not collapse every other control into one.
Funes's security guidance is a useful example. If a secret reaches published remote memory, removing it in a later commit is not treated as sufficient because repository history may retain the earlier value. The documented remediation includes rotating the credential, scrubbing the local memory, deleting the remote dataset repository, recreating it, and pushing the scrubbed memory again.
The point is not that user-controlled repositories have weak deletion. It is that deletion remains layer-specific even when custody is unusually concrete.
Managed memory separates durability from custody
LangChain's current Managed Deep Agents memory documentation shows a third arrangement. Durable memory is optional and backed by Context Hub. A deployment receives a durable read/write tree that is shared across threads and, according to the documentation, every caller of that deployment. The agent can read and update the memory through file operations while LangChain manages the storage surface.
That makes two variables easy to separate.
The memory can be durable without being a user-managed local artifact. It can be writable by the agent without being scoped to one individual user. It can be shared across a deployment while still having a clear persistence boundary.
"Durable," "writable," "shared," and "user-owned" are describing different things.
That sounds obvious when written out. Product language often compresses them into one memory feature.
Export is only the first migration question
The easiest ownership test is to ask whether memory can be exported. I do not think that is enough.
There are three different questions:
- Can I get the memory out? That is export.
- Can another runtime use what I got? That is portability.
- Can I move it without silently changing what the memory means or how it behaves? That is migration fidelity.
The third question is the difficult one.
A persistent-memory system may store more than readable facts. It may also rely on categories, timestamps, provenance, confidence, embeddings, retrieval weights, ranking behavior, project boundaries, or update policies. Another system may import only a subset of that structure, or rebuild its own representation from the exported text.
Claude's text-based path is a good example of why the distinction matters. The export is useful and the import path is practical, but the destination extracts key information into its own memory representation. That is enough for a migration feature. It is not evidence of a lossless transfer of memory objects or downstream behavior.
Funes moves the portability boundary in another direction because supported agents can point at the same dataset artifact. Even there, I would still want to know what each agent recomputes, how retrieval differs, and which semantics live in the artifact versus the consuming runtime before making a stronger migration claim.
A responsible migration description should be able to say what is transferred, what is recomputed, what is dropped, and what must be reinterpreted.
The custody test I would use
I would not require every persistent-memory system to be self-hosted. Provider-managed storage can be a reasonable tradeoff when its controls and switching path fit the job. Local or account-controlled storage can be attractive when artifact custody matters, while still carrying its own retention and history problems.
What I would want is a plain answer to each layer:
- Storage: What is the durable object, and who controls it?
- Inspection: Can I see the meaningful durable state and enough provenance to understand it?
- Correction: Can I change the durable state itself rather than merely prompt around it?
- Deletion: Which exact layer disappears, and which layers may remain?
- Export: What representation do I receive, and is it independently readable?
- Portability: Which other systems can consume it, and what conversion is required?
- Migration: What is recomputed, discarded, or reinterpreted during the move?
None of those answers proves legal ownership, complete erasure, privacy, security, or lossless migration. They do make the switching cost visible before the memory becomes difficult to abandon.
That is the part I would want to know early.
Persistent memory becomes more valuable as it accumulates. The same accumulation makes it more expensive to discover that the export is only a summary, the delete button governs only one layer, or the destination cannot use the representation without rebuilding it.
I do not need a product to tell me the memory exists. But I need to know what I can take, what I cannot, and what changes when I move it.
// End of transmission. Keep the exit visible. — ZYANE