Designing an AI agent for Kubernetes troubleshooting
I designed the first iteration of the Azure Copilot Troubleshooting Agent experience that investigates AKS issues, explains what it found, and helps engineers review a safe next action.
Problem
Troubleshooting a Kubernetes issue required engineers to correlate commands, events, configuration, logs, and monitoring data across several tools.
Vision
Let the agent gather evidence and form a diagnosis while keeping its progress, sources, and proposed actions visible.
Impact
The experience reached preview, and prototype testing showed that participants understood what required attention and how to proceed.
Troubleshooting required information from several systems.
A single Kubernetes failure can involve workloads, nodes, networking, configuration, events, and metrics. Engineers often move between portal pages, dashboards, command-line tools, and documentation before they can identify a likely cause.
- Resource state
- Commands
- Events
- Configuration
- Monitoring
Diagnosing one issue often requires evidence from several parts of the system.
The interaction model separates investigation from action.
I worked with product and engineering partners to define what the agent could do automatically and where human review was required. Evidence gathering and analysis could proceed while the agent worked; any resource-changing step remained visible and required confirmation.
- Gather evidence
- Analyze findings
- Propose a change
- Engineer reviews
- Explicit confirmation
The agent can investigate independently while the engineer retains control of changes.
The agent begins with the current cluster and issue in scope.
The entry point carries the selected AKS context into Copilot, reducing setup and helping the agent choose relevant checks. The interface makes the active resource and investigation scope visible before the agent begins.
Starting with the active resource gives the agent useful context before the first prompt.
Progress remains visible while the agent investigates.
The agent runs targeted Kubernetes commands and reads pod status, cluster events, resource metrics, and configuration to build a picture of the failure. Its activity groups into readable steps, so an engineer can follow what is being inspected and open the artifacts behind each one.
Investigation steps stay visible while the agent gathers evidence, and the run ends on a stated cause with remediation steps.
The result connects diagnosis, evidence, and a controlled next step.
The final response explains the likely cause, summarizes the supporting signals, and proposes a remediation path. Resource-changing actions remain reviewable, with explicit confirmation before execution or a clear path to additional support.
A repeatable interaction model for agentic troubleshooting.
The work balanced the speed of automated investigation with visible evidence and human control. In prototype testing, participants recognized what needed attention and understood the recommended next step, while proposed changes remained reviewable.
Speed was never the hard part of an agentic tool.
Keeping the investigation visible, and keeping every change behind an explicit confirmation, is what let people trust the answer enough to act on it.
Azure OpenAI for Developers
Helping developers get started with AI by doing, not just reading.
