Build on SAIHM. Don’t build SAIHM again.

If you build agentic memory, you have spent — or are about to spend — two years on key management, erasure, sharing, and audit. SAIHM has shipped those. They are open source. Use them.

Most memory tools compete for retail convenience. SAIHM is built to the bar businesses and regulated enterprises audit against — and that bar is the moat.

Why partnering beats competing

The market for AI memory is not zero-sum. Every memory-using agent is a memory-buying agent. Total demand will grow faster than any one vendor can capture. Whether your customers buy from you on top of the protocol, or from SAIHM directly, the industry expands either way.

The hard parts of agentic memory are not storage; they are sovereignty (key custody), compliance (cryptographic erasure), interop (cross-vendor sharing), and accountability (audit trail). SAIHM ships those four. On a public chain. Under Apache 2.0. You can have them now, or rebuild them over the next two years.

Pricing

Public pricing — per-call PAYG and monthly subscription tiers — is published on pricing and applies to all users. Operators building on top — resellers, white-label vendors, downstream integrators — are welcome to get in touch: email ops@saihm.coti.global with the subject “Interested in Partnering”.

Build on top, not against

Your differentiator is your UX, your voice, your domain knowledge, your customer relationships — not the storage primitive. Customers do not care which memory backend their agent uses; they care about the experience.

You can ship an experience that is better than SAIHM’s own on top of the protocol. Better your customers are served by a great UX over SAIHM than by a mediocre UX over a custom backend — and rebuilding the four hard parts of memory is what makes most custom backends mediocre.

What partnering actually looks like

There is no partner program to apply to and no revenue share to negotiate. The client is Apache‑2.0, the protocol is public, and the same published pricing applies to you as to everyone else — so you can build on SAIHM today without a conversation.

What we ask in return is nothing. What we would like is to hear what breaks. If you are integrating and hit an edge the documentation does not cover, mail ops@saihm.coti.global and it gets answered by whoever wrote the code.

Honest comparison vs the field

What each product’s canonical documentation states (reviewed 2026-05-07, every cell re-verified against current vendor documentation 2026-08-30). Where a property is not addressed in the docs reviewed, it is marked “not addressed” — not asserted as a defect. Each vendor column links to the documentation reviewed, so any cell can be checked at its source. Full per-cell matrix with every citation: /comparison.

PropertySAIHMMem0ZepLettaLangMemPinecone
The four hard parts — open ground under Apache 2.0
User-held encryption keysYes
HKDF from a secret only you hold
Not addressedNot addressedNot addressedNot addressedPartial
CMEK in your own AWS KMS; project-level, not per end-user
Per-memory cryptographic erasureYes
DEK destroyed; GDPR Art. 17
Partial
record removal; embeddings and backups not addressed
Not addressed
docs describe facts invalidated with a timestamp, not removed
Partial
DB block delete; not cryptographic
Not addressedPartial
CMEK is project-level and customer-controlled; effect of key deletion on stored data not stated
Public-chain audit anchorYes
public chain
Partial
request log; not chain-anchored
Not addressedNot addressedNot addressedPartial
proprietary logs; not chain-anchored
Cross-vendor consent sharingYes
revocable per grant
Partial
LLM-agnostic; portability not addressed
Not addressedPartial
intra-deployment only
Not addressedPartial
export, not consent sharing
Licensing
LicenseApache 2.0Apache 2.0 + cloudGraphiti Apache 2.0; Cloud proprietaryApache 2.0MITProprietary (BYOC)

Yes stated in the product’s own documentationPartial present but narrower than the propertyNot addressed the docs reviewed do not cover it — not asserted as a defect

Reusing this comparison? Take the matrix as data (CC BY 4.0) rather than a screenshot — it carries each vendor’s source link and its review date, so your copy stays checkable as products change.

The pattern is structural: the field competes on storage, retrieval, and context-engineering — while the four hard parts (sovereignty, cryptographic erasure, chain-anchored audit, cross-vendor consent sharing) are open ground SAIHM already ships under Apache 2.0. That is what you would rebuild over two years, or build on now. Each product above has genuine strengths in its own positioning; /comparison documents what each does well and cites the source behind every cell.

The part that is hard to rebuild

Deleting a record and erasing it are different engineering problems, and the gap is now measured rather than argued. Independent researchers reconstructed soft-deleted embeddings across three HNSW implementations by reading raw index files at the storage layer, bypassing the API entirely — recovering 100% of patient age and gender markers on medical data and 99% identity on facial embeddings from vectors the database reported as deleted (Ghost Vectors, 2026).

What survives three erasure mechanisms Three ways to erase an AI memory record compared. Soft delete flags the row but the embedding stays in the index and is recoverable from raw index files. Hard delete removes the row but backups and derived vectors remain until every copy rotates. Destroying the key leaves ciphertext with no key in existence, unopenable by anyone including the operator. After an erasure request, what is still recoverable? Soft delete Row flagged deleted Embedding stays in the index Recoverable from raw index files Hard delete Row removed Backups and derived vectors remain Recoverable until every copy rotates Destroy the key Ciphertext remains No key exists anywhere Unopenable by anyone, including the operator
Three mechanisms, three different answers to the only question a regulator asks.

This diagram is CC BY 4.0 — reproduce or adapt it, commercially or otherwise, with attribution. Download the SVG; the license travels inside the file. Credit as: What survives three erasure mechanisms by SAIHM, CC BY 4.0.

GDPR Article 17 asks for an outcome, and EDPB Guidelines 5/2019 set the bar at erasure that is verifiable and irreversible. Three things defeat delete-based approaches: embeddings derived from the data persist in the index, backups hold it until every copy rotates, and derived artifacts — summaries, graph edges, records written by other users — still describe the subject.

The same researchers propose the fix independently: encrypt each vector and discard the key on deletion, which took PII recovery to 0%. That is the mechanism SAIHM already ships. Building it yourself means per-record key management, a sharing model that survives revocation, and an audit trail someone else can verify — roughly two years of work to arrive at a property you can adopt this week under Apache 2.0.

The EDPB has not formally endorsed key destruction as Article 17 erasure; several supervisory authorities accept it under conditions. Stated plainly because a partner integrating SAIHM should know exactly what the regulatory position is and is not.

What this isn’t

  • Not an acquihire offer. No one is buying you out.
  • Not a relicensing demand. SAIHM is Apache 2.0; build whatever you want on top.
  • Not a hostile move. The protocol grows when you grow — by construction.

Get in touch

Partnership, white-label, or enterprise enquiries: ops@saihm.coti.global.

Open a conversation →