A familiar pattern is emerging in observability conversations.
As telemetry volumes grow and costs rise, the default recommendation is often to collect less data: Sample more, retain less, index selectively, filter earlier, and reduce cardinality until the economics become manageable.
Some of this is reasonable. No system benefits from unlimited accumulation without curation. But when “send less data” becomes the center of the strategy, it creates a deeper problem: Teams are asked to reduce fidelity before they understand what level of fidelity they actually need.
There’s a Hidden Cost of Reducing Fidelity Too Early
This is the gaslight problem.
The organization is told the issue is its telemetry behavior. Too many logs. Too many spans. Too much cardinality. Too much retention. But often, the underlying issue is that the economic model makes necessary fidelity feel excessive before the team has enough evidence to know what is safe to reduce.
Observability is most valuable under uncertainty. A signal that looks noisy during normal operation may become important during an incident. A trace that seems redundant today may explain a rare dependency failure tomorrow. A log line that looks disposable in one context may become the only evidence of a regression in another.
That is why treating telemetry as simply useful or useless is misleading. Its value changes with the system, the release, the failure mode, and the question being asked. The work of deciding what to keep is not free either. It requires engineering time, operational context, and constant maintenance as systems evolve.
This challenge is becoming sharper as AI-assisted and agentic development changes how software is built.
AI Agents Widen the Gap Between Intent and Runtime Behavior
Historically, engineers had a relatively direct relationship with implementation details. They wrote the code, understood the intended behavior, and had some intuition about which signals would matter in production. That intuition was imperfect, but it existed.
With agents increasingly acting as a proxy between the engineer and the implementation, that relationship becomes more indirect. Agents generate code, modify flows, introduce dependencies, and reshape behavior in ways an engineer may approve without fully internalizing every detail.
This does not remove human responsibility, but it does thin the mental model. The runtime behavior of the system may drift further away from the engineer’s intuition.
That has major implications for observability. The issue is not only that new flows may generate unpredictable telemetry volume. It’s that teams may not know in advance which signals are necessary to understand an implementation they did not fully handcraft or deeply internalize.
In that environment, aggressive early reduction becomes risky. It asks teams to decide what will matter precisely when their understanding may be weakest.
This is not an argument against optimization. Sampling, filtering, retention policies, and cardinality management all have a place. At scale, they are unavoidable. But they should be deliberate architectural choices, not the primary mechanism for making observability affordable.
There is an important difference between optimizing after understanding and optimizing before understanding.
The first is an engineering discipline. The second is guesswork.
This is where economics and architecture intersect. If observability cost scales directly with ingestion, retention, indexing, seats, and add-on capabilities, teams will inevitably feel pressure to observe less. That pressure may be rational from a budget perspective, but it can conflict with the operational need for fidelity.
Cost Management Shouldn’t Mean Less Visibility
For enterprises, the question is not whether cost should be managed. It should. The question is what kind of trade-off cost management imposes.
A mature observability strategy should help teams surface the most relevant signals without making every additional signal feel like a financial mistake. It should reduce noise without reducing the organization’s ability to understand system behavior. It should make broad visibility sustainable, not exceptional.
The industry should be careful with the “send less data” reflex. It may solve an immediate budget problem, but it can also normalize lower fidelity as the default answer to complexity.
In modern systems, especially those increasingly shaped by agents, runtime behavior is becoming a more important source of truth. Observability should help teams close the gap between intent and implementation, not widen it in the name of cost control.
