Version Lineage

Version Lineage

KubeIntellect is one product told across several generations. Each is a self-contained re-architecture of the same idea — together they trace a deliberate path from a capability-maximal multi-agent system to a lean, measurable, human-governed operator.

Lineage: v1 (capability-maximal) → simplify → v2 (lean, measurable) → reframe → v3 (framework-delegated) → productionize → v4 (platform)

Version	What it is	Status	Contribute?
v4/	Platform (recommended). Lean coordinator + feature-flagged layers: sensorium + detector engine, memory hierarchy (episodes + temporal KG), flight recorder, autonomy ladder, predictive detection. uv monorepo.	Current	✅ Active
v2/	Lean baseline. A single LangGraph coordinator ReAct loop over 4 guarded tools with a kubectl safety guard and on-demand RCA.	Baseline	🔸 Fixes/docs
v3/	Framework-delegated. v2's behavior expressed through the deepagents framework — coordinator + sub-agents over a virtual filesystem with planning and delegation.	Experimental	🔸 Fixes/docs
v1/	Capability-maximal origin. LangGraph supervisor + 13 specialized agents, runtime tool synthesis, 100+ Kubernetes tools. The original published architecture.	Legacy	❄️ Frozen

Why re-architect instead of iterate?

Each generation answers a different question:

• v1 asked "how capable can an LLM-orchestrated K8s operator be?" — and got very capable, but large and hard to measure.
• v2 asked "what's the smallest thing that still works?" — a lean, measurable baseline.
• v3 asked "does delegating to a framework buy us anything?" — an honest experiment.
• v4 asks "how do we make this a platform teams can trust in production?" — feature-flagged layers, a hard safety gate, and observability built in.

Keeping every generation in one repo makes the design trade-offs legible and reproducible — which also matters for the research behind the project.

Which should I use?

v4/. It's the current, actively developed implementation. v1/ is the architecture in the published paper and is preserved as-is.