The User, the Power User, and the AI Agent

Observability is needed at the worst possible time.

A service is failing. A deployment is behaving differently than expected. A customer is blocked. You are not opening the observability product because you have spare time and want to explore telemetry. You are trying to understand a live system quickly enough to act: What is broken? When did it start? Who is affected? What changed? How do we fix it?

That is what makes observability such a difficult product category. For many users, it is the interface they reach for in the heat of an incident. For others, it is a daily workspace where they spend hours building a deep understanding of how their systems behave. And now, as AI agents become part of the investigation loop, observability is also becoming a source of machine-consumable context that must be shaped differently from anything a human would read.

These are three distinct consumers of the same telemetry: the user, the power user, and the AI agent, and each needs a different interface on the same data.

For years, observability products tried to serve different human needs through one expanding surface: dashboards, alerts, logs, traces, service maps, query languages, notebooks, and APIs layered on top of the same telemetry. That compromise was already strained. Now AI agents break it. Not because they replace humans, but because they expose a deeper truth: different consumers need different abstractions.

The future of observability will not be defined by one smarter dashboard or one faster API. It will be defined by how well the product serves the user, the power user, and the AI agent.

Complexity Came From Real Work

It is easy to say observability products are too complicated.

It is harder, and more useful, to understand why they became that way.

Applications became more distributed. Infrastructure became more dynamic. Teams started operating across containers, Kubernetes, serverless platforms, managed databases, queues, feature flags, third-party APIs, and now LLM calls. Each new surface solved a real problem and each introduced a new source of telemetry that helped teams answer questions they could not answer before.

The thing is, people who spend the most time in these tools are usually power users: SREs, platform engineers, and developers who enjoy going deep. Their needs are entirely legitimate. They may need to run time and space aggregations on metrics, transaction queries on logs, or multi-step workflows that progressively filter, extract, group, and correlate telemetry across large time windows. This is the reality of investigating complex systems while production is still moving.

So the problem is not that observability products have depth. They need depth. The mistake was not adding capability. The mistake was exposing all of that capability to everyone, all at once.

A log explorer that must be simple enough for a developer searching for one error, and powerful enough for an expert building a multi-step query, often ends up being neither.

The result is a product that is technically capable but cognitively expensive. And cognitive cost matters most precisely when users are under the most pressure, like during an incident.

The Impossible Default

This is where observability becomes a hard product problem. The user and the power user are not simply two skill levels on the same path. They often want opposite things from the same interface.

The user wants the product to make the first move.

Surface likely causes. Highlight recent changes. Show abnormal behavior. Identify affected services. Pull forward representative errors. Start from the problem, not from the data model.

The power user wants control.

Choose the dimension. Change the time window. Extract the field. Join the signals. Compare versions. Group by region, tenant, endpoint, dependency, release, or customer tier.

The user benefits from defaults.

The power user is often constrained by them.

The user wants fewer decisions before the investigation starts.

The power user wants more degrees of freedom once the obvious answers are exhausted.

The user wants the interface to reduce cognitive load.

The power user wants the interface to preserve analytical range.

And neither side is wrong.

A developer trying to understand why an endpoint started failing after a release should not need to remember a query language before making progress. But an SRE investigating a region-specific latency regression across versions, tenants, dependencies, and deploy windows cannot be limited to a guided checklist.

This was the old observability compromise: make the product simple enough for the occasional investigator, but powerful enough for the expert operator. Most products solved the tension by layering complexity: Start with dashboards. Add drilldowns. Add log search. Add traces. Add custom queries. Add notebooks. Add service maps. Add anomaly detection. Add correlation views. Add another sidebar, another mode, another page.

For a while, this worked. Then the default surface gets crowded. The guided path becomes less guided. The expert path becomes harder to find. The product remains technically capable, but becomes harder to reason about.

This is the central design tension: observability has to preserve complexity without forcing everyone to start inside it.

Same Failure, Different Needs

Imagine a checkout service starts returning 500 errors after a deployment.

If you are looking for orientation, you need a fast answer:

Errors increased after deployment 2026-05-29-4 The failures are concentrated in /checkout/confirm and tied to a specific payment provider.

That is enough to get moving. If you are investigating deeply, you need more:

Break failures down by region, version, dependency, and customer tier. Compare against yesterday. Extract the upstream error code from the logs. Check whether retries are masking part of the failure. Correlate traces with deployment events.

Same system and telemetry but different mode of work. When one needs a guided investigation, the other needs an analytical workspace. Both are valid and necessary, but they should not be forced into the same default surface.

Then the agent arrives.

The Agent Does Not Want the Dashboard

An AI agent does not need a dashboard.

It does not care about layout, visual hierarchy, hover states, table density, or whether a service map looks good on a large monitor. But that also does not mean any API is the right interface. A common mistake is to assume that if a human can search logs, an agent can search logs too.

Technically true. Practically wrong.

If an agent investigating an incident pulls millions of log lines into context, the observability platform has failed to do its job. It has pushed telemetry analysis into the model instead of doing that work itself. Agents do not need more context. They need the right operational context:

What patterns are new?

What changed?

Which services, versions, tenants, or regions are affected?

Which examples best represent the failure?

What recent changes correlate with the problem?

Most of those answers already exist inside the observability platform. Historically, users found them through dashboards, charts, filters, and visual inspection. With agents, the platform has to expose those answers more directly.

With agents, the platform should do the telemetry work first: filter, aggregate, correlate, rank, summarize, then hand the results to the model.

A language model is good at reasoning over well-shaped context. It can compare hypotheses, explain likely causes, summarize evidence, and decide what to inspect next. It is not the right place to perform large-scale telemetry analysis from scratch.

An agent-facing interface is not a dashboard without pixels, and it is not a raw endpoint with a prompt in front of it. It is a different abstraction layer entirely.

Putting Complexity in the Right Place

Simple things should be simple to do. Advanced things should be possible. Agent workflows should be designed for agents. The challenge is making those three ideas coexist in the same product without any of them pulling the others out of shape.

For regular users, this means opinionated workflows around common investigations, where the context most likely to matter is brought forward rather than buried behind navigation.

For power users, it means preserving depth: expressive queries, flexible aggregations, and advanced surfaces for people who know exactly what they want to ask.

For AI agents, it means tools shaped around investigation intent. The system should aggregate before returning, surface patterns before raw events, and give the model structured context instead of raw telemetry volume. The telemetry platform should do telemetry work. The model should reason over the results.

Observability has always been about helping people understand systems. What changes now is how many different kinds of people, and agents, need to do that understanding at the same time.

Same telemetry. Different consumers. Different interfaces.

The user. The power user. The AI agent.