SAIHM and Claude Code's new memory: a sovereign protocol layer

Two questions Auto Dream does not answer

When the same agent (or a different agent) needs the same memory tomorrow — on a different machine, or shared with a teammate, or attached to a compliance audit — two questions remain:

1. Whose key encrypts the cells? Anthropic-managed memory is, by construction, readable by Anthropic. That is fine for many workloads. It is not fine for compliance-bound work, sealed-source projects, or any case where the memory itself is the artefact under protection.
2. What proves the cell is gone? When a user invokes the right to be forgotten under GDPR Art. 17, deletion is not the same as cryptographic erasure. A protocol that anchors a destruction event on a public chain can prove erasure. A vendor delete cannot.

SAIHM was built around those two questions. Each memory cell is encrypted under its own data-encryption key (DEK) — a unique, randomly generated key — which is in turn sealed under a key-encryption key (KEK) the client derives from the user's wallet through canonical post-quantum HKDF chains. Erasure is a real cryptographic operation: the wrapped DEK is destroyed, so the cell collapses to ciphertext that nobody — not even the wallet holder — can reopen, and an audit anchor lands on COTI V2 mainnet. Sharing is a contract — explicit grant, scope-bound, revocable, with a public audit trail.

What SAIHM adds to a Claude Code workflow

The SAIHM MCP server drops into the same configuration any other MCP server uses. Eight tools become available to the agent:

• saihm_remember — store an encrypted memory cell.
• saihm_recall — retrieve and decrypt your memories.
• saihm_forget — cryptographic erasure with on-chain audit anchor.
• saihm_status — protocol-runtime stats and storage tier dashboard.
• saihm_share / saihm_revoke_share — selective, scope-bound, revocable sharing.
• saihm_governance_propose / saihm_governance_vote — protocol governance via gSAIHM.

The same eight tools work from Claude Desktop, Claude Code, custom MCP-capable agents, and any framework that speaks the Model Context Protocol. The memory layer travels with the user, not the vendor.

npx @saihm/mcp-server

{
  "mcpServers": {
    "saihm": {
      "command": "npx",
      "args": ["@saihm/mcp-server"],
      "env": {
        "SAIHM_ENDPOINT_URL": "https://operator.example.com/saihm/v1",
        "SAIHM_AUTH_HEADER": "Bearer <token>"
      }
    }
  }
}

Solo, academic, and open-source workloads are first-class. Pricing for every tier is on the pricing page.

Where Auto Dream and SAIHM compose

Auto Dream is a memory-hygiene pass on Claude Code's local memory file. SAIHM is a protocol for sovereign, encrypted, sharable cells. They sit at different layers and do not contend.

A reasonable shape:

• Auto Dream keeps the working set tidy — stale dates resolved, contradictions pruned, day-to-day project memory readable.
• SAIHM holds the cells whose lifecycle the user wants to govern: proofs, audit-bound facts, anything compliance-touching, anything shared between agents, anything that must outlive the choice of model vendor.
• The right to be forgotten resolves to a single MCP call — saihm_forget — that destroys the DEK and anchors the destruction on COTI V2 mainnet.

Cross-agent reuse is the same shape. When a custom agent built outside Claude Code needs to read what Claude wrote, it speaks the same eight tools to the same protocol endpoint, signs with the same agent identity, and reads the same cells — subject to whatever sharing contracts the user has granted.

For the full set of design choices behind that shape — your key instead of the vendor's, a deletion you can prove, a tamper-evident audit trail — see what makes SAIHM different.

Try it

• GitHub: github.com/SAIHM-Admin/saihm-mcp
• npm: npmjs.com/package/@saihm/mcp-server
• Developer docs: /developers
• How SAIHM compares: /comparison

Apache 2.0. Eight MCP tools. One protocol. Your key, your cells, your erasure.

Join SAIHM

Read next

• What makes SAIHM different — built for compliance from day one: your keys instead of the vendor's, a delete you can prove, and a tamper-evident audit trail, plus the other design choices most AI memory tools skip.
• AI needs memory better than yours — the costly failure isn't forgetting, it's confidently misremembering; how a memory layer that verifies, consolidates, and self-corrects changes that.

Try it: a drop-in memory contract

Here is the fastest way to feel the difference. Paste this into your agent’s system prompt — it assumes the SAIHM MCP tools saihm_recall / saihm_remember / saihm_forget are wired into your harness. Following it is what produces the savings:

## Memory contract

On every turn, before you act:
1. RECALL, don't re-read. Call saihm_recall with keywords for the task to load a small, bounded set
   of cells. Do NOT re-send prior turns - the recalled cells ARE your context.
2. Prefer the CURRENT fact. If two recalled cells conflict, the most recent /
   non-superseded one wins - never act on a decision a later cell reversed.
3. REMEMBER durably. Call saihm_remember to persist decisions, conventions,
   and constraints as cells - one fact each, in your own words.
4. On a "delete my data" request, call saihm_forget on those cells: erasure
   is per-record and provable, not a soft delete.

Bounded recall flattens the resend curve from O(N²) to O(N·cap) — the 62.8–85.9% fewer context tokens the open benchmark shows. Start with a small recall cap and raise it only if recall misses.