Architecture on Kubemoot

Kubemoot Architecture - Distributed Consensus vs Single-Model Orchestration

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

“Kubemoot composes capability horizontally - many small specialists, because no single model is big enough to do it all; intelligence is emergent from a committee. A single-model agent is the opposite: capability concentrated in one large reasoner that drives tools and, when needed, spawns copies of itself.”

a single-model coding agent, contrasting itself with Kubemoot

Purpose

There are two broad shapes an agentic system can take. Kubemoot is one of them; most well-known agent systems are the other. The fastest way to understand why Kubemoot is built the way it is - many small models, a coordinator, consensus signals over a message bus - is to hold it next to its opposite and see what each shape buys and costs.

Agentic Consensus

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

Kubemoot answers a question by convening the agents whose expertise fits it, letting them investigate and deliberate, and settling on a synthesis once the crew has spoken. This page is the architecture behind that: how the coordinator selects who takes part, what a consensus signal means to the protocol, and why a discussion settles by state rather than by a clock. For the concept-level model (roles, phases, signal vocabulary) see Crews & Agents, The Moot, and Signals & Protocol - this page assumes them and goes one level deeper into the coordinator’s mechanics.

Tooler-Analyst Architecture

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

Two Roles That Serve Different Phases

Kubemoot organizes the data-gathering and reasoning work of a discussion into two complementary roles that mirror how real teams operate: Toolers who interact with live systems, and Analysts who reason over what the Toolers found.

	Toolers (MCP)	Analysts (RAG)
Phase	EVALUATING	REVIEW
Declared	Agents with MCP tools	Agents with embedded domain docs
Self-discovered	Onboarding agent deploys new MCP servers	RTFM agent indexes new documentation
Carries	MCP tools, no live tools in reasoning	RAG sources, no MCP tools
Thinking	OFF (deterministic tool selection)	ON (reasoning over gathered data)
Analogy	The person with their hands on the keyboard	The person with the manual open, weighing the evidence
GPU profile	Heavier (tool-calling inference)	Lighter (reasoning-focused, no tool overhead)

Why Separate Them

LLMs have a practical limit on how much context they can process while still reliably selecting tools and interpreting results. When a single agent carries both MCP tool schemas and RAG documentation in its system prompt, the prompt bloats and tool selection degrades. Separating concerns gives each agent a smaller, focused prompt: Toolers are better at picking the right tool, Analysts are better at weighing the evidence from those tools.

Scheduling - reminders, follow-ups, recurring

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

One sentence: a crew’s scheduler-advisor Tooler agent calls the scheduling-mcp server’s tools to write ScheduleRecords into the NATS KV bucket kubemoot_scheduled; the operator’s scheduler poller fires due records - either inline in the originating thread or as a new thread, depending on kind x whether a sourceThreadId was attached.

Why this exists

Some discussions are inherently temporally driven:

Reminder - “Remind me in 30 minutes to check the backup job status.”
Follow-up - “Re-check disk usage in an hour” / “Run the weekly health summary every Monday.”
Recurring - daily/weekly admin checks, configured by a cluster admin rather than via chat.

All three reduce to: publish a discussion message at a future time, in the right place. This module provides the primitive.

Kubemoot Scheduler

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

Audience: operator and agent-runtime developers; developers of the ecosystem tools (CrewForge, kmctl); open-source consumers.

One-Paragraph Summary

Kubemoot is an LLM orchestrator. Like kube-scheduler matches Pods to Nodes based on resource requests, the Kubemoot scheduler matches agents to (Model, Provider) bindings based on capability requirements. Agents declare what they can do (capabilities), Models declare what they are (family, params, capabilities) as labels, ModelProviders declare what they have (VRAM, parallelism), and a CrewSchedulingPolicy CRD expresses require/prefer rules using Kubernetes-style label selectors. The match is computed in the agent reconciler via filter → score → bind; the resolved (model, provider, endpoint) is applied to the agent’s Deployment.