Skip to main content

Memory System

OfficeLLM includes a built-in memory system that allows you to persist conversation history from both managers and workers. The memory system is designed to be extensible, allowing you to add custom storage backends easily.

Overview

The memory system automatically stores:
  • All manager conversations (task coordination)
  • All worker conversations (tool executions)
  • Message history for each conversation
  • Metadata (timestamps, agent info, provider details)

Built-in Storage Options

In-Memory Storage

The simplest option - stores conversations in memory during runtime. Data is lost when the application stops.
When to use:
  • Development and testing
  • Single-session applications
  • When persistence isn’t required
  • Quick prototyping
Configuration Options:
  • maxConversations (optional): Maximum number of conversations to store. When limit is reached, oldest conversations are removed.

Redis Storage

Persistent storage using Redis. Conversations survive application restarts and can be shared across instances.
Prerequisites:
  1. Install the Redis client: npm install redis
  2. Run Redis server (e.g., docker run -p 6379:6379 redis)
When to use:
  • Production applications
  • Multi-instance deployments
  • When conversation history needs to persist
  • Sharing conversations across services
Configuration Options:
  • host: Redis server hostname
  • port: Redis server port
  • password (optional): Authentication password
  • db (optional): Redis database number (default: 0)
  • keyPrefix (optional): Prefix for all Redis keys (default: ‘officellm:conv:’)
  • ttl (optional): Time-to-live for conversations in seconds

Using Memory

Accessing Memory

Querying Conversations

Retrieving Specific Conversations

Getting Statistics

Cleanup

Conversation Structure

Each stored conversation has the following structure:

Creating Custom Memory Providers

You can create custom storage backends by extending BaseMemory:

Best Practices

1. Always Close Connections

2. Handle Memory Errors Gracefully

Memory operations are wrapped in try-catch blocks internally, so your application won’t crash if memory storage fails. However, you should monitor logs for memory-related errors.

3. Use TTL for Redis

Set a TTL (time-to-live) for Redis conversations to prevent unbounded growth:

4. Implement Pagination

When querying large datasets, always use pagination:

5. Monitor Memory Usage

For in-memory storage, be mindful of memory limits:

Example: Complete Usage

Troubleshooting

Redis Connection Errors

Solutions:
  1. Ensure Redis is running: docker run -p 6379:6379 redis
  2. Install redis package: npm install redis
  3. Check connection details (host, port, password)
  4. Verify firewall settings

Memory Not Storing Conversations

If conversations aren’t being stored:
  1. Check that memory is configured in OfficeLLMConfig
  2. Verify the memory instance is accessible: office.getMemory()
  3. Check application logs for memory-related errors
  4. Ensure proper cleanup with await office.close()

Performance Issues

For large conversation histories:
  1. Use Redis instead of in-memory storage
  2. Implement pagination when querying
  3. Set appropriate TTL values
  4. Consider archiving old conversations
  5. Use specific queries instead of fetching all conversations