# Model efemerycznych agentów

#sympozium #agenty #architektura #ephemeral

## Fundamentalna decyzja

Sympozium implementuje **model efemeryczny**: każde wywołanie agenta tworzy nowy Kubernetes [[Job]], który po zakończeniu jest usuwany. To odwrotność podejścia "persistent engine" stosowanego w kagent, LangChain, CrewAI.

## Jak to działa

```
Wiadomość użytkownika
    ↓
Channel Router tworzy AgentRun CR
    ↓
AgentRun Reconciler tworzy Job:
  - Agent container (LLM loop)
  - IPC Bridge sidecar
  - Skill sidecars (z efemerycznym RBAC)
  - Opcjonalnie: sandbox, MCP bridge
    ↓
Agent wykonuje zadanie (sekundy-minuty)
    ↓
Job ends → Pod usunięty → RBAC usunięty → Zasoby zwolnione
```

## Implikacje

### Izolacja (zalety)
- **Blast-radius** ograniczony do jednego poda - misbehaving agent nie wpływa na innych
- **Resource limits** per invocation - każdy run ma własne CPU/memory limits
- **[[SecurityContext]]** per run - każdy pod ma hardened security context
- **[[NetworkPolicy]]** per run - deny-all egress, tylko IPC bridge ma sieć
- **[[RBAC]]** per run - credentials istnieją tylko przez czas trwania runu

### Skalowanie (zalety)
- **Horizontal scaling** natywne - K8s scheduler rozkłada pody po nodach
- **No contention** - każdy run to osobny pod, brak współdzielenia procesora
- **Auto-cleanup** - Kubernetes garbage collection czyści po zakończeniu

### Cold start (wady i mitygacja)
- **Problem:** Każdy run = nowy pod = scheduling + image pull + container start
- **Typowy czas:** 5-30 sekund
- **Mitygacja 1:** Warm Pools (SandboxWarmPool) - pre-provisioned sandboxes
- **Mitygacja 2:** ImagePullPolicy: IfNotPresent - obrazy cache'owane na nodach
- **Mitygacja 3:** Tryb Server - Deployment zamiast Job dla long-lived scenarios

### Brak stanu (wady i mitygacja)
- **Problem:** Agent nie pamięta poprzednich konwersacji
- **Mitygacja 1:** Persistent Memory (SQLite + FTS5 na PVC)
- **Mitygacja 2:** Legacy Memory (ConfigMap MEMORY.md)
- **Mitygacja 3:** Session persistence (PostgreSQL)

## Porównanie z persistent engine

| Aspekt | Ephemeral (Sympozium) | Persistent (kagent, LangChain) |
|--------|----------------------|-------------------------------|
| Izolacja | [[Pod]]-level per run | Shared process |
| Cold start | 5-30s (mitygowany WarmPool) | ~0s (process already running) |
| State | External (memory, sessions) | In-process |
| Scaling | Horizontal native | Vertical only |
| Resource utilization | Pay-per-invocation | Always-on |
| Failure blast radius | Single pod | Entire engine |
| Audit trail | Pod logs, CRD status | Engine logs |
| RBAC | Ephemeral per-run | Standing ServiceAccount |

## Kiedy model efemeryczny?

Idealny dla:
- **Cluster operations** - kubectl, helm z izolacją
- **Scheduled tasks** - health checks, sweeps
- **Multi-tenant** - izolacja między tenantami
- **Security-sensitive** - untrusted agent code
- **Batch processing** - one-shot tasks

Mniej idealny dla:
- **Real-time chat** - cold start jest widoczny (ale tryb Server to rozwiązuje)
- **State-heavy workflows** - wymagają persistent memory

---

Powiązane: [[Cykl życia AgentRun]] | [[Agent Sandbox - gVisor i Kata]] | [[Sympozium vs kagent]]