Engineering

I built a DevOps tool that actually reads your cluster

Your AI agent is a historian. It has read every Kubernetes doc ever written, understands the architecture in the abstract, and then confidently guesses what's broken in your cluster.

30 July 2026 · 6 min read

Every Friday at 3am I'm on call, watching Slack like a hawk. My team builds solid things, but there's always one pod that decides to have an existential crisis when the office is closed. Last month I was staring at my screen thinking: why am I explaining what's happening to an AI agent that has zero idea what my cluster actually looks like?

I'm not saying Claude is dumb. Claude is terrifyingly smart. But it's like asking someone who studied architecture to diagnose why your house is on fire without letting them look at the house.

The problem nobody talks about

Most of what I do as an SRE is pattern-matching. A pod's crashing? There are a dozen reasons. OOMKilled? CrashLoop? Did someone deploy something careless? Did the network die?

When I started using Claude Code, I noticed it would ask incredibly intelligent, specific questions — about things my own cluster could have answered immediately. "What were the pod's previous logs?" So I'd copy-paste them. "Is this a resource constraint?" So I'd go check the requests by hand.

The irony was painful. I had this capable AI, and it was somehow less useful than a senior engineer who knew where to look. So: what if it could actually see the cluster?

Building it

The first prototype was rough. I gave Claude tools to read pod events, container logs, resource usage, networking info, and event timelines. Then something happened I didn't expect.

It started asking different questions. Better ones. Things like: "the logs show this error, but the resource request is set to 100Mi and the node only has 50Mi available — this is actually a resource constraint issue." It was connecting dots I would have had to piece together by hand.

Then came the scary part. I realised my AI could break my entire production environment if someone asked it to. Kubernetes is a loaded gun sitting on your desk; you can kubectl apply your way into disaster without much effort.

So I built a safety layer. An allowlist — not a denylist, because those get bypassed — that sits between the AI and your cluster and says: you can read things, but touching production? No. I made it open source, because if I'm asking people to trust an AI near production, they should be able to read exactly what's protecting them.

279 tests. 100% block rate on mutations, including the sneaky ones — flag injection, aliases, pipe chains, decode-and-execute.

The thing that changed everything

A few months in, I found something I genuinely did not expect. Kubernetes 1.36 made sidecars mainstream, and sidecars report their status in a different place — initContainerStatuses, not containerStatuses. Which means a pod can report phase: Running, looking perfectly healthy, while a sidecar inside it crashes every five seconds.

I found this out by running it on my own cluster and watching it fail. My AI read the pod status and said it was healthy. My monitoring said it was fine. My logs showed a sidecar exploding.

I've never felt that particular flavour of panic before. And then I realised: everyone else's agents have the same blind spot. They're not stupid — they're looking at incomplete data, and the industry is broadly fine with that.

Why it matters

AI is getting better at ops work, and that isn't inherently bad. But if we don't give it real information, we're building something that is confidently wrong. And confident-wrong is far worse than honestly-uncertain.

I showed it to other SREs and platform engineers. Most said some version of "wait, so it actually knows what's happening?" One said "finally, an AI that doesn't gaslight me about my own infrastructure." That comment lived in my head rent-free for two weeks.

Does it actually work?

Fair question. I tested it against a real minikube cluster with intentional failure scenarios — crash loops, OOM kills, pending pods, network issues. It found the root cause every time, with actual evidence:

"the container exited with code 137, which is OOMKilled. The memory limit is set to 512Mi, but it's using 520Mi."

I also tested against AWS in LocalStack, Terraform plans, and security findings. Full transparency: some things didn't work immediately and I had to iterate. GCP and Azure have no adequate local emulator for the services those agents cover, so they remain unverified content rather than tested content — that's stated in the benchmarks too. The point is I did the work rather than shipping vibes.

The install is one command — npx github:runopskit/opskit init. It points at your kubeconfig, and suddenly Claude can see what's happening.

The real talk

Am I overselling this? Maybe. Is it going to replace your SRE team? Absolutely not. Will it make you better at your job? I think yes.

Because most of my job isn't knowing everything — it's seeing the patterns in the noise. And right now you're asking an AI to see patterns without giving it the full picture.

That's what OpsKit fixes. $19 at launch pricing for a perpetual licence: 42 specialist agents, 34 investigation skills, 47 slash commands, and a safety layer you can audit before you trust it with anything.

If you're tired of explaining your cluster to an AI that doesn't understand it, it might be worth a look. Questions about whether it fits your setup: support@runopskit.com. I actually read those.