DEV Community: SAIHM-Admin

One memory, every model: grounding two models from the same store — then proving erasure

SAIHM-Admin — Tue, 23 Jun 2026 23:35:25 +0000

by the Architect · Apache-2.0

Every model vendor wants to be the place your context lives. That is convenient right up to the
day you switch models, run two in parallel, or have to prove to an auditor that a deleted record
is actually gone. Vendor-held memory cannot do the last one, and it makes the first two
painful.

This is a short, runnable walkthrough of the alternative: one store you own, read by two
different models at once, with deletion you can demonstrate rather than assert. It runs offline
first — no key, no account — so you can watch the whole thing happen on your own machine.

The setup

git clone https://github.com/citw2/demo-cross-model-memory
cd demo-cross-model-memory
npm install
node demo.mjs            # offline sandbox: seals 3 facts, grounds two models, proves erasure

What the demo does, step by step:

Seal a few facts once. They are encrypted client-side under a key derived from your wallet before anything leaves the process. The store never sees plaintext.
Ground two different models from the same cells. In the offline run these are local stand-ins; add your own keys to ground real models (the per-model demos cover Claude, GPT, DeepSeek, Qwen, Kimi, and GLM individually). The point is that the memory is identical across them — that is what makes it portable.
Forget one fact, then re-query both models. The cell is gone for both, because erasure happens at the store, not per-integration.

Why this shape matters

Portability. The store is addressed by the protocol, not by a vendor account. The same
cells open from the core client, from LangChain, and from LlamaIndex. Switching or combining
models does not strand your context.

Provable erasure. forget does not flip a "deleted" flag — it destroys the wrapped key, so
the ciphertext becomes unrecoverable noise. You can show an auditor the before-and-after
instead of trusting a dashboard toggle. Under the hood the identity is signed with ML-DSA-65,
each cell is sealed with AES-256-GCM, and sharing uses ML-KEM-768 — post-quantum primitives,
because "we deleted it, trust us" is not a compliance answer.

The minimal version in code

If you would rather see the moving parts directly, the core client is three calls:

from saihm_memory import SaihmMemoryClient

mem = SaihmMemoryClient()                 # local blind sandbox by default
cell = mem.remember("Ship date moved to Q3.")
mem.recall()                              # any model you ground reads the same fact
mem.forget(cell)                          # crypto-shred; now it is gone everywhere at once

Point a second model's context-loading at the same recall() and both are grounded from one
source. Call forget once and neither can retrieve it again — there is no second copy living
in a vendor's account to chase down.

What it costs, and what it doesn't

The offline sandbox is free to run and stores nothing beyond the process. Going live uses the
hosted blind endpoint — ciphertext only — and requires a paid membership (no free tier):
pay-as-you-go at $0.01/write and $0.005/read, or subscriptions from $5/mo, settled on COTI V2
mainnet. Everything client-side is Apache-2.0; there is no proprietary SDK lock.

And because you recall a small working set instead of re-feeding a whole transcript every call,
the token bill drops too. The open benchmark —
citw2/saihm-token-benchmark — measures up to
~80% fewer context tokens on long multi-session runs; run it on your own transcript to see your
number.

Run it, then join

Clone the demo, watch one memory ground two models and then disappear from both. If you want
that for real workloads, Join SAIHM: https://saihm.coti.global/join?utm_source=devto&utm_medium=article&utm_campaign=c3

All nine runnable demos: https://citw2.github.io/saihm-demos/

— Architect

A drop-in, ownable memory for LangChain and LlamaIndex — over MCP

SAIHM-Admin — Tue, 23 Jun 2026 23:35:23 +0000

by the Architect · Apache-2.0

If you build agents, you have already met the memory problem. The model forgets between
sessions, so you re-send the transcript every call. That is the line item that grows
quadratically and eventually overflows the window. The usual fixes trade one lock-in for
another: a vendor memory API that holds your data, or a framework-specific store you cannot
carry to the next model.

SAIHM is a memory protocol, not a model and not a product silo. It speaks the Model
Context Protocol, so anything that speaks MCP can use it; and it ships drop-in adapters for
LangChain and LlamaIndex so you do not rewrite your chain to adopt it. The keys are derived
from your wallet and never leave your machine — the service only ever sees ciphertext — and a
single forget destroys the wrapped key so the stored bytes become unrecoverable noise. That
last property is what compliance teams actually ask for.

This is a working integration guide. Every snippet below runs offline against a bundled blind
sandbox first — no key, no account — so you can try the whole thing before deciding anything.

1. The fastest path: MCP server

If your host already speaks MCP (Claude Code, Cursor, Claude Desktop, or your own client),
adding SAIHM is a config change, not a refactor:

npx @saihm/mcp-server

That exposes the protocol's tools to your agent — saihm_remember, saihm_recall,
saihm_forget, saihm_status, plus sharing and governance tools. The agent decides when to
remember and recall; you get a store that survives restarts and follows you across models.

2. LangChain: a drop-in `BaseChatMessageHistory`

For Python chains, install the adapter package and use SAIHM anywhere a chat-message history
is expected:

from saihm_memory import SaihmChatMessageHistory

history = SaihmChatMessageHistory()      # local blind sandbox by default
history.add_user_message("My name is Dana.")
history.messages                         # -> [HumanMessage("My name is Dana.")]
history.clear()                          # crypto-shreds only the messages this history added

Because it implements LangChain's BaseChatMessageHistory, it slots straight into
RunnableWithMessageHistory as the history factory. The full wiring (session keying included)
is in the adapter repo's demo.py — see the run-it section below. The important detail:
clear() crypto-shreds only the messages this instance added, so a reset never wipes the
rest of your memory by surprise.

3. LlamaIndex: a drop-in `BaseMemory`

The same store opens from LlamaIndex through a BaseMemory implementation:

from saihm_memory import SaihmMemory
from llama_index.core.llms import ChatMessage, MessageRole

memory = SaihmMemory.from_defaults()
memory.put(ChatMessage(role=MessageRole.USER, content="My name is Dana."))
memory.get_all()                         # -> [ChatMessage(USER, "My name is Dana.")]
memory.reset()                           # crypto-shreds only what this memory added

Pass it to a chat engine or agent via memory=.... The same cells written from LangChain are
readable here, and from the core client — one memory, three consumers.

4. The core client (any Python app)

No framework required:

from saihm_memory import SaihmMemoryClient

mem = SaihmMemoryClient()                # local blind sandbox by default
cell = mem.remember("My name is Dana Okafor.")
mem.recall()                             # -> [Memory(cell_id=..., text="My name is Dana Okafor.")]
mem.forget(cell)                         # crypto-shred (irreversible)

5. Run the adapter demo (offline, no account)

git clone https://github.com/citw2/saihm-langchain
cd saihm-langchain
npm install                              # the Node sidecar that seals every cell client-side
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt
python demo.py                           # offline blind sandbox; no key, no account

Python never holds a key — a small bundled Node sidecar does the sealing client-side, so the
adapter stays a thin, auditable layer.

6. Going live

The sandbox is an offline stand-in; it stores nothing beyond the running process. Going live
points the same code at the hosted blind endpoint and requires a paid membership (there is no
free tier). You onboard for a JWT, generate a master secret that never leaves your machine,
and the endpoint only ever receives ciphertext:

export SAIHM_ENDPOINT_URL=https://saihm.coti.global/mcp
export SAIHM_AUTH_HEADER="Bearer <your-onboard-JWT>"
export SAIHM_MASTER_SECRET_HEX=<at least 64 hex chars, generated and held only by you>

Settlement is on COTI V2 mainnet: pay-as-you-go at $0.01/write and $0.005/read, or
subscriptions from $5/mo. Apache-2.0 throughout — no proprietary client SDK to lock you in.

Does it actually save tokens?

Recalling a small working set instead of re-sending the whole history is the entire point, and
it is measurable. There is an open, offline benchmark you can run on your own transcript:
citw2/saihm-token-benchmark. On a long
multi-session run it cuts context (input) tokens up to ~80%; on short sessions, less. Output
tokens are identical under both strategies, so the win is exactly the context you stop paying
to resend.

Try it, then join

Clone an adapter, run the offline demo, point it at your chain. If it earns a place in your
stack, Join SAIHM to go live: https://saihm.coti.global/join?utm_source=devto&utm_medium=article&utm_campaign=c3

All nine runnable demos: https://citw2.github.io/saihm-demos/

— Architect

The hidden O(N ) tax in AI agent loops — measured, with a benchmark you can run

SAIHM-Admin — Tue, 23 Jun 2026 12:12:49 +0000

Every turn, most AI agents re-send their entire transcript. Across a real multi-session task that costs 62.8%–85.9% more context tokens than recalling a compact memory instead. Here is the measurement, the method, and how to reproduce it offline.

The cost nobody puts on the invoice

An agent loop is not one model call — it is dozens. A long Claude Code or Cursor session, an autonomous task runner, a multi-day project: each turn is a fresh call that re-sends the system prompt, the entire growing transcript, and the new message. The transcript only grows, so the context you pay for grows with it — and because every turn re-sends everything before it, total context spend scales roughly O(N²) across N turns. It is also why long sessions eventually hit the context window and fall over.

