Onboarding Guide

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

Overview

When no agent in a crew can answer a question, the coordinator signals a capability gap. An agent running in onboarding mode reacts to that signal: it proposes an MCP server that could fill the gap. On the user’s consent it replies with a proposed MCPServer manifest in the discussion thread. Applying that manifest, and creating the Tooler Agent that uses it, are manual steps today.

This page describes what ships today, how to enable it, and what is not automated yet. For the consensus signals that produce a gap, see Agentic Consensus.

Kubemoot Dashboard

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

Overview

The Kubemoot Dashboard is a web UI for looking at a running Kubemoot installation. It lists Kubemoot resources across namespaces, shows GPU node and model state, and streams agent discussions and NATS messages as they happen. It is a SvelteKit application that reads the Kubernetes API and the NATS bus from the server side; the browser never connects to either directly.

Metrics, logs, and traces are not part of the dashboard. For those, see Observability.

Kubemoot Observability

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

How to observe what a Kubemoot crew is doing: the data it exposes, the surfaces that render it, and the external observability stack it depends on. For the dashboard UI itself see dashboard.md; for the consensus protocol that produces most of this data see agentic-consensus.md.

What you can observe

Domain	Signals	Where it comes from
Discussions / consensus	Thread lifecycle, per-agent signals (`triaging`, `evaluating`, `waiting`, `agree`, `concern`, `stand_aside`, `failure`, `block`, `advisory`, `synthesis`), settle decisions, synthesis text	Coordinator + agents publish to NATS `kubemoot.discuss.<namespace>.<crew>.*`
Agent activity	Heartbeats while GPU-queued, triage vs evaluation phases, per-call provider attribution (which model/provider/GPU served each call)	Agent runtime signals + metadata
GPU & scheduling	Loaded-model footprints, in-flight tickets, provider readiness, total/used VRAM, scheduling decisions	Operator-published provider state (NATS KV) + DCGM
Quality	MCP tool quality verdicts (hot/failing/out-of-norm)	MCP quality pipeline → `kubemoot.quality.*`
RAG indexing	Source indexing progress, chunk/embed status	RAGSource controller
Fitness	Per-scenario/iteration pass-rates, assertion results, durations, full conversation transcripts	`CrewFitness` / `CrewFitnessSuite` → XLSX in NATS Object Store

Surfaces

Kubemoot Dashboard: the primary real-time view (discussion threads & timeline, agent topology, NATS messages, fitness suites, GPU/model activity). Updates push-style via NATS JetStream SSE and k8s watch→SSE. See dashboard.md.
NATS JetStream: the event substrate. Streams: KUBEMOOT_CHRONICLE, KUBEMOOT_QUALITY, KUBEMOOT_CHAT, KUBEMOOT_OPERATOR, KUBEMOOT_DISCUSS. Anything the dashboard shows is reconstructable from these.
Prometheus metrics: the agent runtime exposes Micrometer/Prometheus-format metrics; DiscussionMetrics (ai.kubemoot.agent.nats) covers inference timings, token usage, signal counts, and thread/synthesis completion.

The three pillars of observability

Kubemoot leans on the cluster’s existing observability stack rather than shipping its own. The three pillars (metrics, logs, spans) are at different stages.

Operating on Kubemoot

Onboarding Guide

Overview

Kubemoot Dashboard

Overview

Kubemoot Observability

What you can observe

Surfaces

The three pillars of observability