Persistent Memory

#sympozium #agenty #memory

Problem

W modelu efemerycznym agent traci pamięć po zakończeniu runu. Sympozium rozwiązuje to dwoma mechanizmami.

Mechanizm 1: Legacy ConfigMap Memory

Prostszy, starszy system:

Agent output zawiera markery:
__SYMPOZIUM_MEMORY__
Key insight: Pod X has recurring OOM issues
__SYMPOZIUM_MEMORY_END__
    ↓
Controller parsuje logi poda
    ↓
Patch ConfigMap: <instance>-memory
  Data:
    MEMORY.md: |
      # Agent Memory
      - Key insight: Pod X has recurring OOM issues
    ↓
Następny run montuje ConfigMap w /memory/MEMORY.md

Ograniczenia

Flat file (Markdown)
Brak wyszukiwania semantycznego
Max rozmiar: maxSizeKB (domyślnie 256KB)
Brak tagowania/kategoryzacji

Mechanizm 2: SQLite + FTS5 Memory (SkillPack-based)

Zaawansowany system z dedykowanym serwerem:

┌─────────────────────────────────────┐
│ Memory Server (Deployment+Service)   │
│                                       │
│  ┌──────────────────┐                │
│  │  SQLite + FTS5   │                │
│  │  na PVC (1Gi)    │                │
│  └──────────────────┘                │
│  HTTP API: :8080                      │
│  /health - readiness/liveness        │
│  /memory/store - zapis               │
│  /memory/search - wyszukiwanie FTS   │
└──────────┬──────────────────────────┘
           │
Agent Pod (z memory skill):
  - memory_store → HTTP POST
  - memory_search → HTTP GET

Aktywacja

Dodanie skillu memory do SympoziumInstance:

skills:
  - skillPackRef: memory

Co controller tworzy

PVC: <instance>-memory-db (1Gi) - persystencja SQLite DB
Deployment: <instance>-memory - memory-server z PVC
Service: <instance>-memory - ClusterIP na port 8080

Zalety vs ConfigMap

Full-text search (FTS5) - agent szuka w pamięci semantycznie
Tagging - memories mogą być kategoryzowane
Skalowalne - DB na PVC, nie ConfigMap (1MB limit)
Upgradeable - można dodać vector search w przyszłości
API-driven - agent używa HTTP API, nie plików

Memory w scheduled tasks

# SympoziumSchedule
spec:
  includeMemory: true  # Memory context wstrzyknięty do każdego runu

To enabler dla uczących się agentów:

Run 1: Agent odkrywa problem → zapisuje do memory
Run 2: Agent czyta memory → kontynuuje od ostatniego stanu
Run 3: Agent widzi trend → eskaluje

Memory seeds (PersonaPack)

personas:
  - name: sre-watchdog
    memory:
      enabled: true
      seeds:
        - "Track repeated pod restarts for trend analysis"
        - "Remember previous node capacity assessments"

Seeds to początkowa pamięć - instrukcje dla agenta co śledzić.

Architektura memory w podzie

Agent Pod:
  ├── Init Container: wait-for-memory
  │   └── curl http://<instance>-memory:8080/health
  │       (czeka aż memory server jest ready)
  ├── Agent Container:
  │   ├── memory_search("previous issues") → HTTP GET
  │   └── memory_store("New issue found: ...") → HTTP POST
  └── (memory server jest ZEWNĘTRZNY - Deployment, nie sidecar)

Powiązane: Model efemerycznych agentów | Scheduled Tasks - heartbeaty i swepy | SympoziumInstance

3.5 KiB Raw Blame History