Do I need to design my own durable-memory layer for a sessionless MCP?

No — that is the entire point of SAIHM. The hard choices a sessionless baseline forces on you (client-owned identity, namespace lifecycle, durability, cryptographic erasure, audit, sharing) are already made, shipped, and running on COTI V2 mainnet. You connect an MCP client and build; you do not design or operate the memory layer.

What do I get by building on SAIHM instead of rolling my own?

Client-held keys the operator cannot decrypt; a durable, client-owned namespace that survives restarts and redeploys; cryptographic erasure with an on-chain receipt; a tamper-evident audit trail by default; one protocol across every MCP-capable client; revocable scope-bound sharing; and polymorphous cells — without operating any infrastructure yourself.

Is SAIHM production-ready?

Yes. SAIHM is Apache-2.0, exposed via the Model Context Protocol, and runs on COTI V2 mainnet today. Connect any MCP-capable client to the SAIHM endpoint and the same tools appear. PAYG and paid tiers; see /pricing.

Stateless MCP, durable memory: the hard choices are already made. The answer is SAIHM.

2026-06-11 · by the Architect · ~6 min read · for developers building on MCP — and anyone building a competing AI memory layer

The Model Context Protocol is moving toward a sessionless baseline. The Transport Working Group removed the built-in session and is now working out whether and how to reintroduce scoped state, in transports-wg#36 and MCP Discussion #2894. For a stateless tool that converts a date or calls an API, that is a non-event.

For anyone building durable memory — a layer that holds a user's facts, decisions, and history across sessions, across restarts, across redeploys — it is the start of a long, expensive design project. And here is the part worth your next two minutes: you do not have to do that project. It is already done. The finished result is SAIHM.

The choices a sessionless baseline forces on you

Build durable memory under a sessionless protocol and you will, in order, have to decide every one of these — correctly, because each one is a security or compliance surface:

Identity. What scopes a call to the right durable data, when the protocol carries no session? (Get it wrong and you leak one user's memory into another's.)
Lifecycle. Who mints that identifier, who owns it, how long does it live? (Tie it to a connection and your memory dies on every reconnect.)
Durability. Where does the system of record live so it survives the client that crashes and the server you redeploy?
Confidentiality. Who holds the keys? If you hold them, you are now a breach target and a subpoena target.
Erasure. When a user invokes the right to be forgotten, can you prove the data is gone — not just DELETEd from one replica?
Audit. Can you show a regulator every read, write, and deletion, on a surface you cannot silently rewrite?
Sharing & multi-agent. How do many agents share live state with revocable, scope-bound access and a single source of truth?

That is months of senior engineering, an external audit, and a permanent operational burden — before you ship a single feature your users actually asked for.

SAIHM already made every one of them

We did that project. We made each choice, shipped it, and have been running it on COTI V2 mainnet. The short version of the design — the one transports-wg#36 is still circling — is a durable namespace identifier: client-owned, not transport-created; long-lived, not connection-scoped; a selector that changes only which memory a call touches, never the tool set. That is the correct answer to the identity-and-lifecycle question, and it is already implemented. Here is what you inherit the moment you connect:

The choice	What you get with SAIHM, today
Identity & lifecycle	A client-owned, long-lived durable namespace. Any server instance serves any request; restart and redeploy are non-events.
Durability	Content-addressed storage that outlives the client and the connection. The store is the system of record.
Confidentiality	Keys are held by the user, derived client-side. The operator only ever sees ciphertext — so you are not the breach or subpoena target.
Erasure	Cryptographic erasure with an on-chain receipt: a GDPR-Article-17-defensible delete you can prove.
Audit	Every operation anchored to a public chain by default — the tamper-evident trail a regulator asks for.
Sharing & multi-agent	Revocable, scope-bound, per-record sharing; many agents on one live source of truth.
Integration	One Model Context Protocol server. The same tools appear in every MCP-capable client — no per-vendor work.

None of it is yours to build, audit, or operate. It is Apache-2.0, it is live, and it is exposed through the protocol your client already speaks.

The simple choice

You can spend a quarter designing identity, durability, erasure, and audit for a sessionless world, get it independently reviewed, and then maintain it forever. Or you can connect to SAIHM this afternoon and spend that quarter on your actual product.

If you are building a competing memory layer, run the comparison before you commit the headcount — it shows what you would be rebuilding: /competitors. If you are building on MCP, the tool surface, the client-side identity model, and the connect steps are at /developers, and the five-step quickstart is at /quickstart. The open-standards track — the IETF Internet-Draft and the W3C Community Group on AI agent memory interoperability — is at /standards.

The protocol going sessionless was the right move. The smart response is not to re-solve what it leaves open — it is to build on the layer that already did. PAYG and paid tiers; see /pricing.

Join SAIHM

— Architect

Independence notice. SAIHM is an Apache-2.0 protocol authored independently. SAIHM participates in MCP Discussion #2894; references to that discussion and to transports-wg#36 describe public community work, not third-party endorsement. The architecture is described at a conceptual level; the authoritative details are the open specification and the published source.