Memory

Aesoperator uses a sophisticated memory system powered by pgvector and Neon database to maintain context. Unlike other systems, Aesoperator uses a smaller judge model to continuously evaluate stored memories.

Architecture

  • Database: Neon PostgreSQL with pgvector extension for vector embeddings

  • Storage: Key-value pairs + vector embeddings of content

  • Retrieval: Semantic search using cosine similarity

  • Management: Dynamic pruning and retention based on relevance

How It Works

Storage

# Store key-value pairs
aesop.memory.set("user_preferences", {
    "theme": "dark",
    "language": "python"
})

# Store with vector embedding
aesop.memory.store(
    "Important context about user workflow",
    embedding_model="text-embedding-3-small"
)

Retrieval

Dynamic Management

Aesoperator uses "judge" models like o3-mini to continuously evaluate stored memories:

  1. Relevance Scoring: Judges rate memory importance based on:

    • Recency of access

    • Semantic relevance to current task

    • Historical utility

  2. Pruning Decisions: Low-scoring memories are archived or deleted

    • Configurable retention thresholds

    • Task-specific memory lifetimes

    • Automatic cleanup of stale data

  3. Context Window Management:

    • Dynamically selects most relevant memories

    • Maintains optimal context size

    • Prevents context overflow

Memory Types

  1. Short-term: Task-specific, cleared after completion

  2. Working: Persists across related tasks

  3. Long-term: Permanent storage for critical information

Example Usage

Configuration

Technical Details

  • Uses pgvector's HNSW indexing

  • Embeddings cached in Redis for fast retrieval

  • Async pruning jobs run on schedule

  • Automatic backups to object storage

  • Monitoring via Prometheus metrics

Note: Dynamic memory management with judge models is currently in progress. The feature will be generally available in Q2 2025.

Last updated