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

3.1 KiB Raw Permalink Blame History