Ecosystem on Kubemoot

Kubemoot - the Controller

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

Kubemoot is the controller - the Kubernetes operator, agent runtime, and MCP components that turn declared crews into running, deliberating systems. It is the project everything else in this ecosystem is built on. A crew, an authoring tool, or a CLI is only useful because the controller reconciles the resources they produce.

What it includes

The operator (Go, controller-runtime) - reconciles the Kubemoot CRDs (Crew, Agent, Model, ModelProvider, MCPServer, MCPGateway, RAGSource, PromptModule, and the cluster-scoped KubemootConfig), and owns lifecycle: scheduling, finalizers, namespace and resource cleanup.
The agent runtime (Java/Quarkus + LangChain4j) - the process each agent runs as, which deliberates over the message bus, calls tools through the gateway, retrieves RAG knowledge, and emits consensus signals.
The MCP components - the gateway and the mcp-bridge sidecar that connect agents to tools.

What it does

The controller is the substrate; it carries no domain knowledge of its own. It provides the machinery - reconciliation, GPU-aware scheduling, the tool gateway, consensus orchestration, working memory, and observability - and the domain comes entirely from the crews that run on it. That separation is what lets one controller serve infrastructure ops, Kafka operations, research, or security work without change.

Crews

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

If the controller is the substrate, crews are what runs on it. The crews repository is a home for many crews - both the ones Kubemoot needs to operate and example crews that show how to build your own.

Internal and example crews

Internal crews are part of how Kubemoot works. The fitness judge crew, for instance, scores other crews’ fitness runs. These ship with the project.
Example crews demonstrate patterns you can copy - the clearest being Homelab Pilot, an infrastructure-operations crew that doubles as the reference implementation.

A growing catalog

The intent is an ecosystem of crews, not a fixed set. A crew is a portable Helm chart - agents, prompts, tools, and knowledge bundled together - so crews are meant to be shared and reused across clusters. As the catalog grows, crews are expected to be published to a registry such as ArtifactHub.io, the same way Helm charts and other cloud-native artifacts are distributed.

Pilot - a Reference Crew

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

Homelab Pilot is one reference crew - an example of what a Kubemoot crew looks like when it’s fully built out. It is not the product; the product is the controller. Pilot exists to demonstrate the controller with a complete, real crew you can read and learn from.

What it demonstrates

Pilot is an infrastructure-operations crew: its Toolers carry MCP tools for Kubernetes, Helm, Proxmox, and Prometheus, and its Analysts carry domain knowledge from Kubernetes, Proxmox, and Talos documentation. Ask it an operational question and the coordinator convenes the relevant Toolers, they investigate with their tools, Analysts reason over the findings in the REVIEW phase, and the crew settles on an answer.

kmctl - the CLI

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

kmctl (“kubemoot control”) is the command-line tool for working with crews and Kubemoot. It is the scriptable, terminal-native way to scaffold, apply, and exercise crews; CrewForge is the VS Code extension for developing crews and talking to them from the editor.

Status

kmctl is early and actively developed. It is installable from GitHub releases and ships a working command set covering cluster inspection, crew scaffolding, resource management, live conversation, fitness suite execution, and shell completion. Check your installed version with kmctl version, and see the GitHub Releases page for the latest. A small set of subcommands is still planned and marked as such in the reference page.