Production memory needs more than a place to save a note. A team needs to know whether an agent can retrieve the right fact in a later task, update it when circumstances change, keep it within the intended scope, and remove it according to the product's deletion policy.
Open source, self-hosted, and managed describe different decisions. Open source concerns the availability of code. Self-hosting assigns operation of the runtime to the team. A managed service assigns more of that operational work to the provider. A single vendor can offer more than one of these paths.
Start with the user's next task
Choose one situation in which forgetting would create a real failure. For example, a support agent tells a customer on Monday that a replacement was approved. On Thursday, another agent resumes the case. It needs the decision and its source, must keep to the customer's account scope, and should avoid using an obsolete shipping address. If the customer requests deletion, the team needs a clear account of the stored facts and derived artifacts affected.
This scenario produces five testable requirements:
| Requirement | Question to ask in a pilot | Evidence to collect |
|---|---|---|
| Lifecycle | Can the system write, retrieve, correct, expire, and delete a fact? | API results plus a trace of the same fact over time |
| Retrieval | Does it return the relevant fact without injecting unrelated or stale material? | Labeled queries, precision, missed facts, latency |
| Scope | Can one user, tenant, project, or agent read exactly the memories it should? | Cross-scope negative tests and access logs |
| Deployment | Where do raw content, embeddings, graph data, logs, and backups live? | Data-flow diagram and deployment configuration |
| Operations | Can an operator see why a memory was used and repair an error? | Source IDs, versions, feedback path, audit events |
Compare operating models, not logos
The matrix below summarizes vendor documentation reviewed on October 14, 2026. It describes published entry points and pilot questions; no independent performance ranking is implied.
| System | Publicly documented starting point | What to validate yourself |
|---|---|---|
| Mem0 | A hosted API for adding and searching memories. Its self-hosted setup documents a REST server, dashboard, API keys, and request logs. | Extraction accuracy, conflict handling, deletion through every configured store, and the operating cost of your chosen deployment. |
| Zep | A high-level Memory API and a lower-level graph path. Its documentation describes user-level knowledge built from sessions and retrieval across a user's sessions. | Ingestion delay, graph relevance, scope rules, export and deletion behavior, and the deployment terms applicable to your organization. |
| Letta | A stateful agent runtime with editable memory blocks; blocks can be attached to and detached from agents. Documentation describes managed and self-run paths. | Whether its agent-centered workflow suits an application that already has its own orchestration, and how shared blocks are governed. |
| MemOS | A memory platform available as a managed Cloud API or an open-source service, with separate cloud and local plugins for supported agents. Its reference self-hosted setup includes Neo4j and Qdrant. | Which operation and memory type is available in the chosen entry point; project and user boundaries, correction quality, deletion propagation, and operational load. |
These products occupy different layers of an agent stack. Mem0, Zep, and MemOS can provide memory capabilities alongside an existing orchestrator. Letta couples persistent state with an agent runtime. A team that already owns orchestration should decide whether it needs a memory component, a runtime, or both before comparing APIs.
Run the same pilot against every candidate
Use the same users, conversations, and queries for every system. Include ordinary tasks and deliberate failure cases:
- Preference change. A user switches from email to SMS. Does a current-state query use the new authorized preference while retaining earlier information only when the question calls for history?
- Ambiguous fact. An agent mentions an allergy in a hypothetical example. Does the integration avoid treating that statement as a confirmed user fact?
- Wrong-scope request. An agent in another tenant asks for a stored fact. Does the application prevent that fact from reaching the model?
- Deletion request. Does the team have a documented outcome for every store it uses, including the primary store, indexes, caches, derived summaries, and backups?
- Stale project decision. A release date changes. Does retrieval use the current decision for a current-state question?
For each case, record write acceptance, time to searchable state, p95 read latency, retrieval quality, prompt tokens added by the application, correction behavior, and operator effort. Mark undocumented requirements as unverified and resolve them through the pilot or vendor review.
Choose the operating model that fits the work
A managed service can reduce integration and day-two infrastructure work when its data residency, security, and commercial terms fit the application. A self-hosted service gives the team control of the runtime, networking, storage, and upgrade process. That control also makes the team responsible for operating those components.
A local plugin can fit a developer agent whose memory should remain on its host machine. Its host boundary should align with the application's tenancy model before it is used for a shared service. Record the exact deployment path and version in the pilot report, together with the owner of ongoing operations.
The final decision can fit on one page: user task, must-pass tests, measured outcomes, unresolved risks, and the operating owner. It remains useful when vendor releases change the surrounding feature list.