I’ve spent the last few weeks watching observability vendors make increasingly ambitious claims about watching AI agents. We've got better traces, more evaluations, and plenty of promises about automated investigations. I'm still wondering who gets the call when something goes wrong between the systems.
Elastic has taken a decent shot at answering that. At ElasticON New York on October 8, it introduced nightshift AI SRE, an always-on investigator that can catch problems conventional alerts miss, test possible causes, and recommend fixes with human approval. It's in private preview on Elastic Observability Serverless, with broader third-party access still to come.
Elastic's Observability General Manager, Baha Azarmi, says nightshift learns from engineers' investigations and reviews its findings after incidents close:
“That is how it keeps up with production without running up a token bill nobody wants to see.”
I'd certainly welcome a smaller bill. But I'd be more impressed if an investigation could follow a failed customer call through the carrier, CCaaS platform, and CRM, then work out which team needs to fix it. That's where a lot of the real frustration sits.
New Relic and Honeycomb have made their own moves in recent weeks, and Grafana's ObservabilityCON 2026 is next on October 19–21. I've got five questions for Grafana, and quite a few of them have less to do with AI than the people who'll be left dealing with the incident.
TL;DR
-
Elastic's nightshift AI SRE looks promising, with some important limits. Its October 8 launch brings investigation and proposed remediation closer together, although broader third-party integrations remain ahead.
-
Grafana has some convincing demonstrations lined up for ObservabilityCON. LexisNexis Risk Solutions plans to show how Grafana IRM connects investigations, ServiceNow tickets, and on-call paging. The question is how well that works when the incident crosses platform boundaries.
-
Someone needs to explain the costs and the backup plan. Grafana's metered AI evaluations, the migration from OnCall OSS to Cloud IRM, and its recent SMS notification problems raise questions about what service teams will pay and how reliably they'll be reached.
What Did Elastic Announce at ElasticON New York?
Elastic’s October 8 launch gave us something concrete to shine a spotlight on. Nightshift AI SRE brings a Context Engine, Detection Engine, Investigation Engine, and Remediation Engine to incident work. Elastic says its own SREs already use it in production, although the product remains in private preview.
According to Elastic’s technical account, investigations can start from an alert, test competing explanations, and flag missing evidence. The Remediation Engine can then suggest a workflow or connector action, subject to human approval. I'd welcome that over another automatically generated incident summary.
But broader third-party observability and data integrations are still planned, and contact centers rarely have the luxury of dealing with one supplier.
IDC Senior Research Director Shannon Kalvar put his finger on the problem in Elastic's launch announcement:
“These agents need access to a broader context, particularly heterogeneous estates.”
If a customer call breaks between a carrier, CCaaS platform and CRM, can nightshift follow the evidence, identify the right incident owner and confirm the service has recovered? Or does an engineer still have to chase three suppliers?
ElasticON New York promised “real-time AI agents to accelerate incident and threat response,” alongside ES|QL and AI-integration previews. Two days earlier, Elastic was asking, “Who approved an agent’s last action?” in its AI control gap session.
Back in London in February, the emphasis was on giving agents better context. By October, the conversation had shifted toward approval and control.
That's progress, but I'd like to see where Elastic's investigation ends and another team's work begins. A proposed fix is helpful. Knowing the customer can actually get through again would be better.
Why Is AI Agent Observability Becoming a CX Reliability Issue Now?
AI agent observability is turning into a CX reliability issue because agents can complete a workflow cleanly and still leave the customer with a bad result. That failure won’t always trigger the kind of signal an operations team is trained to chase.
Honeycomb's September 29 research found that 71% of respondents were deploying AI agents faster than they could manage or govern them. Meanwhile, Enterprise Management Associates research reported on October 8 found that enterprises typically use six to eight observability tools.
Of the 356 IT professionals surveyed, 41% said switching between tools slowed investigations, while 44% blamed integration and API complexity. That's an awful lot of detective work before anyone can start fixing things.
There's a cost to that delay. Axis Intelligence's six-incident analysis found that, on average, 27% of customer-impact time elapsed before the cause was identified. It's a limited sample, but the finding deserves attention.
And demand is growing. Gartner's October 1 AI Hype Cycle reports that only 17% of organizations currently have agents deployed, while more than 60% expect to within two years.
Service teams could soon be investigating far more incidents where the system reports success and the customer has a rather different story. I'd want both versions in the incident record.
How Do Enterprises Monitor AI Agents in Production?
I wouldn't fancy investigating an AI agent failure with six different telemetry formats and half the conversation missing. Yet that's a reasonable prospect for engineers trying to piece together model requests, tool calls, and handoffs across different platforms.
GitHub made one pragmatic move on September 22, adding enterprise-managed OpenTelemetry export for Copilot sessions, model requests, and tool execution. Prompts and responses are excluded by default. Fair enough for privacy, but investigators still need a way to establish what an agent actually told someone without collecting more personal information than they should.
New Relic's October 6 announcement tackles the format problem. Its “Normalize on Read” approach brings open-source agent traces and native application monitoring data together. AWS's CloudWatch Omni is also generally available, covering evaluations across different models and runtimes.
For contact centers, I'm particularly interested in Operata's September Genesys Cloud AVA integration. It puts AI exchanges, telephony events and human-agent handoffs on one timeline. That's a record an engineer might actually enjoy opening when someone's disputing what happened during a transfer.
New Relic has more coming, too. Its AI Evaluation, due for public preview in November, links quality scores with traces, while its Ground Truth CLI aims to preserve investigation and recovery evidence.
Its Service Architecture Intelligence and Infrastructure 360 announcement interests me more. It promises visibility into service ownership, infrastructure dependencies, and changes, including gateways and load balancers. Infrastructure 360's public preview is scheduled for October 13.
I'd want to see that working during an actual incident, especially when the engineer who finds the fault isn't the person authorized to fix it.
What Should ObservabilityCON 2026 Deliver for Service Teams?
Grafana has set itself a fairly ambitious agenda for ObservabilityCON 2026 on October 19–21. Under the banner “AI for Observability. Observability for AI,” it's promising agent evaluations, OpenTelemetry pipelines, and closer links between investigations and incident management.
I'm particularly interested in the customer demonstrations. DriveWealth says its support team now self-serves 25% of questions through Grafana Assistant, while its SRE team uses Assistant and IRM to investigate alerts before paging an engineer.
LexisNexis Risk Solutions has an even more interesting workflow on the agenda. An alert creates an incident, opens a ServiceNow ticket, triggers an investigation, and pages the on-call team. Grafana's Knowledge Graph is supposed to help connect that activity with service ownership.
I'd like to see how much of that actually works without someone filling in the gaps manually. Deutsche Telekom IT GmbH is also lined up to discuss World Cup-scale reliability, which should give us another useful operational perspective.