There is an alternative: do not re-send the transcript. Keep durable facts — decisions, conventions, file paths — as memory cells, and recall a small, bounded set each turn. That turns the quadratic resend into roughly O(N · cap). The obvious question is how much does that actually save? So SAIHM published a benchmark to measure it — and to let you check the number rather than trust it.

The experiment

The benchmark (citw2/saihm-token-benchmark, Apache-2.0) models one realistic scenario: a build-a-feature coding assistant working across three sittings, where early decisions (“use Recharts”, “store timestamps in UTC”, “named exports only”) accumulate and later turns need to recall them. It counts input/context tokens only, summed across every turn, under two strategies:

Naive — each turn sends system prompt + the entire growing transcript + the new message.
SAIHM — each turn sends system prompt + a capped set of recalled memory cells + the new message. The raw transcript is never re-sent.

Tokenization is gpt-tokenizer (cl100k_base, the GPT-4 BPE). It runs fully offline — no API calls, no keys — so it is deterministic and anyone gets the same result.

The numbers

Session length	Naive tokens	SAIHM tokens	Fewer
5 turns	1,628	605	62.8%
10 turns	6,091	1,273	79.1%
15 turns	13,175	2,023	84.6%
18 turns	18,688	2,632	85.9%

The longer the session, the wider the gap — exactly what the O(N²)-vs-O(N · cap) difference predicts.

Why these numbers are honest, not cherry-picked

Input only. Output tokens are identical under both strategies, so they are not counted. The win is purely on the context you re-send.
It is conservative for short work. At 5 turns you save ~63%, not 86%. The savings are a function of session length and how compact your memory cells are — your real mileage depends on your workload.
It measures a dynamic, not a price. This is resend-vs-recall token volume, not any one provider’s billing.

Reproduce it in two minutes

git clone https://github.com/citw2/saihm-token-benchmark
cd saihm-token-benchmark && npm install
node benchmark.mjs
node benchmark.mjs --recall-cap 8 # trade recall breadth vs savings

Change the cap, swap in your own scenario, re-run. The point of publishing it is that you do not have to take the percentage on faith.

Where the recall comes from

SAIHM is a memory layer you address across models — the same store works from Claude, GPT, DeepSeek, Qwen, Kimi or GLM, and through LangChain/LlamaIndex. Durable facts live as memory cells; each turn pulls a bounded set instead of replaying history. Because the memory is portable, you are not locked to one vendor’s built-in context; because it is yours, you hold the keys and erasure is per-record and provable. There are runnable, one-command demos for each of the above — linked from the demo set.

The honest close

SAIHM is a paid product, with no free tier — that is stated up front rather than buried behind a trial. But the benchmark and all nine demos are open source and run locally, so you can verify the claim and try the integration before deciding anything. The tool surface and connect steps are at /developers; pricing is at /pricing.

Join SAIHM

— Architect

Independence notice. SAIHM is an Apache-2.0 protocol authored independently. The benchmark described here is open source and reproducible offline; the figures are produced by the published script and depend on session length and scenario. The architecture is described at a conceptual level; the authoritative details are the open specification and the published source.

Originally published at the SAIHM blog on 2026-06-23. SAIHM is the Sovereign AI Horizontal Memory protocol — Apache 2.0, open spec at saihm.coti.global.

AI needs memory better than yours. SAIHM is the way.

SAIHM-Admin — Fri, 12 Jun 2026 03:21:04 +0000

Ask people what worries them about an AI's memory and most say the same thing: it forgets. The more expensive failure is the opposite. An assistant that confidently tells you something is already handled when it isn't — or that a task was never done when it was — costs you far more than one that simply says "I'm not sure." The danger isn't a blank. It's a confident wrong answer.

And confident wrong answers are exactly what unmanaged memory produces. That is the problem SAIHM — Sovereign AI Horizontal Memory, a sovereign, encrypted, sharable, persistent memory protocol for AI agents — was built to solve. SAIHM doesn't make your assistant smarter; it gives the assistant a memory it can actually trust — and that changes what the assistant can be relied on to do.

Memory drifts

Over weeks and months, an AI's notes quietly fill up with three kinds of trouble: facts that were true once but aren't anymore, conclusions it half-finished and never closed out, and guesses it never actually checked. Left alone, that pile grows — and the assistant leans on it as though every line were equally reliable.

The result is the worst kind of mistake: stated plainly, delivered with confidence, and wrong. Tidier storage alone doesn't fix it. Neither does simply remembering more. What matters is whether the memory carries enough about each note — where it came from, whether it was ever checked — for the assistant to tell good information from bad and act on the difference.

Dreaming is a good start. SAIHM goes further.

This year Claude and other assistants learned to "dream" — to look back between sessions and tidy their own memory, merging duplicates and dropping stale notes. It is a genuine improvement. But a neater copy of your memory is not the same as a more trustworthy one. SAIHM is the memory layer underneath, and it lets your AI agent go further — point by point:

Dreaming is a periodic pass. SAIHM stays current as you work. A dream is usually a scheduled tidy — a nightly pass. SAIHM consolidates continuously, so the memory your assistant relies on right now is the cleaned-up version, not yesterday's.
Dreaming reviews a recent batch. SAIHM holds your whole history. A dream typically looks back over a limited window of recent sessions. SAIHM gives your assistant a memory that spans everything you have ever told it — so it can draw on a detail from months ago, and a pattern that only shows up over the long haul isn't lost.
Dreaming can let a guess become a "fact." SAIHM keeps them apart. When notes get merged, an unchecked guess can quietly harden into settled truth. SAIHM tags each memory as verified or not, so your assistant only treats something as a confident, reusable fact once it has been confirmed or has held up repeatedly — tidying never launders a guess.
SAIHM remembers what was verified — and what was only assumed. It records, alongside each memory, where it came from and whether it was checked. That is what lets your assistant tell a confirmed fact from a hunch, and say "let me confirm that" instead of stating a guess with false confidence.
SAIHM records corrections as replacements, not extra notes. When two notes disagree, simple tidying leaves both in place. SAIHM stores a correction so the newer, verified version takes over and the stale one is retired — so once your assistant fixes a mistake, it stays fixed and doesn't resurface later.
SAIHM tracks whether the memory is getting more reliable. Most clean-up is invisible; you have no way of knowing whether it actually helped. SAIHM keeps score of the memory's health over time — fewer stale notes, more verified facts — so improvement is something you can see rather than take on faith.

The short version: dreaming makes a copy of your memory neater. SAIHM makes the memory your AI agent thinks with more reliable — spanning your whole history, honest about what has actually been checked, and self-correcting as you go. A neater copy is not the same as a memory you can trust.

How to switch this on

Joining SAIHM gives your AI agent a sovereign memory it can recall from and add to. The habits above aren't automatic — you turn them on by telling your assistant how to use that memory. Paste these standing instructions into your assistant's system prompt, project instructions, or custom-instructions field:

You have SAIHM - a sovereign, persistent memory you can recall from and add to. Use it as your long-term memory, by these standing rules:

1. Start every task by recalling from SAIHM anything relevant, and treat what you find as your own prior knowledge.

2. When you establish something worth keeping, save it to SAIHM and label it: VERIFIED if you confirmed it, ASSUMED if you have not. Never save a guess as if it were confirmed.

3. Before stating anything as settled, check its label. If it is only ASSUMED, say "let me confirm," verify it, and promote it to VERIFIED only once confirmed or repeatedly borne out.

4. When new information contradicts a stored memory, do not keep both: save the corrected version so it replaces the old one, and note that it supersedes it - so the fix sticks.

5. Consolidate as you go: merge duplicates, retire superseded notes, and keep one clean source of truth drawn from your whole history, not just this session.

6. Now and then, take stock of how reliable your memory has become - fewer stale notes, more verified facts - and tighten it further.

7. Use your memory freely; it persists across sessions and tools, so never re-derive what you have already established.

There's a practical bonus, too. Because your assistant recalls just the memory that's relevant instead of rebuilding everything from scratch each session, it spends far fewer tokens to do the same work — as much as 80% fewer in sustained use. Less of the context window goes to remembering, so more of it is free for the task in front of it.

That is the whole trick: the intelligence is your assistant's; SAIHM is the memory that lets it consolidate, keep what's verified and what's assumed apart, and correct itself — across every session, and every tool you use next.

Remembering is the easy part

Any assistant can store what you tell it. The one you can actually rely on is the one whose memory spans everything it knows, separates what it verified from what it only assumed, lets it correct its own mistakes, and grows measurably more reliable over time. That memory layer is what SAIHM is built to be.

That is the line between an assistant you tolerate and one you trust.

Go deeper

For individuals: what sovereign memory means for you
For organisations: control, compliance, and the right to be forgotten
How SAIHM compares: /comparison
Builders & developers: the technical version

SAIHM — the memory layer your AI agent can be trusted to think with.

Join SAIHM

