04.2 providers

Memory Providers

BindAI separates memory management from memory storage through memory providers.

A memory provider is responsible for saving, loading, updating, and deleting conversation history or other persistent information.

Because providers follow a common interface, applications can switch storage backends without changing agent code.

---

Why Providers?

Different applications have different requirements.

For example:

• prototypes may only need temporary memory
• production systems often require persistent storage
• distributed deployments may use centralized databases
• AI assistants may combine multiple memory systems

Memory providers make these scenarios possible while keeping the agent API consistent.

---

Provider Architecture

The architecture is intentionally simple.

Agent

↓

Memory

↓

Memory Provider

↓

Storage

The agent interacts only with the Memory object.

The Memory object delegates storage operations to the configured provider.

---

Available Providers

BindAI currently includes:

• In-Memory Provider

Additional providers may include:

• SQLite
• PostgreSQL
• Redis
• MongoDB
• Vector Databases
• Cloud Storage

The provider interface is designed so new implementations can be added without modifying existing agents.

---

In-Memory Provider

The default provider stores everything in memory.

from bindai_memory import (
    Memory,
    InMemoryProvider,
)

memory = Memory(
    InMemoryProvider(),
)

This provider is ideal for:

• development
• testing
• examples
• temporary conversations

Data is lost when the application exits.

---

Using a Provider

Attach the memory instance to an agent.

agent.use_memory(
    memory,
)

Once configured, loading and saving occur automatically during execution.

---

Provider Responsibilities

Every provider is responsible for operations such as:

• storing messages
• retrieving messages
• clearing memory
• updating stored data
• managing conversation state

The agent never needs to know how the provider performs these tasks.

---

Persistent Providers

Persistent providers keep data after the application stops.

Typical workflow:

Conversation

↓

Memory Provider

↓

Database

↓

Restart Application

↓

Conversation Restored

This allows assistants to maintain long-term conversations across sessions.

---

Distributed Systems

Providers also enable multiple application instances to share memory.

Agent A

↓

Shared Database

↑

Agent B

Both agents access the same stored conversation.

---

Session Isolation

Most providers organize memory by session.

Example:

Session A

↓

Conversation A

Session B

↓

Conversation B

Keeping conversations isolated prevents unrelated sessions from mixing together.

---

Performance

Different providers offer different performance characteristics.

Provider	Best For
In-Memory	Development and testing
SQLite	Small local applications
PostgreSQL	Production systems
Redis	Fast distributed memory
Vector Database	Semantic retrieval

The appropriate provider depends on application requirements.

---

Choosing a Provider

General recommendations:

In-Memory

• tutorials
• local development
• examples

Database Provider

• production deployments
• persistent conversations
• multi-user systems

Redis

• distributed applications
• shared state
• high performance

Vector Provider

• semantic memory
• similarity search
• long-term retrieval

---

Swapping Providers

Because all providers implement the same interface, changing storage usually requires only replacing the provider.

Example:

memory = Memory(
    SomeOtherProvider(),
)

The rest of the application remains unchanged.

---

Best Practices

• Use In-Memory during development.
• Use persistent providers for production.
• Isolate conversations by session.
• Avoid storing unnecessary information.
• Consider backup and retention strategies.
• Select a provider that matches expected scale.

---

Summary

Memory providers determine where and how BindAI stores conversational information.

The provider abstraction allows applications to evolve from simple local prototypes to large distributed production systems without changing the agent programming model.