Getting Started on Kubemoot

Why Kubemoot

Mon, 01 Jan 0001 00:00:00 +0000

Kubemoot runs agentic AI as a committee of small, specialized models that deliberate to consensus - on your own Kubernetes cluster, declared as Kubernetes resources, and measured by executable fitness functions. This page is about where that fits, what it solves, and how it differs.

Where it started, and where it can go

Kubemoot began as a small agent system to help with observability, security, and administration on one homelab cluster, and grew into a general way to run crews of agents on Kubernetes. Today it works well on local clusters with a couple of GPUs or more, running open models you serve yourself.

Overview

Mon, 01 Jan 0001 00:00:00 +0000

Kubemoot is a Kubernetes operator and runtime for multi-agent AI consensus. A question is answered not by one model but by a crew of small, specialized agents that deliberate over a message bus and settle by signal. Everything - the crew, its agents, their prompts, and the models they use - is a Kubernetes resource you declare and version like any other.

The mental model

A moot is an assembly that reaches a decision by deliberation. In Kubemoot:

The Orchestration Gap

Mon, 01 Jan 0001 00:00:00 +0000

A prototype agent is easy to build and hard to operate. The distance between “it works on my machine” and “it runs as dependable infrastructure” is where most agentic AI projects stall. This page describes that distance, and why neither the frameworks above it nor Kubernetes below it closes it.

From prototype to production

Building an agent is a good experience today. You wire up a framework (LangChain, LlamaIndex, an SDK), point it at a model, add a retriever and a few tools, and it works on your laptop against test data. Then it has to run for real, and a different set of questions starts:

Quickstart

Mon, 01 Jan 0001 00:00:00 +0000

This is a laptop trial: one script takes an empty Kubernetes cluster to a real crew answering a real question, on CPU, with no GPU required. It runs the same protocol as a production deployment - a coordinator convening a Tooler, signals exchanged over NATS, an answer synthesized - just smaller and slower, because it runs on CPU with a 1-3B model instead of a GPU with a reasoning-sized one. See Installation for the GPU-backed deployment this trial is a preview of, and the profile table below for exactly what’s smaller and slower.

Install the Operator

Mon, 01 Jan 0001 00:00:00 +0000

This page installs the Kubemoot operator: what a cluster needs before it runs, and how to install it on your own cluster - the GPU-backed deployment Kubemoot is built for. If you want to try the protocol first without a GPU, the Quickstart runs a smaller CPU-only trial with its own script and its own limits, described below.

The operator is one part of the ecosystem. The others install separately, each from its own page:

Questions

Mon, 01 Jan 0001 00:00:00 +0000

Short answers, each one a position you can hold us to, with the page that backs it.

Why not just use Claude Code with a frontier model?

Often you should. A frontier model wins open-ended, one-off work where data may leave your network and per-token cost is acceptable. Kubemoot is for the other situation: data that stays home, cost that is fixed by hardware rather than by usage, behaviour governed as code, and agents that run where your platform already runs, under its RBAC, quotas, and lifecycle. It is not either-or: Claude Code can use a crew as one agent through the crew liaison, the frontier model at the edge and the private crew on the domain work. We do not claim that a crew of small models out-reasons a frontier model; that is not what it is for. What a crew does give you is the choice of where the compute is spent: tokens billed by a provider, or watts on hardware you run.

Related Projects

Mon, 01 Jan 0001 00:00:00 +0000

A common first question is “how is this different from X?” This page answers it for the projects people ask about most. Each entry says what the project is, where it overlaps with Kubemoot, and where the two differ. Several of these are the better choice for some jobs, and the entries say so. Descriptions of other projects are summaries of their own documentation; read their sites for the current picture.

Roadmap

Mon, 01 Jan 0001 00:00:00 +0000

Kubemoot is young. If a capability you expect is missing, it is more likely on this page than rejected. This page lists the significant directions under consideration or in progress: the ones that change what a crew can be. Small features, conveniences, and fixes live on the project board, not here. Each item says what exists today, so nothing below is mistaken for something already shipped.

Ideas become work in the open: propose or argue for one in Discussions.

About the Name

Mon, 01 Jan 0001 00:00:00 +0000

In Anglo-Saxon England, a moot (or gemōt) was an assembly gathered to deliberate and reach a decision. From village moots to the great Witenagemot that advised kings, these assemblies embodied a principle: better decisions emerge when diverse perspectives contribute to a shared deliberation.

Readers of Tolkien know another one. In The Two Towers, the Ents hold an Entmoot to decide whether to march on Isengard: a gathering in a hidden dell, unhurried, where every Ent speaks and nothing is decided until all have. It takes three days. A Kubemoot crew takes minutes, which is still slower than one model asserting an answer, and for the same reason: the answer is not one voice’s.