Which kind of memory do your AI agents actually need?

Eight questions, answered in order. They tell you whether you need a context window, a vector store, your vendor’s built-in memory, or portable memory for AI agents that survives an enterprise review.

Three of the eight send you somewhere simpler than SAIHM. Take those answers — they save you an integration you do not need.

Short answer

If your memory must outlive the session, cross vendors, stay readable only by you, be shared between agents with provenance, be withdrawable, and be provably erased — you need portable memory for AI agents. If any of those is a no, something simpler is correct and this page tells you which.

Q1–Q2 are exits. Most projects stop here. Use a context window or a vector store.
Q3–Q4 decide architecture. Cross-vendor portability and key custody are structural. You cannot add either later with a contract.
Q5–Q7 decide governance. Multi-agent sharing, revocation and erasure are where most memory layers stop short.
Q8 decides evidence. An enterprise review asks what you can prove, not what your vendor asserts.

Jump to a question

Every question links directly, so you can send a colleague straight to the one under debate.

The decision tree · The matrix at a glance
1. Must it outlive the session? · 2. Decisions, or documents?
3. More than one vendor? · 4. Who may read it?
5. Do several agents share one memory? · 6. Must sharing be revocable?
7. Must erasure be provable? · 8. Enterprise security review?
Where SAIHM sits · Taking this into a review

Reviewed 2026-08-30. Published by SAIHM under the Apache License 2.0.

The matrix

Eight requirements against five approaches. Columns are approaches rather than named products, so every cell states something you can verify yourself. Read down your requirements; the column with no gaps is your answer.

Requirement	Context window	Vector store (RAG)	Vendor-native memory	Hosted memory service	SAIHM
Do you need a memory layer at all?
Outlives the session	No	Yes	Yes	Yes	Yes
Recalls decisions and state, not documents	Within session	No	Yes	Yes	Yes
Architecture — decided once, not by contract
Portable across agents, models and vendors	No	Yes	No	Varies	Yes
Readable only by the key holder	n/a	Varies	No	Varies	Yes
Governance — where most memory layers stop
Shared between agents with provenance	No	No	No	Varies	Yes
Sharing you can revoke afterwards	No	No	No	Varies	Yes
Provable erasure (GDPR Article 17)	n/a	Varies	Varies	Varies	Yes
Evidence
Answers an enterprise review with evidence	No	Varies	Varies	Varies	Yes

Yes by designVaries depends on the product you pick — check its documentationNo not what this approach doesn/a requirement does not apply

The decision tree

Read it top to bottom. Answer no and you exit to the approach named on the left — that is your answer, and you are done. Answer yes and you carry on down.

Eight questions in four phases. The first phase ends most projects; the third is where most memory layers stop short.

1. Must it outlive the session?

If nothing must survive the session, use a context window and a scratchpad file. This question ends more projects than any other, so answer it before you evaluate anything.

No. A memory service buys you latency and an operational dependency and returns nothing.
Yes. Go to question 2.

2. Is it decisions and state, or documents?

If you are retrieving documents, use a vector store, not a memory layer. Two different problems share one word, and picking the wrong one gets you a worse retrieval system instead of a better memory.

Documents and reference knowledge. Use Pinecone, Weaviate, pgvector, or whatever your framework already ships.
Decisions, preferences, corrections, state. That is memory. It is small, written constantly, read at the start of every session, and useless if it is wrong. Go to question 3.

3. Must it work across more than one agent, model or vendor?

If you will use one vendor indefinitely, use their built-in memory. If not, your memory cannot live inside one vendor’s account model. Most teams answer this late, after the switching cost is already built. The Model Context Protocol is what makes a memory layer addressable by any compliant agent rather than one vendor’s.

No — one assistant, one vendor. Their built-in memory is simpler, cheaper, and you already pay for it.
Yes. Go to question 4.

4. Who is permitted to read it?

If only you may read it, encryption has to happen before the data leaves your machine. Where encryption happens decides this, and you cannot add it later with a policy or a contract clause.

Your provider may read it. A hosted memory service is fine. Choose it the way you choose any vendor.
Only you. Your keys cannot sit with whoever stores your data. Go to question 5.

5. Do several agents share one memory?

If more than one agent reads and writes the same memory, you need provenance and scoped retrieval, not just storage. Shared memory is what produces compounding value across an agent fleet — and it is where multi-agent systems fail in specific, documented ways.

No — one agent, one store. A single-agent store is enough. Go to question 7.
Yes — a fleet, or agents from different vendors. Research on governed shared memory for multi-agent LLM systems names four failure modes to design against: unauthorised leakage, stale propagation, contradiction persistence, and provenance collapse. Ask any candidate how it answers each. Traceability to the writing agent is the one most memory layers omit entirely. Go to question 6.

