> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bindai.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 10.5 memory

# Memory API Reference

The Memory API provides agents with persistent conversational context across multiple interactions.

While language models only receive the current prompt, memory providers allow BindAI agents to remember previous messages, user preferences, and conversation history.

This page documents the public Memory API.

***

# Overview

Memory stores information beyond a single request.

Conceptually:

```text id="api-memory-1" theme={null}
Conversation

↓

Memory

↓

Agent

↓

Response
```

This allows conversations to feel continuous rather than isolated.

***

# Purpose

Memory enables agents to:

* remember previous conversations
* preserve user context
* personalize responses
* retrieve historical interactions
* maintain long-running conversations

Without memory, every request is independent.

***

# Memory Providers

BindAI separates memory through providers.

```text id="api-memory-2" theme={null}
Agent

↓

Memory Provider

↓

Storage
```

Different providers may use different storage backends while exposing the same interface.

***

# Assigning Memory

Memory is typically attached to an agent.

Conceptually:

```python id="api-memory-3" theme={null}
agent.memory = provider
```

Once attached, the agent automatically reads and writes conversation history.

***

# Reading Memory

Before generating a response, the agent retrieves previous messages.

```text id="api-memory-4" theme={null}
User Request

↓

Load Conversation

↓

Generate Response
```

The retrieved context becomes part of the model input.

***

# Writing Memory

After responding, the interaction is stored.

```text id="api-memory-5" theme={null}
User Message

↓

Assistant Response

↓

Save Conversation
```

Future requests can access this information.

***

# Conversation History

A memory provider typically stores a sequence of messages.

```text id="api-memory-6" theme={null}
User

Assistant

User

Assistant
```

The exact storage format depends on the provider implementation.

***

# Session Isolation

Memory is generally organized by conversation or session.

```text id="api-memory-7" theme={null}
Session A

↓

Memory A

Session B

↓

Memory B
```

Separate sessions should not share conversational history unless explicitly configured.

***

# Persistence

Some memory providers persist data.

Others keep it only during runtime.

Examples include:

* in-memory storage
* databases
* key-value stores
* cloud storage
* custom implementations

The agent interacts with all providers through the same abstraction.

***

# Clearing Memory

Applications may clear conversation history when appropriate.

Typical situations include:

* user logout
* conversation reset
* testing
* privacy requests

Clearing memory starts a new conversation context.

***

# Memory vs Knowledge

Memory and knowledge solve different problems.

| Memory               | Knowledge             |
| -------------------- | --------------------- |
| Conversation history | External information  |
| User-specific        | Shared documents      |
| Dynamic              | Usually static        |
| Changes continuously | Updated independently |

Agents often use both together.

***

# Memory in Workflows

Workflow nodes may also access shared conversation memory.

```text id="api-memory-8" theme={null}
Workflow

↓

Memory

↓

Agent Node
```

This allows multiple agents within the same workflow to share conversational context.

***

# Error Handling

Memory providers should gracefully handle:

* unavailable storage
* missing conversations
* corrupted data
* connection failures

Applications should continue operating whenever possible, even if memory is temporarily unavailable.

***

# Performance

Efficient memory providers should:

* retrieve only relevant history
* avoid unnecessary database queries
* support scalable storage
* minimize serialization overhead

Large conversation histories may require summarization or truncation.

***

# Security

Conversation memory may contain sensitive information.

Providers should:

* encrypt stored data when appropriate
* isolate user sessions
* respect privacy policies
* support data deletion
* restrict unauthorized access

Security requirements depend on the deployment environment.

***

# Best Practices

* Use memory only when conversational continuity is required.
* Keep sessions isolated.
* Limit the amount of retrieved history.
* Store only necessary information.
* Clear memory when conversations end.
* Choose a provider appropriate for your deployment.
* Combine memory with knowledge retrieval when needed.

***

# Related APIs

The Memory API integrates with:

* Agent
* Project
* Workflow
* Knowledge
* Provider

These components together enable context-aware AI applications.

***

# Summary

The Memory API enables BindAI agents to remember previous interactions across multiple requests.

By separating memory into interchangeable providers, BindAI supports everything from simple in-memory conversations to scalable persistent storage while keeping agent behavior consistent and provider-independent.