SAIHM is the candidate global standard for Sovereign AI Horizontal Memory — the memory-protocol companion to the Model Context Protocol (MCP) tool layer. The campaign is multi-track and runs in parallel across every active forum.

Position: protocol layer, not implementation. SAIHM specifies the cell shape, identity binding, encryption envelope, audit anchor, sharing contract, and cryptographic erasure semantics that any compliant AI agent memory must satisfy. Reference implementation is Apache-2.0 at @saihm/mcp-server; operators are free to build their own.

https://saihm.coti.global/blog/2026-05-31-what-makes-saihm-different

What makes SAIHM different

2026-05-31 · SAIHM · for anyone comparing AI memory tools · ~6 min read

Ask most AI memory tools what they do and you hear the same sentence: they remember things for your AI so it does not start from scratch every session. That part is table stakes. SAIHM does it too. The question worth asking is not whether a tool remembers — it ishow it is built underneath, because that is what decides who can read your data, whether a delete is real, whether the memory follows you, and what it costs to run.

This post lays out eight design choices where SAIHM is built differently from the way most AI memory tools are built. Each one is a concrete mechanism, not a slogan, and each links to the page that goes deeper. If you are weighing options, read it as a checklist you can take to any vendor.

Have a question while reading? Ask the SAIHM chatbot on this page (bottom-right corner) for an immediate, specific answer. It is the same SAIHM protocol described here, answering questions about itself in real time.

1. Share a single record, revoke in one step

Bounded sharing, not blanket access.

Sharing memory between people or agents is often all-or-nothing: grant access and hope you remember to pull it back. SAIHM lets the user share a single record with limits on time and on what the recipient may do with it, and revoke that access in one step. It is access you can scope and take back, not a standing copy you have handed away. The FAQ covers how sharing and revocation work.

2. One source of truth for many agents

Coordinate several AI agents without manual syncing.

When several AI agents work on the same problem, they usually drift out of sync — each with its own slice of context, no shared ground truth. With SAIHM they can share one live memory state under cryptographic access control, giving the whole group a single source of truth without anyone hand-copying state between them. This is where it matters most for builders and organisations running more than one agent.

3. Your keys, not the vendor's

The operator cannot read what it cannot decrypt.

With most hosted AI memory, the company running the service holds the encryption key. That is a quiet but large decision: it means the provider — and anyone who compels the provider — can read what your AI remembered about you or your business.

SAIHM is built the other way around. Each cell is encrypted before it leaves the AI client, under a key derived from the user's own wallet. The key stays with the user or their organisation, not the operator, so the operator cannot read the contents at all. That is what the word sovereign in the name refers to. The Trust Center sets out the full posture, and the post on where AI memory lives walks the substrate underneath it.

4. A delete you can prove

Erasure destroys the key and leaves a receipt anyone can check.

In a normal database, a delete flags a row. Recoverable copies linger in backups, replicas, snapshots, and logs. You can say the data is gone; you usually cannot prove it.

SAIHM erasure destroys the key that decrypted the cell. The stored bytes remain on the network as ciphertext that is now mathematically unreadable — by anyone, including SAIHM — and the destruction event is anchored on a public chain so it can be independently verified. A delete becomes something you can demonstrate, not just assert. The mechanism is walked step by step in how SAIHM forgets for real.

5. A history nobody can quietly rewrite

Tamper-evident audit, on by default.

Many memory tools keep no real audit, or keep one the operator can edit. That makes "what happened to this data?" a question of trust rather than evidence.

Every SAIHM operation — write, recall, share, erasure — emits a tamper-evident receipt anchored on a public chain, to a surface neither the operator nor the user can silently rewrite after the fact. The history holds up to outside scrutiny because it does not depend on anyone's good word. See the compliance and trust surfaces for what that produces in practice.

6. One protocol, every AI client

Memory that follows you between tools instead of being rebuilt per vendor.

Memory baked into a single product is memory you lose the day you switch products — or memory you have to re-integrate for every new tool. Most options lock you to one client or require bespoke wiring per vendor.

SAIHM is one open memory protocol that speaks the Model Context Protocol, so the same memory works across the AI clients people actually use. It is published under Apache 2.0. The same protocol, one block of configuration, in every client — see the quickstart and docs.

7. One cell, many shapes

The cell is the durable thing; the shape is a render.

Most stores make you pick a shape up front: a vector database for semantic recall, a key-value store for facts, a document store for prose. The shape is baked in at write time, and changing it later means a migration.

A SAIHM cell is polymorphous. It stores the content once and the AI agent decides the shape when you ask: the same cell can come back as a paragraph to one query and as a single fact, a JSON record, or a table row to another. No second write, no schema to migrate. The full idea, with worked examples, is in polymorphous cells.

8. One encrypted unit instead of a stack

Collapse four stores into one.

Because shape usually dictates storage, teams end up running several systems side by side — a vector database, a key-value store, a document store, an event log. That is four ways to encrypt, four things to audit, four places to delete from when someone asks you to.

SAIHM keeps one memory in one encrypted unit: one envelope, one audit posture, and a single record to erase. Fewer moving parts is not just tidier — it is why the erasure in point 4 and the audit in point 5 stay simple instead of multiplying across products. The side-by-side is on the comparison page.