AI-Native Engineering Demands a New Kind of Observability

Over the past couple of years, I’ve seen many observability vendors re-shipping their existing application performance monitoring (APM) products with some cute AI vectors like token usage, tool calls and model usage breakdown bolted on. But that’s not really a rethink. That’s a nice UI upgrade.

The reason it doesn’t fix anything is that AI systems don’t behave like the systems these legacy APM products were built for. While traditional systems are deterministic, new AI-native systems are probabilistic and adaptive. The same input can produce different results depending on context, prompting, or even vendors rotating model versions without us committing any new code.

Measuring emotions

APM metrics are either binary or continuous. Stuff goes up or down, fast or slow, returns 200 or 500. These signals assume the call either did its job or didn’t, and that “did its job” is a property of the call.

For teams developing agents, this doesn’t really hold water anymore. An agent picks up a task, tries a tool, reasons about the result, hits another tool and eventually replies. Spans are fast, no error logs – and the user walks away furious, because the agent misunderstood the question, forgot something it should have clearly known, even flat out answered with the wrong data. The trace was pristine and the conversation was bad.

This objective “bad” is something APM was never built to see. The problem concerning AI engineering teams is not agents crashing. It’s agents being disappointing. Agents satisfy; they steer emotions. These emotions don’t show up in a latency histogram because they’re not properties of HTTP requests. They’re properties of a conversation.

All of this is more in the realm of psychology than it is of classic software engineering. These are implicit measurements that need to be inferred. These measurements of today simply can’t be measured using the tools of yesterday.

Measure the conversation

Our unit of observation has to change. Here are the new things we should be measuring: What was the user trying to do? Did the agent understand it? Was the agent able to complete its task? If not – why? And most importantly – did the user walk away happy or frustrated?

This is not something we can extract from structured logs. We need models reading these traces. Models that summarize each conversation, manage a taxonomy of topics our users are using our agents for, scoring whether it worked or not – and why. These are the real signals our AI teams need.

These need to be first-class signals in the observability platforms of tomorrow. A team building an agent should be able to set up alerts like “Satisfaction for shopping cart queries dipped below 70% this week,” or “There’s a sharp rise in users trying to order refrigerators and failing.”

 “Users are asking three follow-up questions where they used to ask one.”  Pair that with a chart annotation showing how this regression started right when a prompt change – and now you’re cooking with fire!

All of these are red use-cases that could happily live in a world of low-latency green traces and info level logs.

Closing the loop

Once we have these new signals, they immediately stop being something consumed by humans on a dashboard and start being something our system can act on. A satisfaction drop on refrigerator queries can now trigger a preview run against replayed traces before the next deployment. A refusal spike can surface the prompt change that caused it. Coding agents and software factories can start evaluating the product of their work against the SLO on every iteration and reject changes when the numbers are bad. Observability becomes the connective tissue between what the agent did last and what ships next.

Humans get a new role in this loop. They define what “good” and “bad” mean for each topic or objective the agents handle, they set the SLOs, and orchestrate these loops.

The price of semantic intelligence

Many vendors now ingest OpenTelemetry spans from LLM calls and call it “AI observability”. While token counts, time to first token, and such other signals are important and useful, they are more in the realm of infrastructure and not the core issues our team is concerned with. While running an LLM call over every production trace sounds expensive, and it is, now is the time to build the products that do it right: batch smart, sample well, cache hard, right-size the model. Making this cheap enough is solvable, especially when you consider the alternative is flying an agentic product on the same instruments we used to fly a REST API, which is essentially flying blind.

Closing the gap

Two years from now, every agent team will be running on a small set of interaction-level SLOs. Task success by user intent. Time to resolution across a conversation (rather than a single request). Refusal and escalation rates. Sentiment slope. Topic distribution and how it moves week to week. With milliseconds dethroned, satisfaction points will be the new king.

A lot of this doesn’t exist as metrics today, but it’s all computable from what every agent already produces. The reason we’re not measuring them yet is that the tools we heavily relied on for the past decades don’t have a column for “happiness” – and sure don’t know how to add one.

Teams that fall behind will be the ones running agents on green dashboards while their disappointed users leave.