What is persistent memory for an AI agent?

Information an agent can still use after the current conversation ends, retrieved at the start of the next one. The useful test is not whether something is stored but what it survives: the session, the machine, the application, the model, and the provider.

Is a bigger context window the same as persistent memory?

No. A context window is working attention for a single request. It is re-read and re-billed on every turn and retains nothing once the session ends. A larger window makes longer conversations possible; it does not make anything persist.

Why does my agent forget between sessions?

Because the conversation was the only place that information existed. Unless the agent wrote it to a store outside the session, the session ending is the information ending. Connecting a memory server is what changes that.

Does persistent memory reduce token cost?

Usually, because it replaces the re-briefing you would otherwise paste into every session. Pasted context is re-read on every turn for the life of the conversation; a short retrieval at the start is not.

Will my memory survive changing to a different AI model or vendor?

Only if it is bound to you rather than to the application. Memory kept inside an assistant's account is persistent within that assistant and does not follow you out of it. Memory held under your own key and read through an open protocol does.

Should persistent memory keep everything forever?

No. A store that only grows degrades: superseded facts compete with current ones and the agent applies constraints you removed. Write decisions and reasons, supersede facts when they change, and erase what should not have been recorded.

How can memory be both durable and erasable?

Durability works by making copies, which is exactly what makes deletion unreliable. Sealing each memory under its own key resolves it: destroying the key leaves every remaining copy as unreadable ciphertext, so the copies do not have to be found.

What happens if I lose my key?

The memory sealed under it cannot be recovered, by you or by anyone operating the protocol. That is the same property that keeps operators out of your memory, seen from the other side, so backing up the key file is a genuine step rather than a formality.

Persistent memory for AI agents

Persistent is a word most memory products use and few of them qualify. The useful question is not whether something is stored, but what it survives — the session, the machine, the application, the model, the vendor.

The five things it must survive → Start free →

The problem persistence is meant to solve

An agent without persistent memory is competent inside a conversation and blank between them. You describe your architecture, your constraints, the decision you made last week and why you rejected the obvious alternative. The agent works well. The session ends. The next session begins with an agent that has never met you.

The cost of this is easy to underestimate because it is paid in small installments. Every session opens with a re-briefing. Every re-briefing is incomplete, because you do not remember everything you said last time and you certainly do not remember the reasoning you rejected. So the agent re-proposes discarded approaches, re-asks settled questions, and re-derives conclusions you paid for already. The work is not wrong; it is repeated.

There is a second cost that is easier to measure. Everything you re-explain enters the context window, and everything in the context window is re-read on every single turn of the conversation. A briefing you paste at the start of a session is not paid for once — it is paid for again on each subsequent message, for the life of that session, on every session. Persistent memory replaces that with a short retrieval at the start.

And there is a third cost that only shows up later: the reasoning is not recoverable. Chat transcripts are a poor archive. Nobody greps six months of conversation to find out why a library was rejected. The decision is simply re-litigated, usually to the same conclusion, occasionally to a worse one.

What persistence actually has to survive

Products described as having persistent memory usually survive the first item on this list and go quiet about the rest. Working through them in order is the fastest way to evaluate any offering, including this one.

Must survive	What breaks it	Commonly survived?
The session	Closing the conversation; a context reset	Yes — this is table stakes
The machine	A rebuild, a new laptop, a second device	Only if the store is not a local file
The application	Changing agents, changing IDE, changing vendor	Rarely — most stores belong to the app
The model	A model deprecation or a switch to a better one	Only if memory is not held inside the model’s product
The provider	A shutdown, an acquisition, a pricing change, an account closure	Almost never

The last three are where the word does most of its hiding. Memory stored inside an assistant’s account is genuinely persistent within that assistant — and evaporates the moment you want a different one. That is not dishonest marketing so much as an unstated scope, but the scope is the part that determines whether your memory is still there in three years.

The provider row deserves particular attention because it is the one nobody plans for. This is a young market. Some of the memory products in it today will be acquired, repositioned or shut down. “Persistent” that depends on a company’s continued existence and continued interest is a bet on that company, whatever the storage engineering underneath it looks like.

The property that decides all five: what the memory is bound to

Every row in that table resolves to a single architectural choice, made once, early, and effectively unchangeable afterwards: is the memory bound to an application, or to you?

Bound to an application means the store belongs to the product. Your memories are rows in its database, addressed by its account identifiers, readable through its interface. Persistence is then exactly as durable as your relationship with that product. An export feature, where one exists, gives you a file — not working memory in the next agent.

Bound to you means the memory is held under a key that is yours, in a form defined by an open protocol rather than a product. Any agent that speaks the protocol and holds the key reads the same memory. Switching agents is not a migration; the new agent reads what the old one wrote, on its first run, because there was never anything application-specific about the storage.

This is why the custody question and the persistence question are the same question wearing different clothes. If somebody else holds your memory in readable form, they also hold the ability to lose it, gate it, price it or discontinue it. Sealing memory under your own key is what makes durability a property of the data rather than a promise from a vendor. Agent memory works through the custody side of it in full.

Persistence is not hoarding

A memory that only ever grows becomes useless in a way that is slower and less obvious than a memory that forgets everything. Recall degrades as the store fills with superseded facts, and the agent starts confidently applying a constraint you removed two months ago. Persistent memory is a working record, not an archive, and it needs the same discipline any long-lived record needs.