Interoperability across vendors is an active standards area: MCP for tool access and A2A for peer coordination, surveyed in A survey of agent interoperability protocols. Memory that cannot cross those boundaries cannot participate in it.

6. Must sharing be revocable afterwards?

If you may ever need to withdraw access, sharing must grant a key, not send a copy. Sharing and revocation are one decision. Treat them as two and you find the gap after you need it closed.

No. A single-holder store is enough.
Yes. Every grant needs its own recipient, an expiry, and a revocation you can exercise. If sharing copied your data to them, you cannot take it back — the copy already exists.

7. What must you show when a user asks to be forgotten?

If you must prove the data is unrecoverable, you need erasure by key destruction. Your regulator asks for the outcome; your database offers you the API call.

That the delete succeeded. A soft delete covers you. Most stores do this.
That the data cannot be recovered. Destroy the key and what remains is ciphertext nobody can open, including whoever runs the service. Under GDPR Article 17 the obligation is the outcome, not the API call.

8. Does it face an enterprise security review?

If it does, every answer above must be evidence rather than assurance. An enterprise review does not ask what your memory layer does. It asks what you can prove.

No — you are the only approver. Choose on ergonomics and ship.
Yes — security, your DPO, or procurement. Expect questions on where data lives, who can read it, what evidence you produce for a deletion request, how you cut off a contractor who has left, and what licence you are deploying. “Our provider promises not to look” does not survive the second question, and that alone removes most of the market.

Where SAIHM sits: portable memory for AI agents, enterprise-ready

SAIHM is portable memory for AI agents: enterprise-ready, encrypted and shareable — memory that follows your user across agents, models and vendors, and can be shared, revoked and provably erased.

Questions 3 to 8. SAIHM is the right-hand branch of every one. Portable across vendors. Readable only by you. Shared between agents with provenance. Revocable. Erased by destroying the key. Apache 2.0.
Questions 1 and 2. SAIHM is not your answer, and you should not adopt it. Use a scratchpad or a vector store.

Start free with one command. The same client carries the paid tiers, so the experiment you run this week does not get rebuilt when procurement asks about it.

npx -y @saihm/mcp-server-pro free-join

Taking this into a security or procurement review

Put these six to any vendor you are considering, including SAIHM. Each asks for evidence, and each has a wrong answer.

Where does plaintext exist, and for how long? Ask which component encrypts. If the answer is “the server, on receipt”, your plaintext sits on their infrastructure whatever the contract says about reading it.
Who can decrypt without your cooperation? A promise and a cryptographic inability are different controls. Only one survives a change of ownership.
What do you hand over when a deletion request arrives? Ask for the artefact, not the endpoint. Destroying the key leaves ciphertext nobody can open. A soft delete leaves a row with a flag on it.
How do you cut off someone who has left? If sharing copied the data, you cannot. If sharing granted a key, revocation does something real.
When two agents disagree, which memory wins, and who wrote it? Provenance collapse is a named failure mode of shared memory. If a vendor cannot tell you which agent wrote a record, it cannot tell you whether to trust it.
What licence, and can you self-host it? Apache 2.0 and a client you can run yourself answer your audit question and your continuity question together.

Use these in your own work

The tree and the matrix are published under CC BY 4.0. Reproduce them, adapt them, put them in a slide deck or a vendor evaluation — commercially or otherwise. The only condition is attribution.

Diagram (SVG). agent-memory-decision-tree.svg — scales to any size, and the licence travels inside the file as metadata.
Matrix (JSON). agent-memory-matrix.json — the same eight requirements as structured data, for agents and for anyone rebuilding the table in their own format.

Paste into a web page:

<a href="https://saihm.coti.global/agent-memory-decision-matrix">
  <img src="https://saihm.coti.global/img/agent-memory-decision-tree.svg"
       alt="AI agent memory decision tree" width="900">
</a>
<p>AI agent memory decision tree by <a href="https://saihm.coti.global/agent-memory-decision-matrix">SAIHM</a>, CC BY 4.0</p>

Paste into Markdown, a README, or a doc:

![AI agent memory decision tree](https://saihm.coti.global/img/agent-memory-decision-tree.svg)

*Decision tree by [SAIHM](https://saihm.coti.global/agent-memory-decision-matrix), [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)*

If you adapt the matrix, say so and keep the attribution — adaptations are welcome, silent ones less so. If you find a cell you think is wrong, the sourcing is on this page and the argument is worth having.