Your browser doesn’t support HTML5 audio
Observability used to be the part of the technology stack that nobody wanted to pay for – tooling that sat quietly in the background until something broke, at which point an engineer would dig through logs and get everything back to zero.
That picture is no longer accurate. At a Cloud Native Computing Foundation (CNCF) roundtable at KubeCon Europe 2026 in Amsterdam, a panel of practitioners, open source maintainers, and vendor technologists made a compelling case that observability has evolved from a reactive troubleshooting function into a forward-looking business capability – and that the language the industry uses to describe it has not kept pace.
Keith Babo, Chief Product Officer at Solo.io – with over 25 years across Sun Microsystems, Red Hat, and Solo.io – captured the scale of the change:
Observability plays a key role in probabilistic and non-deterministic workflows – explaining what's going on that we used to do with static code analysis and very deterministic pathways. Observability will now unlock and allow us to audit and explain and debug.
From troubleshooting to business driver
The most striking theme was the broadening of what observability is actually for. Bianca Lewis, Executive Director at Open Search Software Foundation, described it in commercial terms that would have been unthinkable five years ago:
In those days, the biggest problem building a business and selling to enterprise customers was, 'I really don't want to pay for this.' It was one of those necessary evils the business has to have. The most fundamental shift is it's not an evil that I have to have – it's a business driver. It's a predictor of where the business is going.
Lewis went further, making the case that observability platforms will increasingly be used to create Service Level Objectives (SLOs), inform product development, and attach cost data to traces:
The language of observability has completely changed, where you cannot look anymore at an observability platform as a platform for troubleshooting. It's a platform that's going to inform business growth. It's going to democratize data.
The CNCF 2025 Annual Report identifies observability alongside Artificial Intelligence (AI) and platform engineering as the three defining themes shaping cloud native adoption. With over 230 projects and 300,000 contributors across the CNCF ecosystem, these are no longer niche tooling decisions – they carry enterprise-wide consequences.
The AI agent data problem
The roundtable's liveliest exchange was about what happens when AI agents enter the observability picture. This concern was raised during the Q&A:
Are organizations ready for how much more data they're going to be collecting in their logs once they start tracking agent behavior? Your storage bill, if you keep all of the logs and all of your agents, is going to dwarf your development budget.
Jan Fajerski, Principal Software Engineer at Red Hat and a Prometheus maintainer, responded dryly:
I'm not sure 'going to' is the right temporal form. We're already there.
The panel broadly agreed that organizations will over-collect in the short-term, but several panelists saw AI itself as the mechanism for making sense of the data flood. Jakub Suchy, Director of Solutions at HAProxy Technologies, put it well:
One of the problems of having too much observability data historically has been that the human just can't read it, but AI can and can find the little nuggets that are actually useful.
An audience question pushed the discussion further: does observability itself need to become probabilistic, given that AI agents may never take the same path twice? Suchy suggested the phrase "deterministically non-deterministic" – the algorithms are technically deterministic, but the probability they introduce creates functionally unpredictable behavior. Fajerski noted:
Ultimately, you're interested in the physical manifestations of software in the real world. It doesn't matter if the system has non-determinism or not, you still want to observe what that number does.
The linguistics question
The conversation took an unexpected turn when the discussion moved to language itself – what the community gets wrong about how observability is described, what it really means to practitioners, and how that affects the humans doing the work.
Fajerski quoted a Prometheus community member who objects to the phrase "doing observability," insisting instead that observability is a property of a system – a system is either observable or not, and what practitioners do with that property is a separate question entirely:
Nobody can tell you otherwise. What do we mean by doing observability? We're not really doing anything.
Babo picked up the thread from an AI angle, pointing out that the semantic precision of observability language becomes even more critical when Large Language Models (LLMs) are interpreting signals and taking action:
If I was going to ask you, 'Is the application healthy?' — there's a really deep semantic implication to what 'healthy' means in that context. Maybe even more important now, when we're talking about LLMs interpreting signals and drawing correlations and maybe taking actions, that semantic and that linguistic element is even more important.
That observation landed with real weight in the room. If we cannot agree on what "healthy" means when humans are reading the dashboard, the consequences of that ambiguity become significantly more serious when an AI agent is the one deciding what to do about it.
Data sovereignty pushes back against SaaS
The final major theme was data sovereignty. Suchy contended that the decade-long trend of pushing telemetry data to Software-as-a-Service (SaaS) observability vendors is reversing:
Owning your own data is back. We spent the last 10 years pushing everything to SaaS solutions, which created some of these problems with data privacy. Customers I see are very much on the train of, 'No, I'm going to own this data.'
The panel connected this to the Cyber Resilience Act (CRA), due for implementation in September, and the Digital Operational Resilience Act (DORA), already in force across the European Union (EU) but where many member states remain behind on implementation. Open source, several panelists noted, provides the natural infrastructure for organizations wanting to retain sovereignty over their observability data.
A closing question from the audience wondered whether agentic AI will replace dashboards with natural language queries tailored to personas. For example, a business leader might ask, "How much money am I losing because my service is down?" An engineer could ask, "What's the root cause?" Same data, different questions, dynamically generated interfaces.
Fajerski offered a measured response:
The dashboards will stick around. I'm only half joking, but a lot of people like to look at colorful pictures that move.
My take
This roundtable discussion felt like a real turning point. When Lewis described observability as "a platform that's going to inform business growth" and Fajerski insisted it is "a property of a system, not something you do," they were not disagreeing. They were describing two halves of the same transition: from a technical function to a business capability, from cost center to value driver.
The AI agent question is the accelerant. If organizations already struggle with the volume and complexity of observability data from deterministic systems, the introduction of agents that may never take the same path twice forces a rethink of what to collect, store, and act on. The data sovereignty dimension makes it harder still, as European regulation pushes organizations to keep that growing mountain of telemetry within their own walls.
Observability is no longer a conversation to leave to your platform engineering team. It is becoming the nervous system of the business itself – and the organizations that get the language right, that ask better questions of their data and connect technical signals to commercial outcomes, will be the ones that extract the most value from what comes next.