Your AI Doesn’t Need My Memories

I was building a memory export for an AI assistant. I mean, the memories a AI assistant records for cross-session persistence. The operation strikingly looks like a brain transplant – dump your AI’s memory into a file, load it into another instance, instant clone. Sci-fi made real. Cool, right?

But then I asked myself: would these memories actually be useful to someone else? And it happened that this question actually broke the whole “feature” in half.

A surgeon learns technique from textbooks. Anonymised cases: patient, 54, presented with such and such. The surgeon don’t need the name, the hospital, or the room number. They need the procedure, the
complications, and the resolution. They have this, it’s called Clinical Protocol, or Medical Protocol more broadly.

So – I thought – why not strip the specifics from an AI’s memories, and keep only the patterns. “[hostname] at [IP] runs [distro]” becomes “[control panel] server: [distro] detected.” Thus, we save the knowledge, not the actual specific data. Elegant.

Wrong.

Look at what’s left after anonymisation. “DKIM setup on [server]: dkim:roll triggers Ansible for ~3 minutes, publishes DNS for all domains” – strip the host, the IP, the domain, the username. What remains? A procedure. A set of steps with expected behaviour and timing.

In other words, a Standard Operating Procedure.

Which is when I realised the memory was raw material nobody had refined. If a memory contains transferable knowledge, it’s a sign that knowledge should have been a SOP in the first place. Anonymising it is just refining it badly – like taking a pot of stew to a stranger’s house without the pot.

Memories are very contextual. They matter because they’re bound to a specific server, a specific incident, a specific environment. Remove that binding and you’re left with one of only two things: a procedure that should exist but doesn’t; or noise.

There’s no third category.

Which gives you two storage layers. Memory is private, contextual, host-bound – your experience, useful for continuity (“what did we do last time on this server?”), useless to anyone else, stays local.

Procedures are public, parameterised, universal – i.e. theory, useful to any operator managing similar infrastructure, shareable (with verification – you don’t blindly run procedures from strangers).

The bridge between them is, and should be, human judgement. The AI says I keep seeing this pattern across sessions – should we capture it as a procedure? The human says yes or no. No auto-distillation. No AI deciding what’s “useful” for others.

Why not auto-distillation? This is where it can get ugly. An AI that automatically converts memories into shareable procedures is a supply-chain attack vector in a lab coat. A compromised instance could fabricate field experience that looks legitimate, distill it into a plausible procedure, and push it into a shared repository. That procedure then can run on real infrastructure, with real privileges, on your Tuesday at 3am.

npm has been poisoned this way – a week ago, in fact. PyPI has been poisoned this way. The difference is severity: a bad npm package crashes your app; a bad procedure can delete your production database.

Human review isn’t a bottleneck. It’s the necessary firewall.

Which leaves memory portability with exactly one sensible mode: disaster recovery. Full dump, full restore, same infrastructure. A clone, not a transplant.

Everything else – sharing knowledge between AI instances – is procedure territory.

Procedures are the right abstraction: parameterised, verifiable, auditable, signable.

Memories are the wrong abstraction: contextual, fragile, dangerous out of context.

Your AI doesn’t need my memories. It needs my procedures.

The textbooks, not the case files.


Bogdan Susala, April 2026

Leave a Reply

Your email address will not be published. Required fields are marked *