# Sympozium vs frameworki in-process

#sympozium #porównanie #langchain #crewai

## Kontekst

Frameworki in-process (LangChain, CrewAI, AutoGen, LlamaIndex) uruchamiają agentów w jednym procesie. Sympozium reprezentuje podejście "infrastructure-native".

## Porównanie architektoniczne

| Aspekt | In-process frameworks | Sympozium (K8s-native) |
|--------|----------------------|------------------------|
| **Wykonanie agenta** | Shared memory, single process | Ephemeral **Pod** per invocation |
| **Orkiestracja** | In-process registry + queue | **CRD-based** + controller reconciliation |
| **Sandbox** | Docker sidecar (long-lived) | Pod **SecurityContext** + Agent Sandbox |
| **IPC** | In-process EventEmitter | Filesystem sidecar + **NATS JetStream** |
| **Tool gating** | In-process pipeline | **Admission webhooks** + SympoziumPolicy |
| **Persistent memory** | Files on disk | **SQLite + FTS5** na PVC |
| **Scheduled tasks** | Cron jobs / external | **SympoziumSchedule CRD** |
| **State** | SQLite + flat files | **etcd** + PostgreSQL |
| **Multi-tenancy** | Single-instance file lock | **Namespaced CRDs** + RBAC |
| **Scaling** | Vertical only | **Horizontal** - stateless control plane |
| **Channels** | In-process per channel | Dedicated **Deployment** per channel |
| **External tools** | Plugin SDKs | **MCPServer CRD** + auto-discovery |
| **Observability** | Application logs | kubectl, OTel, TUI, Web UI |

## Dlaczego "infrastructure-native"?

Sympozium nie implementuje orkiestracji w kodzie aplikacji. Zamiast tego **mapuje koncepty agentowe na prymitywy Kubernetes**:

```
LangChain concept     →  Sympozium concept    →  K8s primitive
─────────────────────────────────────────────────────────────
Agent                 →  AgentRun              →  Job/Pod
Tool                  →  SkillPack sidecar     →  Container + RBAC
Memory                →  Memory server         →  Deployment + PVC
Chain                 →  Sub-agents            →  Parent-child Jobs
Guard rail            →  SympoziumPolicy       →  Admission Webhook
Scheduler             →  SympoziumSchedule     →  CRD + Controller
Callback handler      →  NATS events           →  JetStream pub/sub
Vector store          →  SQLite FTS5           →  PVC-backed DB
```

## Analiza trade-offs

### Complexity
- **In-process:** Prosty pip install, kilka linii Pythona
- **Sympozium:** K8s cluster, Helm install, CRDs, controllers

### Flexibility
- **In-process:** Dowolny Python code, łatwe prototyping
- **Sympozium:** Deklaratywny YAML, ograniczony do tego co CRDs oferują

### Production readiness
- **In-process:** Trzeba samemu zbudować izolację, scaling, monitoring
- **Sympozium:** Built-in isolation, scaling, monitoring, multi-tenancy

### Debugging
- **In-process:** Standard Python debugger, print statements
- **Sympozium:** kubectl logs, OTel traces, TUI, CRD status

## Kiedy co?

| Scenariusz | In-process | Sympozium |
|-----------|------------|-----------|
| Prototyping | Idealne | Overkill |
| Single developer | Idealne | Za dużo overhead |
| Production multi-tenant | Trudne | Idealne |
| Cluster operations | Niebezpieczne | Bezpieczne |
| Scheduled automation | Wymaga dodatkowej infra | Built-in |
| Compliance/audit | Wymaga budowy | Native |

---

Powiązane: [[Sympozium vs kagent]] | [[Kluczowe decyzje projektowe]] | [[Model efemerycznych agentów]]