Skip to main content
Memproof uses an adapter pattern to decouple its policy and audit layer from the underlying memory storage. Every memory operation flows through the control path (risk, policy, events) before the adapter persists it.

Built-in Adapters

A simple dictionary-backed store for local development and testing. No external dependencies. Data is lost when the process exits.

How Adapters Work

Each adapter translates five canonical operations to the backend: Adapters also normalize backend errors into canonical error codes: NOT_FOUND, CONFLICT, VALIDATION_ERROR, PERMISSION_DENIED, and PROVIDER_UNAVAILABLE.

Writing a Custom Adapter

Subclass MemoryAdapter and implement all five abstract methods plus the provider_name property.

The Base Interface

Example: Redis Adapter

Raise AdapterError with one of the canonical error codes. The orchestrator relies on these codes to decide whether to quarantine, retry, or surface the error.

Using a Custom Adapter with Memproof

Pass a pre-built MemproofConfig and override the adapter after construction, or contribute it upstream so it can be selected by name.
For production backends that require HTTP calls, follow the backend pattern used by LangGraphBackend, OpenAISessionsBackend, and MCPMemoryBackend — create a separate backend class and inject it into the adapter constructor.