Sympozium: a Kubernetes control plane for multi-agent AI

The premise: agents need coordination the way containers needed orchestration

Sympozium describes itself as the coordination layer for multi-agent AI, and the framing line in the documentation is the argument. Containers needed orchestration, agents need coordination. The project positions itself as a Kubernetes-native coordination layer for multi-agent systems, solving the problem Kubernetes solved for containers but for agents that need to share context, hand off tasks and maintain shared situational awareness. The mechanism it proposes is selective permeability, structured handoffs and shared memory, with agents running in isolated workloads and every policy expressed as a custom resource definition. The author is the creator of k8sgpt and llmfit, which is the background that explains the choice of Kubernetes as the substrate. It is written in Go, released under the MIT licence, published on sympozium.ai, and the documentation carries an unusually direct warning that the project is under active development, that the APIs will change and that things will break.

Coordination is the product, placement and serving are not

The most interesting decision in the project is what it refuses to do, and the documentation is unusually clear about the boundary. Sympozium decides what agents do. Where compute happens is the job of a capability layer, namely llmfit-dra, a Kubernetes DRA driver that places models by physics through the stock scheduler. How tokens move is the job of the serving engine, with vLLM, SGLang and llama.cpp named as examples. The analogy the project uses is that when an agent needs a model, Sympozium claims one the way an application claims a PersistentVolume, and it never decides where that model runs. For an adopter this matters twice over. It means the coordination layer can be evaluated without adopting a new model placement system, and it means the boundary is likely to move, since a driver that places models by physics is a young piece of infrastructure.

Agents in isolated workloads, with policy as a CRD

The design principle is that agents do not share a process, they run in isolated workloads, and the rules about what they may do are Kubernetes objects rather than configuration files. That is what the CRD story buys. A policy can be reviewed, versioned and applied with the same tooling as any other cluster resource, and an agent that misbehaves can be stopped by removing the object that authorised it rather than by patching code. The AgentHarness section describes the same idea from the runtime side. It is available experimentally, and the documentation asks for an administrator-approved external adapter running in an isolated AgentRun, or a session-capable runtime for a private, continuing agent to chat conversation, with Kubernetes policy, identity, skills, memory, MCP, observability and audit staying under platform control. The wording is careful: this is an adapter boundary, not permission to run arbitrary upstream images, and the reference adapter in examples/harness-reference/ is digest-pinned.

Quick install: a tap, a shell script, and one cluster command

The install path for macOS and Linux is short. Homebrew is supported with a tap:

brew tap sympozium-ai/sympozium
brew install sympozium

Or a shell installer:

curl -fsSL https://deploy.sympozium.ai/install.sh | sh

Then the cluster side is a single command that does several things, followed by the two entry points, a terminal interface and a web dashboard:

sympozium install          # deploys CRDs, controllers, built-in Ensembles, the Celln plane and ergoz
# With DEEPSEEK_API_KEY, OPENAI_API_KEY or ANTHROPIC_API_KEY set (or a prompt in a
# terminal), the same command installs the Celln fleet: every node with KVM runs
# hardware-isolated, long-running agents for every namespace, on any number of
# nodes. Model access is mediated by default: a gateway holds provider keys, nodes
# never do, the key you gave becomes the `starter` Agent's own key, and every other
# Agent brings its own. No further flags (opt out with --no-celln-mediation).
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 model mediation detail is the one with security weight. The key you supply becomes the starter agent's own key, every other agent brings its own, and the nodes never hold provider keys at all, because a gateway holds them.

The Celln fleet needs KVM, a kernel image, and a patient install

Cells are microVMs, and that is the operational reality of the design. The fleet runs on nodes that have /dev/kvm and a kernel image under /boot, with each cell booted by a virtual machine monitor from that file, and a node probe labels qualifying nodes with celln.dev/kvm=true. Kind is described as a development environment only, because 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 running kernel into the node:

docker cp /boot/vmlinuz-$(uname -r) kind-control-plane:/boot/   # and each worker

On macOS or Windows, Kind runs inside a virtual machine without /dev/kvm and cannot run the fleet at all, and the documentation notes that the installer prints a hint if no node has qualified within the first minute of its wait. That detail is worth internalising: the failure mode of the quick install is not an error message but a wait, which is a rough first experience for anyone who tried this on a laptop.

Helm install splits the CRDs from the control plane

For anything beyond a demo, the documentation recommends Helm, and the split into two charts is the interesting part. cert-manager is a prerequisite because the webhooks need TLS, and the certificate manager manifests are applied directly:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.1/cert-manager.yaml

Then the two charts, the CRDs first so they can be upgraded independently, and the control plane second:

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

The --skip-crds flag on the second command assumes the CRD chart went in first, and the documentation explains the alternative: drop the flag so the CRDs bundled in the main chart are applied instead. Configuration lives in charts/sympozium/values.yaml, with a fuller reference in the Helm chart documentation.

Nine binaries, four chat channels, and a growing dependency surface

The Makefile is the fastest way to understand the scope. It builds nine binaries, controller, apiserver, ipc-bridge, webhook, agent-runner, sympozium, web-proxy, node-probe and model-gateway, plus a channel binary for each of telegram, whatsapp, discord and slack. The image list adds skill images for k8s-ops, sre-observability, github-gitops, llmfit and memory, an llmfit-daemon, an mcp-bridge and the harness reference. The Go module shows the technology choices: NATS for messaging, cobra for the CLI, bubbletea and lipgloss for the terminal interface, OpenTelemetry with OTLP exporters for logs, metrics and traces, the AWS SDK with Bedrock, the Anthropic and OpenAI Go SDKs, pgx for Postgres, the Prometheus client, a JSON Schema validator, blake3 for hashing, and even a WhatsApp library. The go directive is 1.26.4, and the project ships a Makefile target for release notes through release-please with a manifest. The releases are frequent, v0.11.6 on 2026-10-16, v0.11.5 on 2026-10-12 and v0.11.4 on 2026-10-08, with the last push to the repository on 2026-10-16.

Editorial conclusion

Sympozium suits teams already running agents on Kubernetes who need isolation, policy and audit rather than a shared process, since the whole design is expressed as custom resources and controllers. It is the wrong tool for a single agent on one machine, and for a team that will not run KVM nodes, because the Celln fleet requires hardware isolation that a Kind cluster cannot provide on macOS or Windows. Before adopting it, read the note that the project is under active development and that the APIs will change, and confirm the node requirements, since the install waits for a node that satisfies the KVM and kernel image probe.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sympozium-ai/sympozium on GitHub