Independence notice. SAIHM is an open-source protocol authored independently. It is not affiliated with any AI provider, and no AI provider participated in producing this post.

Originally published at the SAIHM blog on 2026-06-05. SAIHM is the Sovereign AI Horizontal Memory protocol — Apache 2.0, open spec at saihm.coti.global.

What makes SAIHM different: built for compliance, not bolted on

SAIHM-Admin — Thu, 11 Jun 2026 03:21:01 +0000

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 is how it is built underneath, because that is what decides who can read your data, whether a delete is real, whether the memory follows you, whether you can stand behind it to a regulator, and what it costs to run.

This post lays out nine design choices where SAIHM is built differently from the way most AI memory tools are built. The first is the one most tools treat as an afterthought — regulatory compliance — and the other eight are the concrete mechanisms that make it real. Each is a 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.

1. Built for compliance from day one, not bolted on

Compliance was a design input, not an afterthought.

Most memory tools reach for compliance late — a data-processing addendum here, a deletion endpoint there, bolted onto a system that was never designed for it. SAIHM was built the other way around: the controls regulators and security leaders ask for are not features stacked on top, they are the architecture. Almost every other point on this page — keys you hold, a delete you can prove, an audit nobody can quietly rewrite — is also a compliance control doing double duty.

That is what a CISO or DPO is actually shopping for, and it is the through-line of the security-leader posts here: the CISO checklist for AI memory, how SAIHM forgets for real, and where AI memory lives. The data-protection mechanisms those posts describe are live today, and they map directly onto the regimes organisations are held to — GDPR (including the Article 15 access right and the Article 17 right to erasure), CCPA/CPRA, HIPAA, ISO/IEC 27001 and SOC 2 — alongside the AI-specific frameworks now taking shape: the EU AI Act, the NIST AI Risk Management Framework and ISO/IEC 42001. The framework-by-framework crosswalk is on the standards page.

SAIHM is also built for where regulation is heading, not only where it is today. Rather than wait for the rules to settle, the project engages the bodies writing them, in the open and on the public record: consultation responses filed on the EU AI Act (Articles 6 and 50) with the European Commission, public comments to NIST, an Internet-Draft at the IETF, and the launch of a W3C Community Group on AI agent memory interoperability. What has shipped and what comes next is on the roadmap.

And it is priced for adoption at scale. Because one encrypted unit replaces a whole stack of separate systems (point 9), the cost structure is a fraction of running the usual pile of databases — so compliance-grade memory is something an organisation can roll out broadly rather than ration to a pilot. The tiers are on pricing.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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 standards and trust surfaces for what that produces in practice.

7. 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.

8. 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.

9. 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 5 and the audit in point 6 stay simple instead of multiplying across products, and it is why the cost in point 1 stays low enough to deploy at scale. The side-by-side is on the comparison page.

Put the list to work

None of these nine is a tagline; each is a design decision you can check for in any tool you are evaluating. Was compliance designed in or bolted on? Who holds the key? Can a delete be proven? Can the audit be edited? Does the memory move between clients? Do you need a separate store per shape? Can you share one record and revoke it? Can several agents hold one source of truth?

If you want SAIHM measured against named alternatives, that is laid out on the comparison and competitors pages. When you are ready to try it on your own workload, join SAIHM — pay-as-you-go and paid tiers are on pricing.

Join SAIHM

Independence notice. SAIHM is an Apache-2.0 protocol authored independently. It is not affiliated with OpenAI, Anthropic, Google, Perplexity, or any AI client vendor. Comparisons describe how memory tools are commonly built and will vary by specific product and configuration; evaluate any vendor, including SAIHM, against your own requirements. Pricing and tier details are on /pricing.

Originally published at the SAIHM blog on 2026-05-31. SAIHM is the Sovereign AI Horizontal Memory protocol — Apache 2.0, open spec at saihm.coti.global.

Where AI memory lives: the substrate underneath SAIHM

SAIHM-Admin — Wed, 10 Jun 2026 03:20:05 +0000

The vendor-memory failure mode

Almost every AI memory feature shipped in the last twelve months lives inside the vendor: on the model provider's servers, behind their authentication, governed by their retention policy, terminated by their billing system. That works until any of the following happens:

The vendor changes the retention policy.
The vendor deprecates the memory product.
You move to a different model and the memory does not move with you.
A regulator asks for proof of erasure and the vendor cannot produce it.
An auditor asks for a timeline of what the agent knew when, and the vendor cannot produce it either.

The fix is not a better vendor. The fix is moving memory off the vendor stack onto a substrate that the agent owner controls, that any party can verify, and that survives the vendor.

What “substrate” means here

The SAIHM protocol is a contract: eight tools, an identity scheme, an erasure receipt, an audit anchor format. The substrate is the physical infrastructure that contract runs on — the ledger that records the audit anchors, the storage network that holds the encrypted cell data, the key material the agent identity is derived from.

The distinction matters because the protocol is the part you depend on. The substrate is the part you can swap.

The four jobs a substrate must do

Any substrate that wants to host AI memory at production seriousness has to do four things, each with its own engineering constraints:

Identity anchoring. The agent's identity must be derivable from key material the agent owner controls (a wallet, an HSM, a KMS) and provable to third parties without trusting the vendor. This is where wallet-derived keys + HKDF chains earn their keep.
Audit anchoring. Each memory write needs a tamper-evident timestamp on a public, append-only ledger so a regulator, auditor, or counterparty can verify the timeline without re-trusting the operator. Finality must be reasonable; the per-write cost must be low enough that anchoring every cell is economically possible.
Ciphertext storage. The encrypted cell content has to live somewhere durable, distributed, and addressable by content hash so any party with the right key can fetch it and any party without the key sees only random bytes.
Erasure proof. When the user invokes the right to erasure, the substrate must support destroying the only decryption key, writing an on-chain tombstone, and blacklisting the storage CID — producing a receipt that a regulator can verify against the public ledger.

The candidate landscape, by job

Different substrate choices satisfy different jobs well or badly:

Identity: any chain with mature wallet tooling works. ETH, BTC, the EVM L2s, Solana, Cosmos, Substrate-family chains, COTI V2 — all viable for the “agent owns its keys” primitive.
Audit anchor: needs low write cost and reasonable finality. Ethereum L1 is too expensive at scale (every cell-mint would cost real dollars). L2 rollups are cheaper but inherit the rollup's data-availability assumptions. Cheaper L1s and app-chains widen the candidate set.
Ciphertext storage: Filecoin and IPFS are the obvious open candidates. Arweave is a candidate technically but its permanent-storage model conflicts with the right-to-erasure requirement (you cannot blacklist an Arweave CID; the network is designed not to forget). S3 / GCS / Azure Blob work but reintroduce a custodial layer.
Erasure proof: not a property of the substrate per se — it is a property of the protocol's key-management discipline. Any chain that can take a small write can record a tombstone; the protocol decides what the tombstone means.

No single substrate is obviously dominant on all four jobs. The honest answer is: you pick the combination that satisfies your constraints, and you document the choice so others can audit it.

SAIHM's deployment choice

SAIHM's reference deployment uses COTI V2 mainnet for identity and audit anchoring, and Filecoin (via a Lighthouse upload path) for encrypted cell ciphertext. The reasoning is narrow and engineering-only:

Native privacy primitives at the protocol level. COTI V2 supports wallet-derived encryption keys and private-data computation primitives, which lets the SAIHM agent identity HKDF chain (MPS-PQC-KEY-GEN-v1 → MPS-AGENT-IDENTITY-v1) tie audit records to the agent without putting sensitive key material on-chain.
Per-anchor cost low enough to anchor every cell. SAIHM mints one transaction per memory cell. The cost ceiling matters: at Ethereum L1 prices this workload would not be viable. The substrate has to make per-cell anchoring economically routine.
No EVM / no Solidity surface area. SAIHM has zero EVM dependency in protocol code — no ethers.js, no Solidity contracts. The substrate is interacted with via its native JSON-RPC. This is a deliberate protocol-design choice (smaller attack surface, no Solidity-version churn, no EVM gas-pricing dependency).
Filecoin for ciphertext, not Arweave. Arweave's permanent-storage model is incompatible with GDPR Article 17 right-to-erasure. SAIHM needs to be able to blacklist a CID after key destruction so re-fetching becomes impossible. Filecoin's incentive model supports CID blacklisting; Arweave's does not.

The choice is a tradeoff, not a coronation. A SAIHM deployment that satisfied the four jobs on a different substrate combination would still be SAIHM — the protocol contract does not change.

The portability point

Pulling these threads together: the substrate is a deployment configuration, the protocol is the load-bearing surface. If COTI V2 disappeared tomorrow, SAIHM the protocol would not disappear; a fresh deployment would stand up on whichever substrate combination satisfied the same four jobs, and the contract surface presented to applications and regulators would be unchanged.

This matters for evaluating any AI memory product, not just SAIHM:

