An agent made a call this week. Somewhere, on some team, it routed a ticket, picked a tool, closed a loop the wrong way. Someone opened the dashboard expecting an answer.
What they got was a trace.
The Word Got a New Job
Observability used to mean something specific. Logs, metrics, traces. The ability to infer a system’s internal state from what it puts out. Is it up? Is it fast? Did it error? That definition served infrastructure teams for fifteen years and it still shows up first in every vendor’s glossary entry.
Then agents arrived, and the word quietly picked up a second job.
Every major platform-building agent-tooling company right now makes the same pivot. They open with the classic definition: logs, metrics, and traces, and then they turn a corner. Traditional monitoring tracks what one vendor calls “known unknowns.” Uptime. Latency. Error rate. Agent observability, they say, is built for the “unknown unknowns.” Why did it choose that tool. Where did the reasoning break. Was the answer actually right.
Those are not the same question. The first one is telemetry. The second one is judgment.
Seeing Is Not the Same as Understanding
I wrote about this gap last December in When Speed Exposed Everything. Leaders spent years building dashboards, assuming visibility would produce action. It didn’t. Visibility without motion turned out to be just observation.
The agent version of that mistake is quieter and more expensive. A session trace tells you the sequence. Tool called, output returned, next step taken. It does not tell you whether the sequence was wise. You can have a complete, technically flawless record of every step an agent took and still have no idea whether it made the right call for the actual situation in front of it.
That distinction matters because the word “observability” carries confidence. Once a team can see everything, they stop asking whether they understand anything. The dashboard becomes the explanation, and nobody notices it never answered the question.
Why the Confidence Is Misplaced
Traditional systems fail in ways that announce themselves. An error code. A stack trace. A clear break in a deterministic path. Agents fail differently. They produce a fluent, confident, wrong answer. They loop without ever throwing an exception. The failure is silent because nothing about the execution looked abnormal.
Session tracing captures that execution faithfully. It does not capture the judgment call underneath it, the moment where a different read of the same context would have produced a different, better outcome. Judgment isn’t in the trace. Judgment is in the gap between what the trace shows and what the situation actually required.
More telemetry reaching a dashboard does not mean the right explanation reached the team standing in front of it. Completeness and comprehension are treated as the same achievement. They aren’t.
What This Costs at Scale
Multiply one silent, well-traced wrong call across a fleet of agents running continuously, and the organization inherits a specific kind of false confidence. Every incident review has a clean session trace attached to it. Every postmortem has data. Nobody has to admit they don’t actually know why the system chose what it chose. The trace becomes a substitute for the explanation, and the substitution goes unnoticed because it looks so complete.
People in charge of these systems are the ones who feel this first. They are the ones standing in the room when the trace is technically flawless, and the outcome is still wrong, trying to explain to a customer or a board why a fully observable system produced an answer nobody can account for.
The Restraint Worth Naming
I wrote in Authority Is Not a Feature about the decision to let a system propose rather than declare. That decision came from the same place this one does. A system that shows you everything it did will always feel more trustworthy than one that admits it can’t yet explain why. The temptation is to let the completeness of the data stand in for the honesty of the answer.
It’s the layer I think about constantly with Kosmos. The correlation and organizational memory a real “why” would require sits upstream of any trace, in context that predates the workflow and outlives any single session. Getting that layer right is a different, harder problem than instrumenting the steps an agent already took.
Observability was built to tell you what happened. It was never built to tell you whether it should have. Confusing the two doesn’t make the system more trustworthy. It just makes the gap easier to miss until it costs something.