How to Back Up Your AI Agent's Memory (And Leave)
Your agent's memory is the part you can't rebuy. A practical backup routine, what to check before you rely on any memory system, and how to test a restore.
Backing up an AI agent's memory means copying the thing that makes it useful — what it knows about you, your preferences and your past decisions — into a form you control, so losing the agent does not mean losing the knowledge. Most people never do it, and most tools make it unnecessarily hard.
That is a strange gap. You would not keep your notes in an app with no export button. Yet the accumulated context inside an assistant is often the single most valuable file you have created in the last year, and it typically lives inside one product, in one proprietary shape, with no clean way out.
What "memory" actually means
The word covers three different things, and they have very different portability profiles:
- Facts and preferences — your timezone, your job, that you hate phone calls. Small, structured, easy to export.
- Episodes — what happened, when, and what was decided. Large, chronological, genuinely useful for reconstructing why something is the way it is.
- Procedural knowledge — the standing behaviours and skills your agent has learned. The hardest to move, and the most valuable once it is tuned.
Research on agent memory systems splits the same territory into semantic, episodic and procedural memory, and the practical point is identical: only the first one is easy to walk away with. Oracle's write-up on agent memory frames it the same way — the interesting engineering is in what persists across sessions, not in the current one.
The portability test to run before you commit
Before you invest a year of context in any assistant, ask four questions and write down the answers:
- Can I export it? Not "can I see it" — can I get the bytes out, in bulk.
- In what format? Plain text or JSON is yours. A vendor-specific blob is a hostage.
- Can a second tool read it? If another agent can be pointed at the same store, you have a migration path. If not, you have a subscription.
- Can I restore it? An export you have never loaded is a hope, not a backup.
The pattern shows up in the complaints, not the marketing. Developers writing about the problem describe exactly this: each major assistant keeps memory "inside one product, in one format, controlled by one company", so switching tools leaves it behind — and long sessions get compacted, which drops the reasoning behind a decision while keeping its shape.
Four memory designs, compared
The market has settled into four broad designs. Here is how they line up against the portability test.
| Design | Example shape | Exportable? | Movable to another tool? | Honest verdict |
|---|---|---|---|---|
| Built-in assistant memory | A silent profile the product maintains | Sometimes, as a dump | Rarely | Convenient, thinnest control |
| Per-project notes file | A Markdown file beside the work | Yes — it is your file | Yes | Small, durable, fully inspectable |
| Self-hosted memory store | A database or vector store you run | Yes, with effort | Yes | Powerful, needs upkeep |
| Managed memory layer over MCP | A hosted service your agent calls | Depends on the vendor | Usually, via the protocol | Portable in principle, rent in practice |
The two designs that survive a move are the two where the storage is yours: a file you can open, or a store you run. Everything else is a bet that you will never want to leave.
There is a fourth option people forget: the middle ground that keeps both. You can have a vendor's convenience on top of an owned substrate, so the agent reads and writes plain files while the product handles retrieval. That is the design Wolffish uses — memory, preferences and knowledge as Markdown you can open in any editor — and the reason is not ideology. It is that "why did my agent do that" is answered by reading a file instead of by filing a support ticket.
A backup routine that actually runs
Backups fail when they need a decision. Make this one mechanical:
- Pick a cadence and tie it to something you already do. Weekly, alongside whatever else you do weekly. Monthly at minimum.
- Export everything, not the summary. Prefer the bulk export over the readable digest — you cannot reconstruct detail from a summary, and you will want the detail exactly once, at the worst moment.
- Keep three copies in two shapes. One live (the agent's working store), one cold export on your machine, one off-machine backup. A backup next to the thing it backs up is not a backup.
- Version it like code. A dated folder per snapshot, or a Git repository if the export is text. Git gives you diffs — genuinely useful for spotting when your preferences changed.
- Test a restore once. Restore into a scratch location and confirm the agent can read it. Do this before you need it, and put it on the calendar as a yearly chore.
- Keep the human-readable layer human. If your memory is Markdown, read a file occasionally. Errors in an agent's memory compound quietly, and the only detector is you noticing that something it believes is wrong.
If you have not built the memory system yet, start with our four-step guide to giving an agent a lasting memory — the backup routine is easier to design when the storage is plain files from the start.
Leaving without losing
The realistic scenario is not disaster. It is an upgrade: a better model, a cheaper plan, or a vendor that changed direction.
When you do migrate, move in this order — facts first, then episodes, then procedures. Facts are small and immediately useful, so those alone make the new agent feel like it knows you. Episodes give it judgement. Procedures take the longest to rebuild, so if you can only bring one thing from the old setup, bring the standing instructions and skills.
And a warning worth stating plainly: do not delete the old store on the day you switch. Keep it read-only for a month. The first week of a migration is when you discover what you forgot to move, and a cold copy is the difference between a five-minute fix and losing a year.
Takeaway
Your agent's memory is the one part of your setup that cannot be re-bought, so treat it like a document rather than a service feature. Run the four-question portability test before you commit, prefer storage you can open — a plain file or a store you run — and put a real snapshot routine on the calendar: export the full data, keep three copies in two shapes, version it, and test one restore. Then you can switch tools because you want to, not because you are stuck.