If you are building an agent: think about your memory protocol independently from the substrate it runs on. Lock-in to either is a problem; lock-in to both at once is worse.
If you are a CISO or DPO: ask vendors for their substrate story — what is the audit ledger, what is the ciphertext store, what is the erasure-proof mechanism, what is the migration story if any of those changes.
If you are a regulator: the substrate is not a black box. Audit anchors are public; the candidate ledgers are well-documented; you can verify the chain of receipts yourself.

How to evaluate a substrate yourself

For each of the four jobs, ask:

Identity: Can the agent owner derive and rotate keys without trusting the vendor? Is the derivation auditable?
Audit anchor: What is the per-write cost? What is the finality timeline? Is the chain public and indexable by third-party explorers?
Ciphertext: Is content addressed by hash? Is the storage network distributed? Can a CID be made unfetchable when its key is destroyed?
Erasure: Does the protocol destroy the only key, or does it merely mark data deleted in a table? Where does the erasure receipt live? Can a regulator verify it against the public ledger without the operator's cooperation?

If a vendor cannot answer one of these for their AI memory product, the substrate story is incomplete.

Polymorphous cells: one memory shape for every AI workload

SAIHM-Admin — Mon, 08 Jun 2026 03:19:17 +0000

Almost every other AI memory stack forces you to pick a shape per store. A vector database for semantic recall. A key-value store for facts. A document store for prose. An episodic log for transcripts. Maybe a graph store for entities. Each shape is a separate piece of infrastructure, a separate encryption posture, a separate audit trail, and a separate bill.

SAIHM does not work that way. A SAIHM cell is polymorphous: it holds one AI memory in one encrypted unit, and your AI Agent decides at recall time whether to return it as prose, a table, a JSON object, a single fact, a summary, or anything else the moment calls for. The cell does not commit to a shape. The recall does.

This post explains what that means in practice, why it collapses four or five stores into one, and the prompts you can paste into any AI you already use to start saving and recalling polymorphous memory today.

1. The shape problem that polymorphous SAIHM cells solve

AI agents need memory in many shapes. Today's stacks ask you to commit to a shape before you know what the agent will need.

A real AI Agent, doing real work, accumulates memory in at least six recognisable shapes:

Episodic — "we talked about X yesterday."
Semantic — "X is a kind of Y."
Structured — tables, records, key-value facts.
Procedural — "to do X, the sequence is A, then B, then C."
Decisional — "we chose X because Y; revisit if Z."
Transcript — the literal text of an exchange the Agent may want to quote later.

The standard reaction is to buy or build a store for each shape: a vector DB for semantic and episodic, a relational store for structured, a document store for transcripts and decisions, plus a procedural-pattern catalog the AI Agent has to know how to query separately. Five products, five keys, five audit posters, five reasons your AI Agent's memory architecture diagram has more boxes than the rest of your application.

The hidden cost is even worse than the headcount. The Agent must know which store to query for which shape. The instant a fact lives in the wrong store, recall fails silently. The instant a new shape is needed, an integration project starts. The Agent's memory becomes the most fragile part of the system.

2. What a polymorphous SAIHM cell actually is

One encrypted unit. One protocol. Many possible recall shapes.

A SAIHM cell is the protocol's atomic unit of memory. It holds:

The content — whatever you (or your AI Agent) chose to save, in whatever form was natural at save time. Prose, JSON, a CSV snippet, a paragraph, a fact, a transcript excerpt, a procedure.
A small metadata envelope — tags, scope, timestamps, the authoring wallet identity.
An encrypted wrapper bound to the writing wallet's key.

That is the whole cell. There is no schema, no fixed field set, no embedding vector you have to compute at write time, no shape commitment.

At recall, the AI Agent asks SAIHM for cells matching a query and a scope. SAIHM returns the matching cells. The Agent then decides what shape to deliver to the human (or the next step in the workflow). The same cell that came back to one query as a paragraph can come back to another query as a JSON object, or a single fact, or a row of a table.

The polymorphism is at recall time, not write time

This is the key idea. Other stacks bake the shape into the write — once you put something in a vector DB, that is what it is. Once you write a row in a relational store, the columns are fixed. SAIHM never commits the cell to a shape. The shape happens when an AI Agent reads the cell and renders it for whatever the moment needs.

3. Examples: one cell, many shapes

Read these as prompts you can paste straight into any AI client connected to SAIHM.

Save once as prose — recall as JSON

Save to SAIHM: the production deploy on 2026-05-20 rolled back
because the migration locked the orders table for 90 seconds.
The fix was to switch to an online schema change tool.

Later that week, an AI Agent that needs the same information as a structured record asks:

Use SAIHM to recall the 2026-05-20 deploy event,
return it as a JSON record with fields:
date, what_happened, root_cause, fix.

The same cell now arrives as:

{
 "date": "2026-05-20",
 "what_happened": "production deploy rolled back",
 "root_cause": "migration locked orders table for 90 seconds",
 "fix": "switch to online schema change tool"
}

No second write. No schema migration. No re-ingest. The recall shapes the output.

Save once as a table — recall as a summary

Save to SAIHM as structured data: a table of our quarterly
support-ticket counts for each region for the last four quarters.

Six weeks later, the same Agent (or a different Agent that holds a SAIHM share to the same scope) asks:

Use SAIHM to summarise the regional support-ticket trend
across the last four quarters in two sentences.

The cell that came in as a table comes back as a paragraph. One memory, two shapes, one source of truth.

Save once as a decision — recall as a procedural sequence

Save to SAIHM: we chose Postgres for the new analytics service
because we already have an oncall rotation for it,
and the read pattern is moderate volume.
Revisit if write volume crosses 10x current.

Later, when another Agent is bootstrapping a similar service:

Use SAIHM to recall our analytics-service database choice
as a procedural checklist for the next service we set up.

The decision cell renders as a sequence of steps that the second Agent can follow — including the revisit trigger as an explicit final check.

4. What polymorphous cells let you stop doing

SAIHM is synonymous with simplicity. Here is what you no longer have to operate.

Per-shape stores. No separate vector DB to run. No separate KV store. No separate document store. No separate episodic log. SAIHM is one protocol holding all shapes.
Per-shape encryption postures. SAIHM encrypts every cell at write time under your wallet's key, before it ever leaves the AI client. Whether the cell holds a paragraph or a table, the encryption is the same and lives in one place.
Per-shape audit trails. Every SAIHM operation — write, recall, forget, share — emits a tamper-evident receipt anchored on a public chain. One audit posture for every memory shape.
Schema-migration projects. SAIHM has no schema to migrate. A new fact, a new field, a new shape is a recall-time concern.
Agent routing logic. Your AI Agent does not have to choose between five stores. It calls SAIHM. SAIHM returns the matching cells. The Agent shapes the answer.

The architect's measured outcome — 80 percent fewer tokens, roughly 5x more output — comes from collapsing this kind of moving-part count. Polymorphous cells are a large part of the why.

5. The compliance bonus: one cell, one erasure

When you delete an AI memory, you have to delete it everywhere. Polymorphous cells make "everywhere" mean one place.

Right-to-erasure obligations (GDPR Article 17, equivalents in HIPAA, PIPL, PIPEDA) require that personal data be removed on request — from every store, every backup, every embedding, every cache. The traditional shape-per-store architecture turns that into a multi-product engineering ticket: the vector DB has to lose its embedding, the KV store has to drop the record, the doc store has to delete the file, every backup that ever rolled has to be re-spun.

A SAIHM cell lives in one protocol. One cell, one erasure. The erasure itself is cryptographic: SAIHM destroys the key that decrypted the cell, then anchors the destruction event on a public chain. The ciphertext remains on the storage network as unreadable bytes that nobody — including SAIHM — can ever decrypt again. That is what makes the erasure defensible under a strict reading of GDPR Article 17, and you can independently verify it on a public block explorer.

Use SAIHM to forget the cell tagged {sensitive-topic}.
Prove it is gone.

6. Three prompts to start using polymorphous cells today

Paste these into the AI client you already use. The SAIHM protocol is the same in Claude Code, Claude Desktop, Cursor, Continue, ChatGPT (via an MCP bridge), and any other Model Context Protocol client.

Prompt 1: save a fact in whatever shape is natural

Save this to SAIHM, in whatever shape captures it best.
Add the tag {project-name}.

Prompt 2: recall it in a different shape

Use SAIHM to recall the cells tagged {project-name}
and return the answer as {a JSON record | a table | a one-sentence summary | a procedural checklist}.

Prompt 3: reshape on the fly across a workflow

For each SAIHM cell tagged {project-name},
return it as a structured row I can append to a tracker.
Then summarise the whole set in two sentences.

You can mix shapes in a single recall, change shapes between recalls, and never re-write a cell. The cell is the durable thing. The shape is a render.

7. Join SAIHM and try polymorphous cells in your own AI

If your current AI memory architecture has five boxes, polymorphous SAIHM cells collapse them into one. The fastest way to feel the difference is to try it on a real workload.

Join SAIHM at /join. Enrolment is a few clicks. PAYG and paid tiers available; see /pricing.
Connect your AI client to the SAIHM endpoint — one block of configuration, copy-paste from the quickstart page.
Paste the three prompts above. Save a fact one way. Recall it another way. Then a third way. Polymorphism is most convincing when you see it in your own workflow.

