Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.openmem.blog/llms.txt

Use this file to discover all available pages before exploring further.

Open Memory Protocol (OMP) is an open standard and Python SDK that gives your AI application one stable API for every memory backend. This page explains the problem OMP solves, how its adapter model works, and where to go next.

​
What is OMP?

Every popular memory provider — Mem0, Supermemory, Letta, Postgres — ships its own SDK, its own schema, and its own concept of users and scopes. Adopting one provider locks your application to it. Switching later means rewriting every memory call. OMP solves this with a single, versioned interface: mem.add(), mem.search(), mem.context(), and a handful of other verbs. You write against those verbs once. The SDK translates them to whatever backend you point it at through a system of adapters — no application code changes required when you switch. The analogy from the spec: OMP is to AI memory what the S3 API is to object storage.

​
Key benefits

Swap providers freely

Change the provider= argument and your application code stays identical. The SDK handles the translation.

Async-native

AsyncMemory mirrors the sync API with full async/await support. Postgres and passthrough backends use native async clients; other providers use a thread pool.

Prompt-ready context

mem.context() returns a ranked, citation-tagged block sized to your token budget — ready to prepend directly to an LLM system prompt.

Self-hostable server

omp-server exposes the full OMP verb set over HTTP so any language or framework can use it, with no proprietary infrastructure required.

​
Provider support

ProviderModeStatus
Postgres + pgvectorNative (reference)Ready
Mem0Translation adapterAvailable
SupermemoryTranslation adapterAvailable
LettaTranslation adapterAvailable
Any native OMP serverPassthrough via base_urlAvailable

​
How the architecture works

When you call mem.add(), the request flows through three layers:
  1. Your application calls a standard OMP verb on the Memory facade.
  2. The OMP SDK validates the payload, enforces the schema, and selects an adapter.
  3. The adapter translates the OMP call to the chosen backend’s API and normalizes the response back to OMP types.
For providers that implement OMP natively, the SDK probes GET /capabilities on startup. If the response includes omp_version, it uses a passthrough adapter — a thin HTTP client — instead of a translation adapter. Your application code is identical in either case. 
Your app  →  Memory facade  →  Adapter  →  Backend
             (OMP verbs)       (translate   (Postgres /
                                or pass-     Mem0 / etc.)
                                through)

​
What’s next

Quickstart

Run your first memory operation against a local Postgres instance in under five minutes.

Installation

Install the SDK with the right extras for your provider and configure credentials.