Skip to main content

​
Custom Memory

BindAI allows you to build your own memory implementations. While the built-in providers cover many common scenarios, some applications require custom storage, specialized databases, cloud services, or proprietary systems. Custom memory providers make it possible to integrate those systems without modifying agents or workflows.

​
Why Create a Custom Memory?

You may want a custom implementation when:
  • storing conversations in your own database
  • integrating with an existing application
  • using a cloud storage service
  • encrypting stored conversations
  • implementing custom retention rules
  • sharing memory across multiple services
The agent API remains exactly the same regardless of the underlying storage.

​
Architecture

A custom provider fits into the existing memory architecture.
The agent communicates only with the Memory object. The Memory object delegates persistence to your provider.

​
Provider Responsibilities

A memory provider is responsible for managing stored conversation data. Typical responsibilities include:
  • loading messages
  • storing messages
  • updating conversations
  • clearing memory
  • retrieving conversation history
The exact implementation depends on your storage backend.

​
Basic Structure

A simplified provider might look like this:
The implementation details are entirely under your control.

​
Creating a Memory Instance

Once your provider exists, create a Memory object.
The agent does not need to know anything about the underlying implementation.

​
Attaching to an Agent

Use the provider exactly like a built-in one.
Conversation loading and saving continue to work automatically.

​
Example: Database Provider

A custom provider could write messages into a relational database.
Each conversation becomes a collection of stored messages.

​
Example: Cloud Storage

Cloud services can also be used.
This allows conversations to survive application restarts and scale across multiple servers.

​
Example: Encrypted Memory

Sensitive applications may encrypt every stored message.
Encryption is handled entirely inside the provider. The agent remains unchanged.

​
Session Management

Most providers organize conversations by session identifier.
This keeps independent conversations isolated.

​
Performance Considerations

Large deployments should consider:
  • indexing conversations
  • batching writes
  • caching recent messages
  • asynchronous persistence
  • database connection pooling
The optimal strategy depends on the storage backend.

​
Error Handling

Providers should gracefully handle failures. Examples include:
  • unavailable databases
  • network interruptions
  • authentication failures
  • serialization errors
Applications may choose to retry, log the error, or temporarily disable persistence.

​
Testing

Before using a provider in production, verify that it correctly:
  • loads conversations
  • stores new messages
  • restores previous sessions
  • clears memory
  • handles concurrent access
  • recovers from failures
Reliable testing helps prevent conversation loss.

​
Best Practices

  • Keep the provider focused on storage.
  • Separate storage logic from agent logic.
  • Support session isolation.
  • Handle failures gracefully.
  • Avoid blocking operations whenever possible.
  • Consider encryption for sensitive information.
  • Document retention and deletion policies.

​
Summary

Custom memory providers allow BindAI to integrate with virtually any storage system. Because the Memory abstraction separates storage from execution, applications can evolve from simple local prototypes to enterprise-scale deployments without changing agent or workflow code.