This deep dive expands on the Loop Asia conversation with Nilesh Gule, Enterprise Architect, Microsoft MVP, and Docker Captain.

Buried in the K8sGPT conversation with Nilesh Gule is a decision most technology leaders will face soon, noticed or not: when an AI system can see everything wrong with your production environment, how much should it be allowed to do about it?

Nilesh's answer was unambiguous: K8sGPT diagnoses, it doesn't remediate. Asked whether the tool should self-heal, he said he'd love that in principle — but letting a system make unsupervised changes to Kubernetes configuration without full context "could cause a lot of problems." The fix stays with a human who understands the surrounding state. That's a design position, not a limitation — from someone with the depth to build the alternative.

That position generalises well past Kubernetes.

The three-tier model hiding in a two-minute answer

Asked where tools like this go next, Nilesh described something more nuanced than "always ask a human" or "let it run free": full self-remediation for the narrow set of issues that are low-risk and unambiguous — a mistyped image tag, a port mapping that's obviously wrong — while anything with real blast radius stays gated behind a human decision. Diagnosis is always automatic; remediation only where being wrong is cheap and being right easy to verify.

That's a useful frame for any leader working out where AI agents belong in operational systems generally: not whether a system should have AI in it, but what the blast radius of a given action is, and whether confidence in the model's judgment matches it. Most organisations skip that question and apply one policy — agents can act, or they can't — to an entire system, when the right answer varies action by action.

Read access is not the same decision as write access

Nilesh's description holds a second distinction. K8sGPT's value depends on broad, deep read access — pod states, resource limits, ingress, event logs — or it can't diagnose anything. That's a lower-risk grant than write access, and it's where most of the tool's value sits: the savings come from compressing the diagnostic flowchart, not removing the fix step.

Organisations moving fast on an AI mandate tend to conflate the two grants — different risk profiles — because the vendor pitch makes it sound like one decision. Separating them — what can this agent see, versus what can it change — is a cheap governance move: most systems already have the controls for it. It just needs to be designed in.

Sovereignty by design, not by accident

K8sGPT is backend-agnostic — OpenAI, Azure OpenAI, Amazon Bedrock, Gemini, Oracle, Hugging Face, Watson, or Ollama running locally. Nilesh flagged Ollama as a cost lever, but it's also a control lever: an organisation worried about what leaves the cluster can point the tool at a self-hosted model instead of a frontier API, without rewriting the integration. That's architecture doing governance's job before governance has to intervene.

The pattern underneath the tool

None of this is really about Kubernetes. It's a working example of a problem boards are handing down without a framework: deploy AI into the operational core of the business. K8sGPT's designers had to answer exactly those scoping questions — what can it see, what can it touch, where does the backend need to sit — to ship a credible product. Full visibility, gated action, portable backend is a reasonable template for any AI agent touching production systems, not just container orchestration.