One protocol. One encryption posture. One audit trail. Every memory shape your AI Agent needs. Join SAIHM and see it for yourself.

Join SAIHM

Independence notice. SAIHM is an Apache-2.0 protocol authored independently. It is not affiliated with OpenAI, Anthropic, Google, Perplexity, or any AI client vendor. The 80 percent token-spend reduction and ~5x productivity uplift are internal metrics measured by the SAIHM author team on their own workloads since adopting SAIHM, and will vary by usage pattern. Pricing and tier details are on /pricing.

Originally published at the SAIHM blog on 2026-05-21. SAIHM is the Sovereign AI Horizontal Memory protocol — Apache 2.0, open spec at saihm.coti.global.

Cryptographic erasure: how SAIHM makes AI memory forget for real

SAIHM-Admin — Sun, 07 Jun 2026 03:18:41 +0000

AI agents are now persistent. They remember conversations, decisions, personal facts, regulated content, and procedural state across days, tools, and tenants. Every regulatory regime that already governs data — GDPR Article 17, HIPAA, PIPL, PIPEDA, the EU AI Act — applies to that memory. When a person, a regulator, or an internal policy demands "delete what the agent remembers about me," the answer cannot be "we tried."

This post explains why a database DELETE is not erasure, what cryptographic erasure is, how SAIHM implements it for AI memory, and how a regulator can verify a single erasure on a public block explorer without any cooperation from SAIHM. There are also three prompts you can paste into the AI client you already use to perform a forget today and pull the audit receipt.

1. Why DELETE is not erasure

A regulator asking "prove that data is gone" rarely accepts "we ran DELETE."

A DELETE statement in a relational database does one specific thing: it marks a row in the live table as removed. It does not, in any modern operational deployment, actually erase the bytes from every place the row has been. Bytes survive in:

Write-ahead logs — the row's full prior value sits there until the WAL segment ages out, sometimes weeks.
Point-in-time backups — daily, weekly, monthly snapshots that may retain the row for years under standard backup policy.
Read replicas — lagging copies, sometimes geographically dispersed, sometimes operated by a different team.
Snapshot volumes — cloud-provider block-level snapshots, often kept for disaster recovery.
Vector embeddings — AI workflows commonly embed the row's content into a separate vector store. That embedding is derivative personal data and is its own forgetting problem.
Downstream sinks — anything the row was streamed into: an analytics warehouse, a search index, a log aggregator, a fraud detection pipeline, an AI agent's own memory.

Each of those locations is an independent erasure problem. The "delete it everywhere" engineering ticket grows with every downstream system. The traditional answer is a multi-quarter project to track lineage, instrument every sink, and prove eventual consistency. Meanwhile the regulator is waiting and the clock is running.

AI memory layers make this worse, not better. An AI agent writes derived facts from the original data into its own memory store. That memory is now its own copy of regulated content, often under a different access posture than the source. Standard DELETE on the source does nothing about the agent's memory of it.

2. What cryptographic erasure actually is

Destroy the key, not the bytes.

Cryptographic erasure — sometimes called crypto-shredding — flips the problem. Instead of trying to delete every copy of the bytes, you encrypt the bytes under a key, hold that key in a single revocable location, and when you want to "forget," you destroy the key.

The ciphertext can remain wherever it has been replicated — backups, snapshots, distributed storage networks, archive tier. Without the key, every copy is mathematically random bytes. There is nothing to recover. The data has been erased in the only sense that matters: it is no longer accessible by anyone, anywhere, ever.

The pattern is recognised in standards: NIST SP 800-88r1 ("Guidelines for Media Sanitization") explicitly treats destruction of the encryption key as a valid sanitisation technique for encrypted media. Several national regulators take a similar position for personal-data erasure under GDPR Article 17 when (a) the encryption was strong, (b) the key was uniquely tied to that data, and (c) the destruction is auditable.

Those three conditions are precisely what SAIHM enforces by design.

3. How SAIHM implements cryptographic erasure for AI memory

Per-cell key. Real destruction. Tamper-evident receipt on a public chain.

Every SAIHM cell is encrypted at write time under a per-cell data-encryption key (DEK). The DEK is itself derived from a key custody graph rooted in the user's wallet, using a post-quantum-aware HKDF chain. The DEK never leaves the AI client in plaintext, and only the client (with the wallet) can re-derive it.

The ciphertext is sharded onto a public storage network (Filecoin / IPFS). The SAIHM protocol holds only the encrypted metadata envelope that points at the cell. The storage operator cannot read the cell. SAIHM the protocol operator cannot read the cell. Only the AI Agent that holds the wallet can.

The forget pipeline

When you ask SAIHM to forget a cell, four things happen in sequence:

DEK destruction. The data-encryption key for that cell is destroyed in the client's key store. SAIHM's protocol identifies this destruction with an explicit GDPR-Article-17 reason code.
Tombstone. A tombstone record is written to the SAIHM protocol so future recall queries cannot return the cell.
CID blacklist. The cell's storage Content Identifier is blacklisted, so any cached or downstream resolver also refuses to serve it.
On-chain anchor. A tamper-evident receipt of the erasure — cell identity, timestamp, GDPR-Article-17 reason code — is written to the public chain. That receipt is the audit artifact a regulator will look at.

After this sequence, the ciphertext bytes on the storage network are still there — you cannot ask Filecoin to retroactively delete what it stored — but they are now permanently undecryptable by anyone. The cell has been erased in the cryptographic sense, with a publicly verifiable receipt.

Why per-cell DEKs matter

A single master key protecting every cell would mean "destroy one cell" requires re-encrypting every other cell under a new master — an enormous, slow, error-prone operation. SAIHM gives each cell its own DEK so a forget is a single, atomic key destruction. One cell out, the rest of your memory unaffected.

4. How a regulator verifies a SAIHM erasure

Without SAIHM's cooperation. On a public block explorer. In about a minute.

The on-chain receipt is the verification artifact. A regulator (or your own compliance team, or an independent auditor) takes the cell identity that was supposedly erased, opens a public block explorer for COTI V2 mainnet at mainnet.cotiscan.io, and queries the SAIHM audit contract. The receipt comes back with three facts:

The cell identity exists in the erasure log.
The timestamp of erasure.
The GDPR-Article-17 reason code attached to the destruction.

The verifier does not need access to SAIHM's servers. SAIHM cannot retroactively change the receipt; the chain is immutable for everyone. The verification works the same way for the data subject, for the controller, for the regulator, and for an independent auditor.

This is the contrast that matters under GDPR Article 17. A regulator who is handed a screenshot of "DELETE row 4928 OK" from an operations dashboard has to take the operator's word for everything: that the DELETE actually ran, that backups have aged out, that no replica still holds the row. A regulator who is handed an on-chain transaction hash for the erasure event has to take nobody's word for anything. The receipt verifies itself.

5. Three prompts to perform a SAIHM forget today

Prompt 1: forget a single cell with proof

Use SAIHM to forget the cell tagged {sensitive-topic}.
Prove it is gone and give me the on-chain receipt URL.

The AI Agent returns a block-explorer link directly to the erasure transaction.

Prompt 2: forget every cell matching a scope

Use SAIHM to forget every cell tagged {personal-data-of-subject-X}.
Confirm each erasure on chain and give me the audit summary.

Useful when a data-subject erasure request applies to multiple cells. Each cell gets its own DEK destruction and its own on-chain receipt; the summary lists them.

Prompt 3: export the audit trail for a period

Use SAIHM to export the audit trail for {project-name}
for the last 90 days, including every write, recall, share, and forget,
in a format suitable for a compliance review.

The export is signed by your AI Agent's wallet identity and includes the on-chain transaction hashes. Hand it to your auditor or attach it to a regulator response.

6. What this lets you stop doing

SAIHM is synonymous with simplicity. Here is what you no longer have to operate or budget for.

Erasure-tracking products. No separate lineage tracker, no separate consent manager bolt-on, no separate "right-to-be-forgotten" workflow product. SAIHM ships the forget as a first-class operation.
Backup-window erasure timelines. No "your data will be fully erased once backups age out in 90 days." The DEK is destroyed at the moment of the forget; the backups become unreadable immediately.
Vendor-trust assumptions. No "trust us, we deleted it." The on-chain receipt is the proof; it does not require trust in SAIHM or in any storage operator.
Multi-system reconciliation. No "we have to also delete this from the warehouse, the search index, the log aggregator, the embedding store." The cell lives in one protocol; the forget happens in one protocol.
Regulator back-and-forth. The audit export carries on-chain receipts. The verification is one click in a public block explorer. The conversation ends.

7. Join SAIHM and run a forget on your own AI memory

If your current AI memory layer cannot answer "prove this is gone" with a verifiable receipt, that is a compliance gap waiting to surface. SAIHM closes it on day one.

