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
in_memory
langgraph
openai_sessions
mcp
A simple dictionary-backed store for local development and testing. No external dependencies. Data is lost when the process exits. Connects to LangGraph’s checkpointer and memory store APIs. Pass backend connection details to enable real provider communication.Without langgraph_url, the adapter falls back to an in-memory store. Stores memories as session metadata via the OpenAI Responses API.Without openai_api_key, the adapter falls back to an in-memory store. Communicates with an MCP-compliant memory server via JSON-RPC over HTTP.Without mcp_server_url, the adapter falls back to an in-memory store.
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.