Introducing Kite AI Agent: Conversational Operations for Kubernetes

Managing Kubernetes clusters often involves a frustrating amount of context switching between a dashboard to visualize state and a terminal to actually get things done. Kite already simplifies this with a highly visual React and Go-based experience, but we wanted to take operational workflows a step further.

Today we are introducing the Kite AI Agent—a built-in, context-aware assistant powered by OpenAI and Anthropic models. This isn't just a chatbot that spits out generic Kubernetes documentation; it actively interacts with your cluster.

Why We Built It

Diagnosing a failing service usually looks like this:

1. Notice a deployment is failing in the dashboard.
2. Drill into the pods and find the crashing instance.
3. Fetch the pod logs.
4. Realize a ConfigMap is missing a crucial environment variable.
5. Open your terminal, edit the YAML, and apply the change.
6. Restart the deployment to pick up the new configuration.

The Kite AI Agent turns this multi-step process into a conversation. You can simply ask, "Why is the auth-service deployment crashing?" The agent will look at the deployment state, fetch the associated pod logs, identify the problem, and suggest a fix. If you tell it, "Add the missing API_URL to the ConfigMap and restart the deployment," it will generate the necessary patches and apply them.

What It Can Do

The agent is built leveraging LLM tool-calling (function calling). We've equipped it with a robust set of tools that allow it to safely read and mutate cluster state using standard Kubernetes APIs:

1. Contextual Diagnostics

Instead of chaining together multiple kubectl get and describe commands, you can query your infrastructure using natural language:

• Cluster Overview: Ask for a summary of cluster health, node counts, and overall resource usage.
• Resource Queries: "Find all pods in the production namespace that are currently in CrashLoopBackOff."
• Log Analysis: "Fetch recent errors from the payment-worker pod and summarize them."

2. Active Remediation

The AI agent isn't strictly read-only. It can modify infrastructure directly, making it an excellent tool for rapid fixes and prototyping:

• Patching: "Scale the frontend deployment to 5 replicas" or "Change the image tag of the worker daemonset to v1.2.0."
• Creation & Updates: "Create a NodePort service exposing the Redis deployment on port 6379."
• Cleanup: "Delete all failed pods and completed jobs in the default namespace."

Under the Hood

The Kite AI Agent runs entirely within our Go backend (pkg/ai). We built native integrations using the official Anthropic and OpenAI Go SDKs, giving you the flexibility to choose the model that best fits your workflow.

When you prompt the agent, it translates your intent into precise client-go API calls using dynamic clients (via unstructured types and discovery mapping). Tool calls like patch_resource or get_pod_logs are mapped directly to core Kubernetes APIs.

Because giving an LLM access to your infrastructure requires strict guardrails, the agent heavily relies on Kite's existing Role-Based Access Control (RBAC) implementation. The agent operates strictly within the boundaries of the logged-in user's permissions—it cannot perform actions or access namespaces that the user is not authorized to see.

Getting Started

https://github.com/kite-org/kite/releases/tag/v0.8.0

To try out the agent, pull the latest version of Kite, navigate to the AI configuration panel, and add your API key for OpenAI or Anthropic.

We are actively expanding the agent's toolbelt to handle more advanced operational workflows, including multi-cluster diagnostics and prometheus query tools.

[Gingiris]

This is a great direction — turning multi-step debugging workflows into conversations is exactly where K8s ops should be heading.

A few thoughts from watching similar tool-calling agent patterns:

1. Confirmation UX matters a lot. You mentioned the agent can "apply" patches directly. In my experience, the sweet spot is showing a diff preview + requiring explicit confirmation for any mutating action. Users trust agents more when they can review before commit.

2. Error recovery is underrated. When a patch fails (wrong resource version, immutable field, etc.), the agent's ability to gracefully explain what went wrong and suggest alternatives is often more valuable than the initial suggestion. Worth investing in good error-to-natural-language mapping.

3. Multi-cluster will be huge. You mentioned it's on the roadmap — this is where conversational ops really shines. "Compare the resource usage of auth-service across staging and prod" without manually switching contexts is a massive time saver.

Feature idea: Consider a "dry-run" mode where the agent explains what it would do without actually executing. Great for learning and for users who want to understand the underlying API calls before giving full trust.

Excited to see where this goes. The RBAC-scoped execution is the right foundation.