What is an AI agent memory protocol?

A specification for how agent memory is identified, sealed, addressed, shared, erased and invoked, defined independently of any one implementation. It is what allows a second client, written by someone else, to read memory the first one wrote.

Why not just use a product with an export feature?

An export gives you a file in the product's shape, which something still has to translate into the next product's shape, by hand and with loss. A protocol removes the translation entirely, because both implementations were written against the same specification.

How is this different from MCP?

MCP standardizes the wiring: discovery, tool schemas and transport. It deliberately says nothing about where memory lives, who can read it, how sharing works or what deletion means. A memory protocol specifies those and binds to MCP for invocation rather than inventing a competing transport.

Is SAIHM an internet standard?

No, and no memory protocol currently is. SAIHM published draft-saihm-memory-protocol as an Internet-Draft on the Independent Submission Stream in May 2026. An Internet-Draft is a working document with no formal standing and carries no IETF endorsement; it exists so the design is citable and checkable.

What makes a protocol genuinely open?

A license permitting reimplementation, a specification published separately from the code, a citable and versioned reference, and nothing load-bearing withheld. The practical test is whether a stranger could write an interoperating client from the published material alone.

What does binding memory to a key instead of an account change?

The operator becomes a storage provider rather than a gatekeeper: they cannot read, decline or lose your memory, and the identifier means something to any implementation. The trade is that recovery is your responsibility, since nobody else holds the key.

How many tools does the protocol expose?

Eight: store, retrieve, erase, status, share, revoke, and a governance pair for protocol parameters. The surface is kept small on purpose, because an interface an agent has to be taught is one it will use wrongly.

AI agent memory protocol

Portability is not a feature a product can add. It is a property of the layer the memory is defined at — which is why memory has to be a protocol, and why an export button is not the same thing.

What a memory protocol must specify → Where the standards work stands →

Why a product cannot deliver this, however good it is

Every memory product will tell you that you own your data, and most of them mean it. They will point at an export endpoint, and the export will work. It is still not portability, and the reason is structural rather than a matter of effort or good faith.

An export produces a file in a shape the product chose, describing records the product defined, addressed by identifiers only the product understands. To use it somewhere else, something has to translate it into the next product’s shape. That translation is written by hand, for each pair of systems, and it is lossy in the places the two models disagree — which is exactly the places that carried the meaning. You have your data. You do not have your memory.

Contrast the case where the memory was never product-shaped to begin with. If the format, the addressing and the access rules are defined by a specification that no single implementation owns, a second implementation reads the first one’s memory because both were written against the same document. Nothing is exported and nothing is translated. That is what “portable” has to mean to be worth anything, and it is only available at the protocol layer.

The distinction has a practical test. Ask whether a competent stranger could write a second client, without your cooperation, that reads memory written by the first. If the answer is no, portability rests on the vendor’s continued goodwill.

The six things a memory protocol has to specify

A great deal of what circulates as “open” in this space specifies one or two of these and leaves the rest to the implementation, which puts the interesting behavior back inside the product.

1. Identity: Who a memory belongs to, in a form that is not an account on somebody’s platform. If identity is an account, every other guarantee is scoped to that platform’s willingness to keep honoring it.
2. Sealing: How content is encrypted, under whose key, and at what point in its journey. This determines custody, and it cannot be retrofitted — a system that stores plaintext cannot become one that does not without rewriting everything.
3. Addressing: How a memory is named, so a different client can ask for the same thing. Without stable addressing there is no shared vocabulary between implementations.
4. Sharing: How access is granted to another party, at what granularity, and how it is withdrawn. Per-item grants and bulk access are different protocols wearing the same word.
5. Erasure: What removal means at the bit level, and what it guarantees against copies. “Delete” without a specified meaning is a user-interface behavior, not a protocol guarantee.
6. Transport binding: How an agent invokes all of the above. This is the layer MCP already standardizes well, which is why a memory protocol should bind to it rather than reinvent it.

The sixth is worth dwelling on, because it is where a lot of effort gets wasted. The Model Context Protocol already solved discovery, tool schemas and transport, and solved them well enough that an agent can use a server its author never heard of. A memory protocol that invents its own transport is competing where it has nothing to add and fragmenting where the ecosystem had converged. Binding to MCP and specifying the five things MCP deliberately leaves open is the useful division of labor. MCP memory covers that boundary in detail.

What “open” has to mean before it means anything

The word is doing a lot of unearned work across this market. Four things make it checkable, and the fourth is the one that separates an open protocol from an open-source product.

A license that permits use and reimplementation. SAIHM is Apache-2.0, which includes an express patent grant — the clause that matters if you intend to build on something commercially.

A published specification, separate from the code. Source alone is a description of one implementation’s current behavior, including its accidents. A specification says what is required, which is what a second implementer needs.

