Skip to main content

​
Memory Providers

BindAI’s memory package separates memory operations from their storage implementation through a common provider interface. The package includes an abstract MemoryProvider class, a MemoryRegistry for provider registration, and a Memory facade that delegates operations to a selected provider.

​
Provider Architecture

The package-level architecture is:
The provider determines how memory records are stored, retrieved, searched, and deleted. This architecture describes the memory package. It does not imply that every provider is available through BindAI Studio or integrated into Agent execution.

​
The MemoryProvider Interface

MemoryProvider is an abstract base class defined in bindai_memory.provider. A provider implementation must implement these methods: The exact search behavior, persistence guarantees, dependencies, and configuration requirements depend on the selected implementation.

​
The Memory Facade

The Memory class provides a common interface over a selected provider. It accepts:
  • A registered provider name as a string
  • An existing MemoryProvider instance
  • None, which selects the provider registered under the name memory
Example:
This example uses the default memory registration. It does not select SQLite by default. To select a registered provider explicitly:
This selects the provider class registered under sqlite. Successful operation still depends on the provider implementation and its runtime requirements. When using a provider that supports closing, call memory.close() when finished. The facade also supports context-manager usage.

​
Registered Built-in Providers

The current bindai_memory.registry source registers these provider names: These registrations confirm that the provider classes are included in the package’s registry. They do not, by themselves, confirm that all external services, optional dependencies, or Studio configuration paths are ready to use. Consult each provider’s implementation and tests before relying on its behavior.

​
In-Memory and Persistent Storage

The registry distinguishes the memory and sqlite provider names.
  • memory selects InMemoryProvider.
  • sqlite selects SQLiteMemoryProvider.
Do not assume that the default in-memory provider persists records across process restarts. Likewise, verify the SQLite provider’s database configuration and persistence behavior before documenting a specific database path or restart guarantee. The actual storage configuration should be taken from the selected provider’s implementation, not inferred from a memory name.

​
Custom Providers

The package supports registering custom provider classes through MemoryRegistry.register. A custom provider must inherit from MemoryProvider and implement its abstract methods. For example, the registration API has this form:
Here, CustomMemoryProvider represents an implementation supplied by the application; it is not a built-in BindAI provider. After registration, the name can be passed to Memory, provided the registration is available in the running process. This is a package-level extension mechanism. It does not establish that custom providers can be selected or configured through Studio.

​
Provider Registry Operations

The registry provides these operations:
Provider names are normalized to lowercase. Registration rejects an empty name and a class that does not inherit from MemoryProvider. providers() returns a copy of the registry mapping. The registry is a runtime registration mechanism, not a persistent provider configuration store.

​
Memory Record Lifecycle

The Memory facade uses MemoryManager for certain record updates. When Memory.get successfully retrieves a record, the inspected implementation:
  1. Updates the record’s access information.
  2. Reinforces its importance.
  3. Writes the updated record through the provider.
  4. Retrieves the record again and returns that result.
The manager also exposes explicit operations for promotion, expiration checks, importance decay, reinforcement, and expiration metadata. These operations should not be confused with automatic background maintenance. Do not claim that records are automatically promoted, expired, or forgotten on a schedule unless a separate runtime component implements that behavior.

​
Memory Providers and Agent Execution

The provider package defines record storage and management. It does not, on its own, establish when an Agent loads or saves conversation history. Before documenting automatic conversation persistence, Studio provider selection, or memory sharing across workflow runs, verify the relevant Agent, runtime, and Studio integrations.

​
Storage and Security

Choose a provider based on the application’s requirements and the backend’s verified behavior. Memory records may contain sensitive information. Consider credentials, access controls, backups, retention, and deletion requirements for the chosen storage system. Do not depend on undocumented backend schemas as public interfaces.

​
Summary

The BindAI memory package provides a common storage API through MemoryProvider, Memory, and MemoryRegistry. The inspected registry includes in-memory, SQLite, vector, PostgreSQL, Pinecone, and Chroma provider classes. It also supports registering custom provider implementations that satisfy the abstract interface. Provider registration is not the same as verified backend operation or Studio integration. Document those capabilities separately when their implementations have been checked.