Three habits carry most of the value, and none of them require special tooling.

Write decisions, not transcripts. The durable unit is a conclusion and the reason behind it. “We use X because Y, and rejected Z because W” stays useful for years. A blow-by-blow of how you got there does not, and it crowds out the things that do.

Supersede rather than accumulate. When a fact changes, replace the old one. Two contradictory memories do not average out; they make the agent unpredictable, and you will not know which one it used.

Erase what should not persist. Some things are recorded that should not have been — a credential pasted in passing, a third party’s personal data, a client engagement that has ended. A persistent store without a real erasure path accumulates liability at the same rate it accumulates value.

That last habit is the one with a hard technical requirement behind it, and it is the subject of the next section.

Durability and erasure pull in opposite directions

This is the tension at the center of persistent memory, and most systems resolve it by hoping nobody notices.

Making data survive means making copies: replicas for availability, snapshots for recovery, backups for disaster, caches for speed, archives for audit. Good durability engineering is the practice of creating copies you never have to think about. It works, and it is why your data is still there after a disk fails.

Erasure means the content must stop existing. Against a system engineered to make copies you do not have to think about, a delete request has to reach every one of them — including the ones in cold storage, the ones on a replica that was offline during the deletion window, and the ones in a backup taken an hour before you asked. In practice a delete removes the live row and leaves that set behind. The record is gone from the interface, which is not the same as gone.

SAIHM resolves this by making the copies harmless instead of chasing them. Every memory is sealed under its own key. Erasing destroys the key, and the ciphertext — wherever it has spread, however many replicas exist, including ones nobody can enumerate — becomes unreadable to everyone, the operator included. Durability and erasure stop competing, because the thing that has to be destroyed is small, singular, and under your control.

The consequence worth stating plainly: this makes erasure genuinely irreversible. There is no support ticket that recovers it. That is the correct behavior for an erasure primitive, and it is why the operation is scoped to when erasure is the intent rather than used to tidy a working set.

How SAIHM handles persistence

SAIHM is a memory protocol rather than an agent or an application. It stores nothing readable, and it is not the thing you talk to.

Survives the session: Memory is written when something is decided and retrieved at the start of the next conversation.
Survives the machine: Storage is distributed rather than a file on one device. A new machine with your key reads the same memory.
Survives the application: The interface is an open protocol, so a different agent reads what the previous one wrote.
Survives the model: Memory is not held inside any model’s product, so a model switch or deprecation does not touch it.
Survives the provider: The protocol is Apache-2.0 and the memory is sealed under your key, so no operator holds readable content or a lock-in point.

The honest limit, stated where it belongs rather than in a footnote: because the storage side holds no plaintext, features that require a server to read and reason over your content are constrained by design. If server-side semantic ranking over your memory corpus is the requirement, a hosted memory service is the right architecture and this one is not. The decision matrix lays that choice out as a decision tree, including the cases where the answer is not SAIHM.

One further requirement follows from binding memory to a key rather than an account: the key is yours to keep. Nobody can reissue it, because nobody else has it. That is the same property that keeps the operator out of your memory, seen from the other side, and it means backing up the key file is a real step rather than a formality.

Start free

The free tier needs no card, no wallet and no crypto. Tell your agent “Join SAIHM”, or run one command:

npx -y @saihm/mcp-server-pro free-join

It shows a short code and a link. Open the link, approve it, and the agent has memory from that moment. Prefer to start in a browser? /free does the same thing. To wire it into an MCP client first, MCP memory has the configuration.

Paid plans are monthly. Card worldwide through Stripe; card and M-PESA in Africa through Paystack. Stablecoin is available for those who prefer it and is the only route that needs a wallet. Prices are published on the pricing page rather than quoted per customer.

Join SAIHM → Quickstart →

Common questions

What is persistent memory for an AI agent?: Information an agent can still use after the current conversation ends, retrieved at the start of the next one. The useful test is not whether something is stored but what it survives: the session, the machine, the application, the model, and the provider.
Is a bigger context window the same as persistent memory?: No. A context window is working attention for a single request. It is re-read and re-billed on every turn and retains nothing once the session ends. A larger window makes longer conversations possible; it does not make anything persist.
Why does my agent forget between sessions?: Because the conversation was the only place that information existed. Unless the agent wrote it to a store outside the session, the session ending is the information ending. Connecting a memory server is what changes that.
Does persistent memory reduce token cost?: Usually, because it replaces the re-briefing you would otherwise paste into every session. Pasted context is re-read on every turn for the life of the conversation; a short retrieval at the start is not.
Will my memory survive changing to a different AI model or vendor?: Only if it is bound to you rather than to the application. Memory kept inside an assistant's account is persistent within that assistant and does not follow you out of it. Memory held under your own key and read through an open protocol does.
Should persistent memory keep everything forever?: No. A store that only grows degrades: superseded facts compete with current ones and the agent applies constraints you removed. Write decisions and reasons, supersede facts when they change, and erase what should not have been recorded.
How can memory be both durable and erasable?: Durability works by making copies, which is exactly what makes deletion unreliable. Sealing each memory under its own key resolves it: destroying the key leaves every remaining copy as unreadable ciphertext, so the copies do not have to be found.
What happens if I lose my key?: The memory sealed under it cannot be recovered, by you or by anyone operating the protocol. That is the same property that keeps operators out of your memory, seen from the other side, so backing up the key file is a genuine step rather than a formality.