Overview

It goes beyond simple vector storage to provide a bio-inspired, multi-module memory architecture. It actively processes, curates, and evolves memory through 10 specialized modules orchestrated by a central hub.

The Memory System operates as a unified service layer sitting behind the MainOrchestrator. It is accessed either automatically during query processing or manually via specific API endpoints.

System Architecture & Information Flow

Authentication Flow

All access is secured via API Keys. The system supports a dual-key mechanism:

1. Static Admin Key: For system-level operations.
2. Database Keys: For user/tenant access, hashed and validated against PostgreSQL api_keys table.

Context Injection: Upon successful validation, the verify_api_key dependency injects a context dict (user_id, project_id, api_key_id) into the request, which flows down to the Orchestrator.

Auto-Invocation & Lifecycle Hooks

A key design principle of DRIP is that memory operations are transparent. Developers interacting with the main /api/v1/query endpoint do not need to manually manage memory.

The "Hook" Mechanism

The MainOrchestrator implements hooks at critical stages of the query lifecycle:

1. Pre-Retrieval Hooks (Context Injection)

• Trigger: Before searching the knowledge base.
• Action:
  • Fetches recent Episodes (last 7 days).
  • Injects Personalized Context (user preferences).
  • Retrieves Short-Term session buffer.
• Result: The query is "enriched" with this context before being sent to the LLM.

2. Retrieval Phase Hooks

• Trigger: During vector/graph search.
• Action: Semantic Memory injects relevant facts and Procedural Memory injects relevant skill definitions into the search results.

3. Post-Response Hooks (Consolidation)

• Trigger: After a successful LLM response.
• Action:
  • Episodic Memory: Stores the interaction (Query + Answer) as a new Episode.
  • Short-Term Memory: Updates the session buffer.
  • Observability: Logs usage metrics.

Comparison: Auto vs Manual

Usage Tracking & Observability

To ensure accurate billing and monitoring, a specialized Middleware Patch was implemented.

The Tracking Gap Solution

Standard analytics tracked the Orchestrator, but direct calls to /api/memory/v1/* (e.g., from admin dashboards) bypassed this.Solution: MemoryTrackingMiddleware intercepts all requests to the memory namespace.

Middleware Logic

1. Intercept: Catches GET/POST/PUT/DELETE on v1/memory/*.
2. Extract: Pulls user_id and tenant_id from the auth context.
3. Track: Asynchronously calls usage_tracker.track_event() with event_type="memory_read" or "memory_write".
4. Tag: Marks events from dashboards with is_dashboard_tool=True for filtering.

Detailed Module Analysis

Explore individual memory modules: