Full documentation: deploy.sympozium.ai/docs
[!IMPORTANT]
AgentHarness is available experimentally. Run an administrator-approved
external adapter in an isolated AgentRun, or choose a session-capable runtime
for a private, continuing Agent → Chat conversation. Kubernetes policy,
identity, skills, memory, MCP, observability, and audit remain under platform
control. Start with the AgentHarness guide
and the digest-pinned reference adapter. This
is an adapter boundary—not permission to run arbitrary upstream images.
Quick Install (macOS / Linux)
Homebrew:
brew tap sympozium-ai/sympozium
brew install sympozium
Shell installer:
curl -fsSL https://deploy.sympozium.ai/install.sh | sh
Then deploy to your cluster and activate your first agents:
sympozium install # deploys CRDs, controllers, built-in Ensembles, the Celln fleet, the model gateway and ergoz
# The same command installs the Celln fleet: every node with KVM runs hardware-isolated,
# one-shot and long-running agents for every namespace, on any number of nodes. The
# fleet's two DaemonSets are privileged (booting micro-VMs needs /dev/kvm, /boot and
# /lib/modules) and the install says so first. Nothing about models is asked: each Agent
# brings its own ModelConnection and key, the gateway adds it per call, nodes never hold it.
sympozium # launch the TUI — go to Ensembles tab, press Enter to onboard
sympozium serve # open the web dashboard (port-forwards to the in-cluster UI)
The Celln fleet runs on nodes that have /dev/kvm and a kernel image under
/boot (each cell is a microVM; the VMM boots it from that file); the node
probe labels such nodes celln.dev/kvm=true. Kind is a development
environment only. On a Linux host, Kind nodes already see /dev/kvm but
ship without a kernel image, so a plain install waits for a node that never
qualifies. The mitigation is to copy the host's running kernel into each node;
the probe labels it within seconds:
docker cp /boot/vmlinuz-$(uname -r) kind-control-plane:/boot/ # and each worker
Kind on macOS or Windows runs inside a VM without /dev/kvm and cannot run
the fleet at all. The installer prints this hint if no node has qualified
within the first minute of its wait.
Advanced: Helm Chart
Prerequisites: cert-manager (for webhook TLS):
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.1/cert-manager.yaml
Sympozium can be installed as two charts: sympozium-crds (the CRDs, so they can be upgraded) and sympozium (the control plane). Install the CRDs first, then the control plane:
helm repo add sympozium https://deploy.sympozium.ai/charts
helm repo update
helm upgrade --install sympozium-crds sympozium/sympozium-crds \
--namespace sympozium-system --create-namespace
helm upgrade --install sympozium sympozium/sympozium \
--namespace sympozium-system \
--skip-crds --set createNamespace=false
--skip-crds on the second command assumes you installed sympozium-crds
first. If you skip the CRDs chart, drop --skip-crds so the bundled CRDs
in the sympozium chart are applied instead.
See charts/sympozium/values.yaml for configuration options, or the Helm Chart docs for the full guide.
Why Sympozium?
Containers needed orchestration. Agents need coordination.
Sympozium is a Kubernetes-native coordination layer for multi-agent AI systems. It solves the same problem Kubernetes solved for containers — but for agents that need to share context, hand off tasks, and maintain shared situational awareness.
And that is the whole product. Sympozium decides what agents do. Where compute happens is the job of a capability layer — llmfit-dra, a Kubernetes DRA driver that places models by physics through the stock scheduler. How tokens move is the serving engine's job (vLLM, SGLang, llama.cpp). When an agent needs a model, Sympozium claims one the way an application claims a PersistentVolume — it never decides where it runs. See Positioning for the boundary and what's deliberately out of scope.
Evaluating Google's AX and Agent Substrate? Read Sympozium vs Google AX, an honest comparison that includes where they are ahead (idle-agent density, suspend/resume, control-plane scale) and how the two could fit together.
Agent Coordination
| |
|---|
| Synthetic Membrane | Selective permeability for agent teams — control what agents share via trust groups, visibility tags, and field-level gating. Read the paper |
| Agent Workflows | Delegation, sequential pipelines, supervision, and stimulus triggers between personas — visualised on an interactive canvas |
| Shared Workflow Memory | Pack-level SQLite memory pool for cross-persona knowledge sharing with per-persona access control and time decay |
| Ensembles | Helm-like bundles for AI agent teams — activate a pack and the controller stamps out Agents, Schedules, and memory |
Platform Infrastructure
| |
|---|
| Model Endpoints for Agents | Declare models as CRDs — GGUF or HuggingFace weights are downloaded, an inference server (llama.cpp, vLLM, TGI, or custom) is deployed, and OpenAI-compatible endpoints are exposed for your personas. No API keys required. Placement is claimed, not decided here: with llmfit-dra installed, the stock scheduler places models by physics |
| Skill Sidecars | Every skill runs in its own sidecar with ephemeral least-privilege RBAC, garbage-collected on completion |
| Multi-Channel | Telegram, Slack, Discord, WhatsApp — each channel is a dedicated Deployment backed by NATS JetStream |
| Persistent Memory | SQLite + FTS5 on a PersistentVolume — memories survive across ephemeral pod runs |
| Scheduled Tasks | Cron-based recurring agent runs for periodic workflows, data syncs, and automated checks |
| Agent Sandbox | Kernel-level isolation via kubernetes-sigs/agent-sandbox — gVisor or Kata with warm pools for instant starts |
| MCP Servers | External tool providers via Model Context Protocol with auto-discovery and allow/deny filtering |
| TUI & Web UI | Terminal and browser dashboards with live workflow canvas, or skip the UI entirely with Helm and kubectl |
| Policy & Governance | SympoziumPolicy CRD — tool gating (allow/deny, enforced on every run), sandbox requirements, network egress rules, image-registry allowlists, and whether skills may touch Secrets |
| One Key per Agent | Every Agent uses its own model key; only its sub-agents share it. The key's owner is recorded on its Secret and checked by the controller, the admission webhook and, on every call, the model gateway. Skills cannot read Secrets or start pods that do unless a policy allows it. See Security |
| Agent-Bound Model Access | Celln holds no model. Each Agent's (any OpenAI- or Anthropic-compatible endpoint) is its route; its key is owned by that Agent, pinned to that endpoint's origin, and added per call by a model gateway that re-checks everything on every request. Operators may narrow destinations by host pattern and approve private endpoints once. See the |
Documentation
Development
make test # run tests
make test-system # run envtest system tests (no cluster needed)
make lint # run linter
make manifests # generate CRD manifests
make run-controller # run controller locally (needs kubeconfig)
License
MIT License
