Skip to main content
Deploy this agent when one cluster needs an investigator that can read the cluster itself, the telemetry around it, and — where you run them — the GPUs underneath it. It is the combined alternative to running a cluster investigator and a telemetry investigator side by side. This page covers what it reaches, the access it needs, and where it stops.

What it does

You describe what is wrong and it investigates across all three signal sources at once: reading cluster state through read-only kubectl, pulling the metrics, logs and traces around the incident from Grafana, and checking GPU health where the workload depends on it. It reconstructs the change timeline and returns a structured root-cause analysis. The point of combining them is correlation that neither half can do alone — a pod restarting because of a GPU fault looks like an ordinary crash loop until something reads both.

What it reads

All of it read-only, apart from the in-pod diagnostics noted below. It carries the same domain knowledge as Kubernetes RCA — twenty-three workload-specific methods — plus five GPU-specific ones.

Before you deploy

The Grafana connection is optional because the agent can instead reach your own in-cluster MCP server, or run its own bundled Grafana tooling. Add a connection only to use the built-in path. Without any of the three, it still investigates the cluster — it simply has no telemetry to correlate against.
The install grants the same cluster access as Kubernetes RCA: Kubernetes’ aggregated view role, a supplemental role for the cluster-scoped reads it omits, and pods/exec for the workload methods that diagnose from inside the pod. Exec is a separate value, so you can narrow it to named namespaces or remove it and let those methods fall back to resource state.

Ask it for

In chat, or as a run’s prompt:

Defaults and limits

The time budget degrades rather than fails. At 70% the agent is nudged to converge; at 100% further tool calls are refused and it reports what it has.

In a workflow

It is a specialist bound to one cluster, so a step targeting it has already established which cluster the problem is in. Because it covers three signal sources, it often replaces two steps that would otherwise run in parallel and need synthesizing afterwards. See Orchestration for how a step delivers work to it.

What it will not do

It changes nothing in the cluster or in Grafana. Its non-read grant is confined to a fixed list of read-only in-pod diagnostics, and everything else is refused. It sees exactly one cluster. Deploying one instance and expecting it to answer for a fleet is the mistake worth avoiding — run one per cluster, and name each after the cluster it watches.

Next steps

Kubernetes RCA

The cluster half alone, with no external data sources.

Grafana Investigator

The telemetry half alone, across clusters.

Deploy an agent

Install a self-hosted worker into your cluster.

Agent catalog

Every catalog agent, side by side.