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 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 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-crdson the second command assumes you installedsympozium-crdsfirst. If you skip the CRDs chart, drop--skip-crdsso the bundled CRDs in thesympoziumchart 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 |
| Mediated Model Access | By default a model gateway holds provider keys, so hardware-isolated agents never see one. Built-in routes cover OpenAI, Anthropic and DeepSeek (any model), and approved local servers work keyless. See the mediation guide |
| Serving Mode | Run an agent as a long-lived, OpenAI-compatible + MCP HTTP endpoint instead of a one-shot Job — agents as services |
| Observability & Cost | OpenTelemetry traces and metrics, Prometheus endpoints, per-run trace IDs, and token usage with estimated cost on every AgentRun |
| Celln Tool Catalogue | Hardware-isolated agents borrow real programs (grep, sed, awk, jq, …) taken from container images pinned by digest, never reimplemented. Every borrowed tool names the image layer it came from, and operators extend the toolbox by adding an image to the catalogue, no rebuild. See the fleet guide |
| Any AI Provider | OpenAI, Anthropic, AWS Bedrock, Azure, Ollama, or any OpenAI-compatible endpoint (Groq, Mistral, DeepSeek, OpenRouter, vLLM, LM Studio, …) — no vendor lock-in |
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