# 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:
```yaml
skills:
  - skillPackRef: memory
```

### Co controller tworzy
1. **PVC**: `<instance>-memory-db` (1Gi) - persystencja SQLite DB
2. **Deployment**: `<instance>-memory` - memory-server z PVC
3. **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

```yaml
# 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)

```yaml
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]]