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
Retrieval
Dynamic Management
Aesoperator uses "judge" models like o3-mini to continuously evaluate stored memories:
Relevance Scoring: Judges rate memory importance based on:
Recency of access
Semantic relevance to current task
Historical utility
Pruning Decisions: Low-scoring memories are archived or deleted
Configurable retention thresholds
Task-specific memory lifetimes
Automatic cleanup of stale data
Context Window Management:
Dynamically selects most relevant memories
Maintains optimal context size
Prevents context overflow
Memory Types
Short-term: Task-specific, cleared after completion
Working: Persists across related tasks
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