The observability landscape is undergoing a fundamental transformation, and platform teams are at the center of it. As telemetry data volumes explode - driven by AI, microservices, and distributed systems - the traditional developer-owned observability model is breaking down. Platform teams are now taking ownership of instrumentation as core infrastructure, and the implications for how you design, measure, and scale your platform are significant.

Main insights

• Platform teams are shifting observability responsibilities "down" into the platform layer rather than "left" to developers, embedding instrumentation, telemetry pipelines, and data standards as core infrastructure capabilities
• Telemetry data is growing 30-40% year-over-year, with AI-driven workloads accelerating this trend and creating unsustainable cost pressures under traditional usage-based pricing models
• OpenTelemetry is emerging as the foundation for AI-readiness, offering standardized schemas, reduced vendor lock-in, and better compatibility with AI-driven analysis and automation
• A new capability class is emerging: observing AI agents themselves, requiring platform teams to monitor token usage, permissions, data access, and compliance across enterprise agentic workflows

Luca Galante, managing director at Weave Intelligence and a leading voice in the platform engineering community, joined Dilek Altin, senior analyst at Weave Intelligence, to present findings from their new market guide on observability. Together, they benchmarked how hundreds of enterprise organizations approach observability and identified the forces reshaping the market.

You can watch the full discussion here if you missed it.

Why observability is the first market guide

Weave Intelligence launched with the recognition that platform engineering has reached an inflection point. The discipline now extends far beyond traditional DevOps and developer experience, rapidly incorporating observability, FinOps, security, data, and AI. As Luca explained, "We wanted to have this research arm that can span across all these different verticals as they are intersecting now with platform engineering and as platform teams have increasingly more responsibilities across all of these different domains."

Observability emerged as the natural starting point because of three converging pressures:

Scale has destroyed the traditional collection model. Many enterprise teams now handle trillions of traces and telemetry events. As Luca noted, "At this point we reached a scale that sort of destroyed the traditional collection model that observability is kind of based on." AI is accelerating this problem. Every LLM activity generates roughly three to five times the observability data of a traditional application event.

Vendor pricing models are misaligned with user needs. Most incumbent observability vendors charge based on data volume, creating a three-way tension between finance teams demanding cost control, application teams needing full-fidelity data, and SRE teams requiring real-time signals. As Dilek explained, "You can fulfill one of them but every time I fulfill one of them the other two will be unhappy."

AI agents are breaking the interface. Traditional observability tooling was built around dashboards designed for human operators investigating issues serially. AI agents operate differently - parallelizing investigations and hitting endpoints at 10x to 100x the query load. Luca described it plainly: "Imagine you have like a one lane highway and now you're trying to cram like a hundred cars just driving like next to each other. There's going to be a lot of crashes happening."

Shifting down: The new paradigm for platform teams

One of the most important concepts in the market guide is shifting down - a deliberate contrast to the familiar "shift left" approach. While shift left pushes responsibilities to developers, shifting down embeds functionality directly into the platform layer itself.

Dilek defined it clearly: "You want to enable or embed functionality in the platform rather than actually shifting it to the developers or the teams." In practice, this means that when a developer deploys a Kubernetes cluster, database, or any other resource, all telemetry instrumentation, data pipelines, and endpoints are automatically wired and available - no manual setup required.

The research shows this is a pressing need, not just a philosophical preference:

• Approximately 50% of survey respondents identified shifting down as a key priority
• Around 60% reported that their observability data is either too noisy or fails to help them find root causes quickly enough

This creates what Dilek called a "vicious circle." When teams don't get the data they need from centralized systems, they build their own pipelines and adopt their own tools. That fragmentation degrades shared data quality further, prompting more teams to opt out, until the entire system becomes unsustainable.

The solution is to treat observability as a golden path. As Luca emphasized, "Looking at these things as paths and then potentially golden paths" allows platform teams to turn instrumentation, semantic conventions, and tooling into capabilities that are embedded by design across different teams, workflows, and applications. Consistency becomes the default, not the exception.

The cost crisis and the OpenTelemetry response

Cost is the most talked-about challenge in observability today. Telemetry data is growing 30-40% year-over-year - and that's before AI workloads become mainstream. Dilek put it bluntly: "If you think we're already in a very difficult situation today, wait next year or the year after when actually the data tsunami is going to hit us hard. Next year it's going to be 80%, the year after probably 100%."

