New Relic's Autopilot Kubernetes Agent Hits Public Preview
New Relic's Autopilot Kubernetes Agent, now in public preview, runs 90+ diagnostic detectors to find root causes in cluster incidents and generates remediation code for engineer review.

Why it matters
- New Relic launched the Autopilot Kubernetes Agent in public preview.
- The agent runs more than 90 diagnostic detectors across Kubernetes events, logs, object descriptions and APM traces.
- Cloud Native Computing Foundation research cited by New Relic shows 66% of organisations running generative AI rely on Kubernetes.
- The agent uses the Ground Truth context engine, built on OpenTelemetry, to identify likely causes and generate fix code.
- Chief Product Officer Brian Emerson said the tool embeds agentic AI into containerised workflows while keeping engineers in control.
New Relic has put its Autopilot Kubernetes Agent into public preview, a tool that runs more than 90 diagnostic detectors across cluster data and generates remediation code for engineers to review and execute.
The launch targets operations teams — Site Reliability Engineers and Platform Engineers — who work in Kubernetes environments where fault diagnosis and recovery are hard. That difficulty has real business weight in Australia and New Zealand, where Kubernetes has become central to application infrastructure for many companies but often demands specialist knowledge few staff hold.
The practical consequence: when problems emerge in complex clusters, businesses can find themselves dependent on a small number of engineers. New Relic is betting an AI agent embedded in existing workflows can widen that bottleneck.
What does the agent actually do?
New Relic describes the agent as a specialised extension of its broader Autopilot system, which investigates incidents and supports response workflows. While the wider platform handles full-stack observability queries, this version focuses specifically on containerised systems.
The tool runs its 90-plus diagnostic detectors across four categories of data:
- Kubernetes events
- Object descriptions
- Logs
- Application performance monitoring traces
It's built to help teams investigate a specific set of failure modes: compute resource problems, scheduling failures, network errors, and cloud configuration faults such as Application Load Balancer and ingress settings.
Under the hood, the agent uses what New Relic calls its Ground Truth context engine, built on OpenTelemetry. That engine analyses correlated operational data, identifies a likely cause, and generates suggested fix code. Engineers then review and execute that code inside their existing workflows — the agent proposes, humans dispose.
The takeaway: it's diagnosis plus draft remediation, not autonomous repair.
Why is Kubernetes operations hard to staff?
New Relic frames the launch around an expertise gap it says now exists in many businesses. Traditional infrastructure operations centred on fixed machines — a model most ops teams understand. Kubernetes shifts that towards a distributed, self-healing environment that can still be brutal to troubleshoot when failures cascade across services.
The result shows up in incident response times. Teams move between dashboards, logs and tracing tools to piece together the cause of an outage, and each hop adds delay.
General-purpose large language models haven't solved this, and New Relic names the reason: those systems often lack direct access to operational context from live environments. An LLM that can't see your cluster's actual events and traces can only guess at causes. The Ground Truth engine is New Relic's answer — feed the model the correlated telemetry first, then ask it to reason.
Scale compounds the problem. New Relic cited Cloud Native Computing Foundation research showing that 66% of organisations running generative AI rely on Kubernetes, adding to the operational complexity of large, growing multi-cluster environments.
In plain terms: the estates keep getting bigger, and the specialists aren't multiplying at the same rate.
What did New Relic say?
Brian Emerson, Chief Product Officer at New Relic, described the tool as a response to the operational pressures created by complex container infrastructure.
"When critical Kubernetes infrastructure fails, engineers need clear answers, not just more alerts," Emerson said.
He expanded on the design philosophy in a second statement:
"The New Relic Autopilot Kubernetes Agent embeds specialised, agentic AI directly into the engineer's containerised workflows to eliminate the guesswork from complex cluster incidents while keeping the engineer safely in control. Because it works natively across any telemetry source, it provides a level of full-stack observability that specialised or closed-system tools cannot match."
Both quotes carry the same message: the agent works where engineers already work, and it doesn't take the decisions away from them.
How does it fit into engineering workflows?
The product is aimed at teams that already manage operational incidents through established engineering processes rather than standalone AI interfaces. It's designed to fit standard Site Reliability Engineering and platform engineering workflows, with options for human oversight during investigations.
That design choice matters more than it might sound. In Kubernetes environments, a single configuration change can have wide effects across services — which is exactly why review and approval remain central to incident handling there, even as vendors add AI.
The pattern is broader than New Relic. Across observability and operations software, suppliers are introducing AI-based investigation tools while still framing them as decision-support systems rather than autonomous operators. Nobody in this market is selling an agent that pushes changes to production clusters on its own.
So the agent slots into the review step, not around it.
What's the competitive logic?
For New Relic, the launch also expands its push to tie AI features more closely to observability data. The strategic move is focus: rather than offering general troubleshooting, the company is building an agent for one specific operational domain.
That narrowness is deliberate. Outages often affect systems that only a small number of specialists fully understand, and a domain-specific agent with direct access to cluster telemetry can go where a general chatbot cannot. Emerson's claim that the tool "works natively across any telemetry source" positions it against what he calls "specialised or closed-system tools" — a direct shot at rivals whose agents only see their own data.
The stakes are commercial as well as technical. Observability is a crowded market, and every major vendor is now racing to layer AI investigation capabilities onto the telemetry pipelines they already own.
What happens next?
The agent is available now in public preview, meaning engineering teams can try it against live cluster incidents today — with the human-review guardrails New Relic has made central to the pitch. Whether the 90-plus detectors and the Ground Truth engine actually shorten incident response times in production will be the test that decides if this becomes a standard part of the SRE toolkit or another alert-adjacent tool engineers learn to ignore.
Source: itbrief.com.au
More from Sophie Lindqvist
Show full bio
Staff writer covering regulation, policy and their impact on artificial intelligence and machine learning at AI In Context.
537 articles
Related articles
- Red Hat Ships OpenShift 5 With Agentic Ops, Five-Year Support
- Red Hat ships OpenShift 5 with AI agents, five-year lifecycle
- CloudOpsBench exposes reasoning gaps in cloud operations agents
- OpenAI Ships AgentKit, Expanded Evals, and Reinforcement Fine-Tuning for Agents
- OpenAI to Acquire Promptfoo and Build Red-Teaming Into Frontier