TL;DR — Key Takeaways
- Telemetry coverage does not equal useful observability; teams need signals that help developers explain failures, trace dependencies and identify the changes behind regressions.
- Golden paths should make OpenTelemetry and consistent service metadata automatic, while platform teams define a shared observability model that connects signals to decisions.
- AI workloads expand observability requirements beyond infrastructure health to areas such as token consumption, inference latency, hallucinations, guardrail failures and the cost of repeated agent actions.
Telemetry can be present in every service and still leave platform teams blind when production behavior turns unfamiliar. Instrumentation proves that systems emit data; useful observability depends on whether engineers can connect those signals quickly enough to explain what happened and decide what to do next.
The distinction is becoming more important as internal developer platforms support a larger mix of infrastructure, applications and AI components. Coding agents can increase the volume of software entering production, while AI applications introduce model behavior, token consumption and guardrail failures that conventional infrastructure dashboards were not designed to capture.
Golden paths give platform teams a way to make telemetry part of every deployment. However, standardized collection solves only the first part of the problem; teams must still determine which signals matter, how they relate and whether developers can use them without depending on a small group of observability specialists.
Coverage Alone Doesn’t Create Observability
Coverage metrics reward the presence of telemetry, even when the resulting data cannot answer an engineer’s questions. A service may emit logs, metrics and traces while remaining difficult to understand because the signals are incomplete, poorly structured or disconnected from the rest of the system.
Liz Fong-Jones, technical fellow at Honeycomb.io, says the percentage of instrumented services reveals little about whether a platform’s observability program works.
“Coverage is meaningless unless developers can actually analyze the data and use it to get insights,” Fong-Jones says. “You can have telemetry everywhere and still not have useful observability. Otherwise, increasing coverage just increases cost. It’s empty calories.”
Platform teams need to evaluate whether telemetry supports concrete tasks, including diagnosing an unfamiliar failure, tracing a request across dependencies and determining which change caused a regression.
The quality of those answers matters more than the raw number of services sending data.
Telemetry Costs Force Platform Teams to Choose
Shallow coverage often reflects a practical compromise. Telemetry volumes can grow much faster than observability budgets, leaving teams to reduce fidelity, shorten retention periods or concentrate detailed monitoring on their most important services.
Shannon Kalvar, research director for enterprise systems management, enterprise client platforms, observability and AIOps at IDC, says older pricing and storage models forced operations teams to control how much data they collected.
“So, if you have 10 times the data from adding in an agent or three, you pay 10 times what you originally paid,” he says. “Worse, the tools that allow you to respond to that, to pick and organize data, require people.”
AI-assisted development intensifies the imbalance. One operations specialist may support developers working with coding agents, the applications those teams produce and a growing web of machine-to-machine interactions.
While automatic threshold setting and analysis could help, Kalvar cautions those agentic approaches remain largely untested.
Golden Paths Need a Shared Observability Model
Platform teams can embed OpenTelemetry, or OTel, into approved images, service templates and deployment pipelines. They can also collect the four golden signals — latency, traffic, errors and saturation — without requiring each development team to assemble its own instrumentation.
The harder work begins when the organization decides what those signals mean. Kalvar says platform teams need agreement about who uses a signal, which decision it supports and when a machine may act on it.
“The real challenge is ontology and its associated orientation,” he says. “What matters to your organization? How do different departments read the same signal, and why? What decisions are humans accountable for, which can be handed off to machines, and what signal drives them?”
A common telemetry schema should therefore include consistent service names, ownership data, deployment versions and business context. Golden paths can enforce those conventions at creation time, sparing developers from reconstructing them after an incident.
AI Workloads Expand the Signal Set
Infrastructure health remains necessary for AI services, but it cannot show whether a model is accurate, drifting from expected behavior or spending more to produce the same result. Platform teams may also need to monitor hallucinations, token use, inference latency and attempts to cross policy boundaries.
Repeated agent actions create another issue. Kalvar calls it the “durability of action”: determining whether a task performed repeatedly by agents should be rewritten, optimized and managed as conventional code.
“The one that people miss is ‘durability of action’,” he says.
Once a task stabilizes, converting it into ordinary code can reduce token costs and give teams a more reliable way to test and optimize it.
Linking these signals requires more than placing another dashboard beside the infrastructure view. Model behavior, application performance, underlying resources and cost must share enough context for teams to trace a symptom through the full stack.
Measure Whether Engineers Can Debug
Platform leaders evaluating observability tools should test them against real services and incidents rather than vendor demonstrations.
Kalvar says recommends selecting two trusted vendors and comparing how their knowledge or context graphs perform in the organization’s environment over 90 days.
The same test should extend to developers. Platform teams can measure whether engineers resolve incidents without specialist intervention, how quickly new hires become comfortable in production and whether teams can explain unfamiliar system behavior with the telemetry supplied by the golden path.
“If you must have a coverage metric, make it the percentage of teams whose most junior member feels confident debugging in production,” Fong-Jones says.