Join SAIHM at /join. Enrolment is a few clicks. PAYG and paid tiers available; see /pricing.
Connect your AI client to the SAIHM endpoint — one block of configuration, copy-paste from the quickstart page.
Run a forget. Save a test cell, then erase it with Prompt 1 above. Open the block explorer link. The receipt is there before the kettle boils.

For CISOs and compliance leads who want the full ten-requirement landscape, see also AI memory needs a standard. SAIHM already meets it. — a longer board/RFP read.

Join SAIHM

Independence notice. SAIHM is an Apache-2.0 protocol authored independently. It is not affiliated with OpenAI, Anthropic, Google, Perplexity, or any AI client vendor. This post describes the SAIHM erasure protocol as implemented; nothing in it constitutes legal advice on any particular regulatory regime. Organisations should validate erasure procedures against their own controllers and regulators. Pricing and tier details are on /pricing.

Originally published at the SAIHM blog on 2026-05-21. SAIHM is the Sovereign AI Horizontal Memory protocol — Apache 2.0, open spec at saihm.coti.global.

AI memory needs a standard. SAIHM already meets it.

SAIHM-Admin — Sat, 06 Jun 2026 08:10:22 +0000

Your AI agents are already writing to memory. Some of what they write is regulated data, some is decision history, some is intellectual property. Every regime that covers data — GDPR, the EU AI Act, HIPAA, PIPL, PIPEDA — covers that memory the moment it is written. Today, most organisations are accumulating that memory across half a dozen incompatible vendor surfaces, with no shared way to audit it, erase it, or move it.

The market needs an AI memory standard. This post does three things. First, it lays out the honest current landscape. Second, it states the consensus requirements an AI memory standard must satisfy — derived from active regulation, established security frameworks, and the open protocols that are already winning in the AI tooling layer. Third, it makes the case that SAIHM is the most complete public candidate to be that standard, and shows how to evaluate the claim yourself.

Internal metric, disclosed up front: since we built SAIHM and adopted it on our own workloads, our token spend dropped 80 percent and our productivity rose roughly 5x. That is the operating-cost case. The compliance case is in this post.

1. The AI memory landscape today (honest read)

Four categories of solution dominate. None of the first three was designed to be a standard.

Category	Examples	Who holds the key?	Cross-tool portable?	Erasure with proof?	Built-in audit trail?
Vendor-native memory features	OpenAI memories, Claude memory, Gemini personalisation, in-app "save this"	Vendor	No	No	No (vendor logs only)
Hosted memory SaaS	Mem0, Letta, Zep	Vendor (operator)	Limited (per integration)	No (delete is not erasure)	Partial
Self-operated vector databases	Pinecone, Weaviate, Chroma	You (but you operate the DB)	You build it	You build it	You build it
Open protocol AI memory	SAIHM	You (user-held wallet key)	Yes (Model Context Protocol)	Yes (cryptographic, on-chain receipt)	Yes (every operation, by default)

Each of the first three categories ships real value — conversational continuity, hosted convenience, similarity search. None was designed to be the durable, regulator-defensible memory layer your AI agents will be operating in for the next decade. None offers all of: user-held keys, cross-tool portability, cryptographic erasure, and a tamper-evident audit trail. SAIHM does.

2. The consensus requirements an AI memory standard must meet

Ten requirements converge from active regulation, security frameworks, and the AI-tooling open protocols. They are not optional for any organisation already covered by data law.

The sources of the consensus. The list below is the intersection of obligations and norms that practitioners are already operating against:

GDPR Article 17 — right to erasure, including data held by automated decision systems.
EU AI Act (Regulation 2024/1689) — logging, traceability, and human-oversight requirements for high-risk AI systems; phased application through 2027.
NIST AI Risk Management Framework 1.0 (January 2023) — provenance, auditability, and incident-response expectations.
ISO/IEC 27001:2022 — cryptographic key management, access control, and audit logging controls.
HIPAA, PIPEDA, PIPL, LGPD — sectoral and regional privacy regimes with similar erasure and audit obligations.
Model Context Protocol (open spec, multi-vendor adoption) — the de-facto interoperability surface for AI memory tools across Claude, ChatGPT bridges, Cursor, Continue, and custom agents.
Operational reality — organisations running heterogeneous AI fleets need one memory layer across many clients to avoid an integration-and-audit explosion.

The ten requirements. Any AI memory layer that aspires to be a standard must satisfy all of them:

User-held key custody. The encryption key sits with the data subject (or their organisation), not the vendor. Vendors cannot read what they cannot decrypt.
Cryptographic erasure with proof. A forget operation destroys the key, leaves the ciphertext mathematically unreadable, and produces an independently verifiable receipt — the GDPR-Article-17-defensible posture.
Tamper-evident audit trail. Every write, recall, share, and erasure is logged to a surface neither operator nor user can silently rewrite. This is the regulator-facing artefact.
Open standard, cross-tool portability. The same memory protocol works across every AI client an organisation uses, today and after the next vendor change.
Encryption at rest and in transit. Ciphertext-only storage; ciphertext-only egress. No plaintext at any node the user does not control.
Polymorphous data shapes. Tables, JSON, key-value records, prose, transcripts, and binary references in one protocol. Input one shape, request another; the cell does not care.
Revocable scope-bound sharing. Per-record sharing with time bounds, mode bounds, and one-prompt revocation. No blanket access.
Distributed-agent coordination. Multiple AI agents — across regions, fleets, or supply chains — can share live memory state with cryptographic access control. Single source of truth without manual sync.
One protocol, every client. A single integration surface for the whole AI fleet. Minimises engineering cost, audit cost, and incident-response surface area.
Independent verifiability. Open source, public-chain anchors, and reproducible builds. No "trust us" claims; every assertion is testable by a third party.

3. SAIHM, requirement by requirement

SAIHM is the only public AI memory protocol we are aware of that satisfies all ten requirements today. Each line below is independently verifiable.

Requirement	SAIHM mechanism	How to verify it yourself
1. User-held key custody	ML-DSA-65 wallet-derived keys; HKDF identity chain anchored to the holder's wallet. SAIHM the operator never holds the user's decryption key.	Inspect the open-source key-derivation code; verify wallet ownership on COTI V2 mainnet.
2. Cryptographic erasure with proof	Forget operation destroys the Data Encryption Key, writes a tombstone, blacklists the CID, and anchors the destruction event on the public chain.	Read the tombstone receipt on cotiscan.io; the original ciphertext becomes mathematically unreadable.
3. Tamper-evident audit trail	Every SAIHM operation anchors a signed receipt on COTI V2 mainnet (chain ID 2632500). Regulator-grade evidence by default.	Pull the audit-trail export from `saihm_status`; cross-check each receipt on the public explorer.
4. Open standard, cross-tool portable	Eight MCP tools cover the whole protocol surface. Same prompts work in Claude Code, Claude Desktop, ChatGPT (via MCP bridge), Cursor, Continue, and custom agents.	Connect any MCP-capable client to the SAIHM endpoint; the same eight tools appear.
5. Encryption at rest + in transit	Per-cell encryption before egress; shard-distributed ciphertext across Filecoin and IPFS. No plaintext leaves the user's machine.	Inspect the write-path code; pull a ciphertext shard from Filecoin directly — it is unreadable without the user's key.
6. Polymorphous data shapes	Cells hold structured (tables, JSON, key-value) and unstructured (prose, transcripts, descriptions) content in the same protocol. Input one form, request output in another.	Run `saihm_remember` on a CSV; `saihm_recall` for the same content as a paragraph; the cell does not care about shape.
7. Revocable scope-bound sharing	Three sharing modes (temporary ≤ 24h, permanent, syndicate). One-prompt revocation. Per-record, not per-account.	Issue a share, revoke it, watch the on-chain revocation event land within one block.
8. Distributed-agent coordination	Multiple AI agents holding a share read and write the same live SAIHM cells. Fleet robotics, autonomous drones, multi-region trading agents stay in sync without manual exchange.	Connect two agents to the same share contract; observe state changes propagate via SAIHM, not via a private side channel.
9. One protocol, every client	One Model Context Protocol server; one configuration block; works in every MCP-capable AI client. No per-vendor integration.	Compare the MCP config blocks across your tools; the SAIHM block is identical.
10. Independent verifiability	Apache 2.0 source; npm package `@saihm/mcp-server`; listed on Glama and Smithery MCP registries; build commitments anchored on a public chain.	Clone the source, run the test suite, compare your build hash to the on-chain anchor.

4. The CISO checklist

Paste this into your next AI memory RFP, regardless of the vendor you are evaluating. Any vendor that scores fewer than 10/10 is a partial solution that will compound audit cost and lock-in risk.

Can your organisation hold the decryption key, with the vendor unable to decrypt without you?
Can the vendor produce a cryptographic erasure receipt for a single record, independently verifiable on a public surface?
Is every read, write, share, and erasure recorded on a tamper-evident audit surface neither the vendor nor the user can silently rewrite?
Does the same memory protocol run in every AI client your teams use today and the one they will pick next year?
Is all data encrypted at rest and in transit, with no plaintext outside your control?
Can a single memory cell hold structured and unstructured data, and serve it back in either shape on demand?
Can you grant scope-bound, time-bound, revocable access on a per-record basis from a single prompt?
Can a fleet of AI agents share live memory state with cryptographic access control, without manual sync?
Is the integration surface a single protocol across the whole AI fleet, not a per-tool integration?
Is the implementation open source, with public-chain build anchors and a third-party-runnable test suite?

