How RubixKube works

RubixKube is built around one idea: reliability is not a dashboard, it is a loop. A mesh of specialised agents runs that loop continuously against every environment you connect. Each pass through the loop leaves the system sharper than it was before. This page is the five-minute tour of how the pieces fit. Each piece has its own deep-dive linked below.

The short version

The OPEL loop

Observe, Plan, Execute, Learn. The rhythm every agent follows.

The Agent Mesh

Specialised agents that each own one slice of the loop.

The Memory Engine

Private knowledge that grows with every incident.

The Knowledge Graph

The live model of your stack that every agent shares.

Why a loop, not a dashboard

Traditional observability tools see your infrastructure for the first time every time you log in. Dashboards do not remember. Alerts do not learn. Every incident starts from scratch. RubixKube is built differently. A single OPEL loop runs across every environment, every hour of every day. It observes the state, plans what to do when state drifts, executes (with your approval) when a fix is needed, and learns from the outcome. The Memory Engine holds that learning. The next incident starts warmer than the previous one did.

What you see, and when

Day one: topology appears

The Observer walks every connected environment and builds a live Knowledge Graph. Services, nodes, dependencies, relationships. You see the shape of your stack in under an hour.

Week one: baselines settle

The system learns what normal looks like for every resource. Anomaly detection sharpens. Alert noise drops.

Month one: causality emerges

The Memory Engine has enough incident history to spot repeating patterns. RCA reports surface prior-art fixes alongside the fresh investigation.

Ongoing: compounding value

Every resolution you confirm feeds the graph. Every rejection teaches what not to recommend. The system is yours and only yours.

Where each agent fits

Each agent in the mesh owns one piece of the loop. None of them work in isolation. The shared Knowledge Graph is how they stay coordinated.

Agent	Role	Loop phase
Observer Agent	Watches every environment, collects signals	Observe
Memory Agent	Stores incidents, surfaces prior art	Observe, Learn
RCA Pipeline Agent	Builds causal chains from signals	Plan
SRI Agent	Powers Chat, invokes skills	Plan, Execute
Remediation Agent	Applies approved fixes safely	Execute
Guardian Agent	Enforces policies, bounds blast radius	Execute

Remediation and Guardian are live in production deployments. Observer, SRI, Memory, and RCA Pipeline are generally available today.

Where you start

The OPEL Loop

Read next if you want the mental model that makes everything else obvious.

Quickstart

Read next if you want to see it running against a real environment.

Common questions

Is this just another monitoring tool?

No. Monitoring tells you something is wrong. RubixKube tells you what is wrong, why it is wrong, and what to do about it. Every answer is cited back to the signal it came from.

Does RubixKube replace Prometheus, Datadog, or similar?

It does not have to. Those systems stay in place. Integrations are on the roadmap so their signal flows into the same Knowledge Graph your Observer is building. See Integrations.

What kinds of environments work?

Kubernetes (EKS, GKE, AKS, KIND, bare metal), AWS accounts, GCP projects, and Linux VMs. Azure on AKS works today via the Kubernetes path. Subscription-level Azure is on the roadmap.

How is my data handled?

The Memory Engine and Knowledge Graph belong to your workspace. They are not shared across tenants, and the raw signal streams stay inside the boundaries you configure. See Safety and Guardrails.

Connect your environment The OPEL Loop

​The short version