This growth is colliding with volume-based vendor pricing. Teams have tried workarounds - tiering data, tuning retention periods, renegotiating contracts, switching off signals - but these are temporary fixes, not structural solutions.

OpenTelemetry is emerging as a structural response to this crisis. The market guide shows that roughly 35-40% of teams are already fully on OpenTelemetry, with about half actively evaluating it. The reasons are clear:

• Cost reduction through early filtering. OpenTelemetry supports edge sampling and tail sampling, which reduce data volume at the source before it reaches expensive storage and processing systems.
• Standardized schemas for AI compatibility. OpenTelemetry data schemas are publicly available and well-documented, meaning AI models are already trained on them. As Dilek explained, proprietary schemas increase the likelihood of false positives and require significant additional model training.
• Reduced vendor lock-in. Standardization makes it easier to switch between observability solutions without rebuilding instrumentation from scratch. "Once all the data schemas are pretty much standardized, you can switch easier from solution A to solution B," Dilek noted.
• Foundation for agentic workflows. As AI agents increasingly monitor and respond to system behavior, a shared, standardized telemetry language becomes essential. Without it, you're building automation on top of inconsistent, proprietary data formats.

The new frontier: Observing AI agents

Perhaps the most forward-looking insight from the market guide is the emergence of a new capability class: observing AI systems and agents themselves. This goes well beyond traditional application and infrastructure monitoring.

As enterprises deploy agents across sales, marketing, finance, and software development, they need centralized governance and visibility. Dilek outlined the requirements: "You probably want to put in the same requirements in terms of safety, observability, the access of data that they have, manage basically also what rights the agents have. You want to do this centrally."

This is becoming part of the platform engineer's job spec. Teams must monitor:

• Token consumption and associated cost
• Data access patterns and potential leakage
• Agent permissions and external call behavior
• Regulatory compliance and "know your agent" requirements

This is not purely a technical challenge - it's a governance, safety, and compliance challenge. As Dilek put it, "This is basically a major body of new functionality and we are seeing already first players in the field that actually are covering this." Some vendors are extending existing data pipelines to include agent observability; others are treating it as an entirely new problem space.

What platform engineers can do now

The market guide is designed to be a practical resource. Depending on where you are in your platform journey, your next steps will differ:

If you're building a platform from scratch: Start by talking to your users. Understand what telemetry data they need, in what format, and how they want to access it. Design golden paths that embed instrumentation, semantic conventions, and tooling by default. As Dilek advised, "Think about the path that you need to put in place in order for them actually to be able to access the data that they need to access."

If you already have observability embedded: Evaluate your OpenTelemetry migration strategy. Assess your current data schemas, signals, and pipelines, then design a conversion plan that lets you adopt OpenTelemetry incrementally without disrupting existing workflows.

If you're preparing for AI: Ensure your infrastructure wiring is in place first. As Dilek emphasized, "If you don't have your fundamental platform in place, then it's going to be very difficult for you to actually start working on agentic software development or even agentic analysis." Once the foundation is solid, you can focus on capturing, formatting, and analyzing telemetry data automatically to create actionable outcomes - whether that's bug fixes, configuration changes, or resource scaling.

Luca summed up the broader lesson well: "So many of the topics that we've been talking about here in the community for the last five, six years - things like standardization by design, templates, blueprints - with AI are ever more needed and are ever truer."

​

If you enjoyed this, find more great insights and events from our Platform Engineering Community.

​

Key takeaways

• Shift observability down into the platform. Embed instrumentation, telemetry pipelines, and data standards as core platform capabilities rather than pushing them to developers. This reduces cognitive load, ensures consistency, and prevents the vicious circle of fragmented tooling and degraded data quality.
• Prioritize OpenTelemetry for cost control and AI readiness. Standardized schemas reduce vendor lock-in, enable early data filtering to control costs, and provide the foundation for AI-driven analysis and automation. With telemetry data growing 30-40% year-over-year - and accelerating - this is not optional.
• Prepare for agent observability as a new capability class. As AI agents proliferate across enterprise functions, platform teams must monitor token usage, permissions, data access, and compliance. Treat this as a governance and safety challenge, not just a technical one.
• Focus on signal quality over data volume. More data does not equal better insights. Around 60% of teams report their observability data is too noisy or fails to support root-cause analysis. Design your platform to collect the right signals, not just more signals.