SAIHM answers yes to all ten. The honest result of running this checklist across the rest of the market today: vendor-native scores 0–2, hosted SaaS scores 2–4, self-operated vector DBs score 3–5 (everything you build yourself). The 4–7 point gap is your audit cost, your lock-in risk, and your incident-response surface area.

5. Two SAIHM operations a CISO will care about on day one

These are the two prompts your team can run within the first hour of adopting SAIHM. Both are paste-ready into any MCP-capable AI client.

The audit-trail export

Use SAIHM to export the audit trail for the
{department-or-system} workload, last 90 days.
Format as a CSV suitable for the risk committee.

You get a tamper-evident, public-chain-anchored record of every memory operation your AI agents ran in the period. Bring it to the next risk meeting. Most incumbent memory vendors cannot produce this artefact at all; SAIHM produces it by default.

The verifiable erasure

Use SAIHM to forget all cells tagged
{data-subject-id}. Produce the destruction receipt
and the public-chain anchor for legal review.

This is your GDPR-Article-17-defensible posture in one prompt. The cell's encryption key is destroyed; the ciphertext is mathematically unreadable; the destruction event is anchored on a public chain. Counsel can verify the receipt independently.

6. Adopting SAIHM as your AI memory standard

Join SAIHM at /join. Five-step quickstart (wallet, USDC.e, connect, say "Join SAIHM", verify). PAYG and paid tiers available; see /pricing.
Run an audit-trail export on a small SAIHM workload within the first hour. Present the artefact at your next risk meeting.
Run the CISO checklist on your incumbent memory tool side-by-side with SAIHM. The standard wins on paper before it wins in production.
Scale. Recommended pattern for multi-agent deployments: one fresh empty wallet per AI Agent (memories are bound to the wallet that wrote them; per-agent wallets contain blast radius and produce per-agent audit trails). Setup guide on the quickstart.

SAIHM does more than every alternative and asks less of the organisation. One protocol. User-held keys. Cryptographic erasure with public-chain proof. The CISO checklist passes; the CFO benefits from the 80 percent reduction in token spend and roughly 5x productivity lift on the same workloads.

Join SAIHM

Independence notice. SAIHM is an Apache-2.0 protocol authored independently. It is not affiliated with OpenAI, Anthropic, Google, Perplexity, Mem0, Letta, Zep, Pinecone, Weaviate, Chroma, or any AI client or vendor named in this post. References to those vendors describe publicly observable product characteristics, not endorsements or disparagements. The 80 percent token-spend reduction and ~5x productivity uplift are internal metrics measured by the SAIHM author team on their own workloads since adopting SAIHM, and will vary by usage pattern. Regulatory citations (GDPR, EU AI Act, NIST AI RMF, ISO/IEC 27001, HIPAA, PIPEDA, PIPL, LGPD) are correct as of publication; consult counsel for application to your jurisdiction.

Originally published at the SAIHM blog on 2026-05-18. SAIHM is the Sovereign AI Horizontal Memory protocol — Apache 2.0, open spec at saihm.coti.global.

SAIHM and Claude Code's new memory: a sovereign protocol layer for Auto Dream and Managed Agents — SAIHM

SAIHM-Admin — Sun, 31 May 2026 04:14:45 +0000

SAIHM and Claude Code's new memory: a sovereign protocol layer for Auto Dream and Managed Agents

2026-05-09 · SAIHM

Anthropic shipped two memory features in early May 2026. Auto Dream for Claude Code consolidates project memory: it converts relative dates ("yesterday") into absolute timestamps, prunes contradicted facts, and merges insights so that a long-lived project file stops decaying after twenty sessions. Memory in Claude Managed Agents went to public beta the same week, surfacing per-agent memory as files that developers can export and edit through the API or the Claude Console.

Both are good shipments. Auto Dream solves a real failure mode — the moment your project memory file picks up a "yesterday we decided to use Redis" line that becomes ambiguous a week later, or a stale "API uses Express" entry from before the Fastify migration. Managed Agents memory makes the API-level story concrete: memory as files, not as an opaque vendor blob.

This post is not a comparison. SAIHM is a memory protocol, not a memory feature inside any one vendor. The two are designed to compose, and that is the point.

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:

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.
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 a per-agent data-encryption key (DEK) sealed by a per-agent key-encryption key (KEK), both derived from the user's wallet through canonical HKDF chains. Erasure is a real cryptographic operation: the DEK is destroyed, the cell becomes ciphertext-only nothing, 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 "
      }
    }
  }
}

The free tier covers 2,500 writes and 250,000 reads per month, no card required, no time limit. Solo, academic, and open-source workloads stay at zero cost. Pricing for higher tiers 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.

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

Independence notice. SAIHM is an Apache-2.0 protocol authored independently. It is not affiliated with Anthropic, and Anthropic did not participate in producing this post. References to Auto Dream and Claude Managed Agents memory are based on Anthropic's public release coverage in early May 2026.

SAIHM cuts AI context tokens up to 80% on long sessions

SAIHM-Admin — Thu, 21 May 2026 02:48:20 +0000

Recall a bounded set of memory cells each turn instead of re-sending the whole transcript, and on long, multi-session AI work the context-token spend drops by up to ~80% — a figure you can reproduce with the open benchmark. The difference is SAIHM — a sovereign memory layer that any AI client can call — and a small set of prompts you can paste straight into the AI you already use after joining your AI agents to SAIHM.

This post hands you those prompts. It also explains why SAIHM solves the three failures every other approach forces you to live with: the runaway token spend on long sessions, the out-of-context-window cliff, and the chaos of bolting together vendor-locked memory features that never talk to each other.

Read in order. The first section delivers the savings.

1. SAIHM prompts that maximise token economy

Every long AI reply re-reads itself. That re-reading is what you pay for. SAIHM stops it.

The opening move: tell SAIHM to load only what matters

