What Agent Observability Actually Covers (and Where It Hits a Ceiling)
Agent observability is valuable for reliability, but the learning question requires a different category—one designed to compound how teams work.
I spent about five years building observability systems — logs, metrics, traces at real scale. So before I say anything opinionated about agent observability, let me do the thing the topic actually calls for and lay out what these tools do, because it’s genuinely useful and worth understanding before you buy one.
What agent observability platforms actually cover
At the core, they give an agent run a trace — the same primitive that transformed backend systems — and let you follow it end to end. In practice that means a handful of things. They capture the full sequence of a run: the LLM calls, the tool calls, the retrievals, the intermediate steps, in the order they happened, so you can see what the agent actually did rather than just what it returned. They track the operational numbers — latency, token usage, cost per run, cost per step — which matter more than people expect once you’re running agents at any volume. They surface errors and failures: where a run broke, where a tool call returned garbage, where the agent got stuck in a loop. Most of the serious ones now include some form of evaluation — scoring outputs against quality criteria, either with rules, human review, or model-graded evals — so you can tell whether a run succeeded, not just whether it completed. And they version things: which prompt, which model, which config produced which result, so you can tell whether last week’s change made things better or worse.
What to look for when you’re comparing them
A few questions separate the real ones from the thin ones. Does it trace multi-step and multi-agent flows, or does it fall apart the moment one agent calls another? Does it capture tool calls and retrievals as first-class events, or does it only see the LLM calls and leave you blind to the half of the run that actually touches your systems? Does it support evaluation, or does it stop at raw telemetry and leave the “was this any good” question to you? Will it hold up at production scale and volume, not just in a demo? And does it integrate with the framework and harness you already use, or is it going to demand you rebuild your stack around it? If you’re running agents in production, you need something that answers most of these. This is a real category solving a real problem, and I have a lot of respect for the teams building in it.
But it’s the wrong ceiling
Classical observability was built to monitor machines. The implicit goal is reliability — keep the system up, catch the regression, page someone when the latency spikes. When people point that same lens at agent sessions, they inherit the same goal: treat the session as a system to be monitored, and report on its health. Uptime for agents. Everything I described above is, underneath, in service of that question — is the agent working?
Here’s what that misses. An agent session isn’t a machine doing a deterministic thing. It’s a collaboration between a person and a model, and the interesting signal isn’t whether it stayed up — it’s how good work actually got done. Which framing worked. Which correction unblocked it. Why one person gets a great result from the same agent that leaves someone else fighting the tool for an hour. Reliability monitoring can tell you the session completed. It can’t tell you the person got better, or teach the next person how they did it.
The instinct that gets this right is one I’d phrase as: store and learn from your production traces. Not telemetry hoarded “just in case,” but real execution used to make the next execution better. For an applied-AI team that’s not quite recursive self-improvement, but it’s not far off either — the raw material for improvement is sitting right there in the sessions, and almost nobody is mining it.
Zoom out and it’s really about building a compounding learning machine. The organizations that win won’t be the ones with the best single agent; they’ll be the ones that shorten the loop between “someone figured out how to do this well” and “everyone does it that way now.” Reliability monitoring doesn’t close that loop. It was never trying to.
So when someone tells me they have agent observability covered, I believe them — for the reliability question. The learning question is a different category, and it’s the one that compounds. That’s the one we’re building for.