A citable, durable reference. Documentation that can be edited without trace is a weak foundation for a claim. SAIHM’s memory protocol is published as an Internet-Draft — draft-saihm-memory-protocol, Independent Submission Stream, submitted May 2026. An Internet-Draft is a working document with no formal standing and is not endorsed by the IETF; it is a public, versioned, citable description of the design, so the claims made here can be checked against something more durable than marketing copy.

Nothing load-bearing held back. This is the real test. If the specification is public but a required component is proprietary, the openness is decorative. The way to check is the stranger test above: could someone write an interoperating client from the published material alone?

Where the standards work currently stands

Agent interoperability is an active standards discussion. A working-group-forming Birds-of-a-Feather session on Agent Communication Protocols met at IETF 126 in July 2026, and a non-working-group mailing list was created to continue it. No working group is chartered, and nothing described here carries any standards body’s endorsement.

That is the honest state of it, and it is worth being precise because this is an area where implication does a lot of work. Participating in a discussion is not standardization. Publishing an Internet-Draft is not standardization. A BoF is a meeting held to decide whether a working group should exist, and until one is chartered and has produced consensus documents, nobody in this space has a standard — ourselves included.

What can be said without stretching: the questions being raised are the right ones, they are the questions this protocol was built to answer, and the answers here are implemented and shipping rather than proposed. Sealing before storage, per-item sharing with revocation, and erasure by key destruction are live in the published client today. Anyone can read the specification and the source and check that for themselves, which is a different and more durable kind of claim than an endorsement.

What binding memory to identity rather than to an account buys

This is the design decision the other five follow from, so it is worth isolating.

When memory belongs to an account, the account issuer is in every path. They authenticate the read, so they can decline it. They hold the record, so they can lose it. They define the identifier, so it means nothing elsewhere. They set the terms, so the guarantees move when the terms do. None of this requires bad intent; it is what an account is.

When memory is bound to a key you hold, the operator is a storage provider and nothing more. Authentication is a cryptographic fact rather than a permission. The identifier is meaningful to any implementation. Access does not depend on a relationship continuing, which is what makes the portability claim survive the vendor. It also means recovery is your responsibility rather than a support process — the same property viewed from the other side, and one that should be stated with the benefit rather than in a footnote below it.

Persistent memory works through what that binding means for durability; memory security covers what it does and does not do for the threat model.

What this looks like in practice

The protocol surfaces to an agent as a small set of MCP tools: store, retrieve, erase, report status, share, revoke, and a governance pair for protocol parameters. Eight in total, deliberately few, because a memory interface an agent has to be taught is one it will use wrongly.

Underneath, each memory is sealed on the device before it is stored, addressed by an identifier that does not depend on any operator’s account system, shared by re-wrapping a single item’s key for a single named recipient, and erased by destroying that key so remaining copies become unreadable rather than merely unlisted.

None of this is visible to the person using it. What they see is an agent that remembers, and remembers the same things when they switch to a different agent. The protocol is the reason that second part is true. Parameter-level detail is on the documentation page; integration notes are on the developers page.

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 → Read the docs →

Common questions

What is an AI agent memory protocol?: A specification for how agent memory is identified, sealed, addressed, shared, erased and invoked, defined independently of any one implementation. It is what allows a second client, written by someone else, to read memory the first one wrote.
Why not just use a product with an export feature?: An export gives you a file in the product's shape, which something still has to translate into the next product's shape, by hand and with loss. A protocol removes the translation entirely, because both implementations were written against the same specification.
How is this different from MCP?: MCP standardizes the wiring: discovery, tool schemas and transport. It deliberately says nothing about where memory lives, who can read it, how sharing works or what deletion means. A memory protocol specifies those and binds to MCP for invocation rather than inventing a competing transport.
Is SAIHM an internet standard?: No, and no memory protocol currently is. SAIHM published draft-saihm-memory-protocol as an Internet-Draft on the Independent Submission Stream in May 2026. An Internet-Draft is a working document with no formal standing and carries no IETF endorsement; it exists so the design is citable and checkable.
Is there a working group for agent protocols?: Not a chartered one. A working-group-forming Birds-of-a-Feather session on agent communication protocols met at IETF 126 in July 2026 and a non-working-group mailing list was created to continue the discussion. A BoF is a meeting to decide whether a working group should exist.
What makes a protocol genuinely open?: A license permitting reimplementation, a specification published separately from the code, a citable and versioned reference, and nothing load-bearing withheld. The practical test is whether a stranger could write an interoperating client from the published material alone.
What does binding memory to a key instead of an account change?: The operator becomes a storage provider rather than a gatekeeper: they cannot read, decline or lose your memory, and the identifier means something to any implementation. The trade is that recovery is your responsibility, since nobody else holds the key.
How many tools does the protocol expose?: Eight: store, retrieve, erase, status, share, revoke, and a governance pair for protocol parameters. The surface is kept small on purpose, because an interface an agent has to be taught is one it will use wrongly.