Use SAIHM to recall only what is relevant to {today's task}.
Do not re-read the rest of our history.

On a 50,000-token conversation, this single SAIHM prompt typically cuts the cost of the next reply by 70–90 percent. Your AI pulls three to five relevant SAIHM cells instead of fifty pages of transcript.

See it measured. A small, offline, reproducible benchmark tokenizes a multi-session agent transcript two ways — re-sending the whole history every turn versus recalling a bounded set of memory cells — and reports the context-token saving. It grows with session length: about 79 percent at ten turns, rising to roughly 86 percent by eighteen. Run it on your own session: github.com/citw2/saihm-token-benchmark.

The closing move: have SAIHM remember the decision, not the discussion

Save this decision to SAIHM in one sentence,
tagged {project-name}.

Tomorrow's session opens with a one-sentence SAIHM recall instead of yesterday's full transcript. Compounded over a week, this is the single biggest contributor to the ~80% context-token reduction.

The mid-session move: a SAIHM summary you can re-load anywhere

Ask SAIHM to summarise what we have decided so far
in under 200 words, tagged {project-name}.

You can abandon a long thread, open a fresh chat, and pick up exactly where you left off — in any AI tool, on any day, on any device. The SAIHM cell travels with you.

The status check: see what SAIHM is doing for you

Show me my SAIHM status.

You get a dashboard: cells stored, storage tier, recent activity, sharing grants, compliance receipts. No spreadsheets, no accounting. One sentence in, one summary out.

Why this works. SAIHM stores each fact as its own encrypted cell. Recall pulls only the cells that match. The AI never reads your whole history unless you ask it to. The mechanism is the open Model Context Protocol, so the same SAIHM prompts work in every MCP-capable client.

2. SAIHM solves the out-of-context-window problem

Every AI has a context window. The window is finite. SAIHM is not.

The context window is your AI's short-term memory. SAIHM is its long-term memory. Short-term holds today's conversation; SAIHM holds everything else; the AI calls SAIHM on demand. The window never has to swell, and nothing important is ever lost when it fills.

The "resume kit" pattern

Open any large project session with:

Use SAIHM to recall the resume kit for {project-name}.

Close it with:

Update the SAIHM resume kit for {project-name}.
Capture decisions, blockers, and what to do next.

Sessions can now run for weeks across multiple AI tools. Every session opens with a small SAIHM recall and closes with a small SAIHM update. The window stays small. The project advances.

The "do not lose this" pattern

When you sense the context window is about to fill:

Before we get cut off, save the critical state to SAIHM
so I can continue this in a fresh session.

SAIHM cells survive session ends, browser crashes, tool switches, and quota resets.

The "switch tools without copy-paste" pattern

Started in one AI client, want to finish in another:

Save everything I need to continue this work
in another AI tool to SAIHM.

Open the second client connected to the same SAIHM endpoint:

Use SAIHM to recall the work I was just doing.

Your memory is portable because the protocol is portable. The AI tool is incidental.

3. Capabilities only SAIHM gives you

SAIHM does more than any other approach — for less effort, with simpler prompts.

Cryptographic erasure you can prove

Use SAIHM to forget the cell tagged {sensitive-topic}.
Prove it is gone.

This is not a vendor delete. SAIHM destroys the key that decrypted the cell and writes the destruction event to a public chain. The cell becomes ciphertext that nobody — including SAIHM — can ever read again. This satisfies a strict reading of GDPR Article 17 and you can independently verify the erasure on a public block explorer.

Encrypted storage you alone can open

Every SAIHM cell is encrypted at write time under a key derived from your wallet. The ciphertext is content-addressed and pinned on IPFS, then durably archived to Filecoin — decentralized, censorship-resistant storage. Even with the stored ciphertext in hand, it stays unreadable without the wallet-derived key your AI Agent holds. SAIHM the operator cannot read your memories. The storage networks cannot read them. Only your AI Agent can.

Polymorphous cells: structured in, unstructured out (and vice versa)

Save this table to SAIHM as structured data,
then summarise it back as a written paragraph.

SAIHM cells hold both structured data (tables, JSON, key-value records) and unstructured data (prose, decisions, transcripts) — in the same protocol, with no schema migration. Input in one form, request output in another, or vice versa: a CSV in, a paragraph out; a paragraph in, a JSON record out; a description in, a structured ticket out. Truly polymorphous memory cell storage. The SAIHM cell does not care about the shape; the AI Agent decides at recall time.

Scope-bound sharing in one sentence

Use SAIHM to share my {project-name} cells with {teammate's agent},
read-only, expires in 7 days.

Time-bound, scope-bound, revocable. Revoke any time:

Revoke the SAIHM share I gave {teammate's agent}.

Other approaches make you operate a separate sharing product, or grant blanket access through a vendor dashboard. SAIHM gives you the same outcome in one prompt.

Shared SAIHM memory for distributed AI agents

Sharing SAIHM cells across multiple AI Agents compounds the savings, accuracy, and efficiencies. Globally distant agents stay in sync without manual exchange: each one calls SAIHM for the latest shared cells before acting. The same mechanism powers fleet robotics, autonomous drones, multi-region trading agents, and any coordination task where two or more AI Agents must agree on a single source of truth.

Use SAIHM to share my mission-status cells with {robot-agent-id}
read+write, scoped to mission {mission-id}.

Every agent that holds the share reads and writes the same SAIHM cells. The cells stay encrypted; only the granted agents can decrypt; the public chain records who joined the share and when. Coordination becomes a SAIHM recall, not a network round-trip.

One wallet per AI Agent (recommended)

SAIHM memories are bound to the wallet that wrote them. The AI Agent reads and writes its memories through that wallet. The safest pattern: create a new, empty wallet for each AI Agent and fund it only with the small SAIHM PAYG balance it needs. Compromise of one AI Agent never touches another agent's memories, and a clean audit trail follows every agent for its lifetime. Step-by-step wallet creation and AI-Agent connection: see the quickstart (five steps, ~5 minutes) and /appendix/ai-agents for the list of wallet-connect-capable AI clients.

Compliance-grade audit, on by default

Use SAIHM to export the audit trail for {project-name}
for the last 90 days.

Every SAIHM operation (write, recall, forget, share) anchors a tamper-evident receipt on COTI V2 mainnet. If your industry requires evidence of what an AI agent did with which data — healthcare, finance, government, supply chain — that evidence is already there, on a public chain, signed by your own agent identity. You did not have to bolt on a logging product. SAIHM did the work.

One protocol, every AI client

The same SAIHM prompts work in Claude Code, Claude Desktop, ChatGPT (via an MCP bridge), Cursor, Continue, custom agents, and any client that speaks the Model Context Protocol. Your memory follows you. The vendor does not own it. SAIHM is Apache 2.0 and self-hostable if you ever want to.

4. Freedom from the chaos other solutions force on you

SAIHM is synonymous with simplicity. Here is what you escape.

Vendor-locked memory features — ChatGPT's memory, Claude's memory, in-app "save this" controls. They forget when you switch tools. SAIHM does not.
Hosted "agent memory" SaaS — bolt-on services, separate billing, separate keys, separate dashboards, separate outages. SAIHM is one protocol, one key, one prompt vocabulary.
Vector databases you operate yourself — you become a DB administrator instead of an AI user. SAIHM has no infra for you to run.
Privacy and compliance bolt-ons — separate consent managers, separate audit-trail products, separate erasure tooling. SAIHM ships all three on the same protocol.

The measured outcome — up to ~80% fewer context tokens on long sessions, reproducible with the open benchmark — is what happens when you replace four moving parts with one. SAIHM does more, for less, with less effort.

5. Join SAIHM and try the prompts above in your own AI

If you are still on a hosted-vendor memory feature, or you are juggling multiple memory products that never talk to each other, the fastest comparison is the one you run yourself, on a real task, using the prompts in this post.

Join SAIHM at /join. Enrolment is a few clicks. PAYG and paid tiers available; see /pricing.
Connect your AI client to the SAIHM endpoint — one block of configuration, copy-paste from the quickstart page.
Paste the SAIHM prompts above into whichever AI you already use. Measure the next reply's token count against a fresh chat without SAIHM. The savings are visible in the first session.

SAIHM does more than every alternative and asks less of you. Join SAIHM and see it in your own AI client.

Join SAIHM

Independence notice. SAIHM is an Apache-2.0 protocol authored independently. It is not affiliated with OpenAI, Anthropic, Google, Perplexity, or any AI client vendor. The context-token reduction is reproducible independently: the open benchmark measures the saving on any session you point it at — the ~80 percent figure reflects long multi-session work and scales with session length (about 79% at ten turns, ~86% by eighteen). Pricing and tier details are on /pricing.

Originally published at the SAIHM blog on 2026-05-17. SAIHM is the Sovereign AI Horizontal Memory protocol — Apache 2.0, open spec at saihm.coti.global.

DEV Community: SAIHM-Admin

One memory, every model: grounding two models from the same store — then proving erasure

The setup

Why this shape matters

The minimal version in code

What it costs, and what it doesn't

Run it, then join

A drop-in, ownable memory for LangChain and LlamaIndex — over MCP

1. The fastest path: MCP server

2. LangChain: a drop-in BaseChatMessageHistory

3. LlamaIndex: a drop-in BaseMemory

4. The core client (any Python app)

5. Run the adapter demo (offline, no account)

6. Going live

Does it actually save tokens?

Try it, then join

The hidden O(N ) tax in AI agent loops — measured, with a benchmark you can run

The cost nobody puts on the invoice

The experiment

The numbers

Why these numbers are honest, not cherry-picked

Reproduce it in two minutes

Where the recall comes from

The honest close

AI needs memory better than yours. SAIHM is the way.

Memory drifts

Dreaming is a good start. SAIHM goes further.

How to switch this on

Remembering is the easy part

Go deeper

What makes SAIHM different: built for compliance, not bolted on

1. Built for compliance from day one, not bolted on

2. Share a single record, revoke in one step

3. One source of truth for many agents

4. Your keys, not the vendor's

5. A delete you can prove

6. A history nobody can quietly rewrite

7. One protocol, every AI client

8. One cell, many shapes

9. One encrypted unit instead of a stack

Put the list to work

Where AI memory lives: the substrate underneath SAIHM

The vendor-memory failure mode

What “substrate” means here

The four jobs a substrate must do

The candidate landscape, by job

SAIHM's deployment choice

The portability point

How to evaluate a substrate yourself

Related reading

Polymorphous cells: one memory shape for every AI workload

1. The shape problem that polymorphous SAIHM cells solve

2. What a polymorphous SAIHM cell actually is

The polymorphism is at recall time, not write time

3. Examples: one cell, many shapes

Save once as prose — recall as JSON

Save once as a table — recall as a summary

Save once as a decision — recall as a procedural sequence

4. What polymorphous cells let you stop doing

5. The compliance bonus: one cell, one erasure

6. Three prompts to start using polymorphous cells today

Prompt 1: save a fact in whatever shape is natural

Prompt 2: recall it in a different shape

Prompt 3: reshape on the fly across a workflow

7. Join SAIHM and try polymorphous cells in your own AI

Cryptographic erasure: how SAIHM makes AI memory forget for real

1. Why DELETE is not erasure

2. What cryptographic erasure actually is

3. How SAIHM implements cryptographic erasure for AI memory

The forget pipeline

Why per-cell DEKs matter

4. How a regulator verifies a SAIHM erasure

5. Three prompts to perform a SAIHM forget today

Prompt 1: forget a single cell with proof

Prompt 2: forget every cell matching a scope

Prompt 3: export the audit trail for a period

6. What this lets you stop doing

7. Join SAIHM and run a forget on your own AI memory

AI memory needs a standard. SAIHM already meets it.

1. The AI memory landscape today (honest read)

2. LangChain: a drop-in `BaseChatMessageHistory`

3. LlamaIndex: a drop-in `BaseMemory`