Metrics, logs, and traces are built for systems whose important decisions were made before the request arrived.
Agent observability has a different center of gravity.
Agents make decisions at runtime. The important bug is often not that a request took too long or a tool call failed. It is that the agent chose the wrong thing for reasons you never captured.
You can't dashboard what you didn't decide.
Traditional observability assumes the system's logic lives in code you can instrument directly. Agent systems move part of that logic into runtime context, model output, and tool selection. The decision becomes the thing you have to observe.
The decision is the unit of observation
In a traditional system, the unit of observation is the request. A request comes in, flows through the system, and produces a response. You trace the request, measure its latency, log its outcome. The request is the thing you watch.
In an agent system, the unit of observation is the decision. The agent receives input, decides what to do, takes an action, and observes the result. The action might be a tool call, a state change, a message sent, or another decision. The decision is the thing that matters, because the decision is the thing that can be wrong.
Traditional observability captures the action: the tool call, the API request, the state change. It does not capture the decision.
Why did the agent make this call? What context was it considering? What did it ignore? What authority did it believe it had?
Those are the debugging questions. Traditional observability was not built to answer them.
The hard part of agents is authority covers what the agent is allowed to do. Observability covers what it actually did, and why. You need both to operate the system safely.
What an agent dashboard looks like
A traditional dashboard shows system health: error rate, latency, throughput, resource usage. Those still matter. The agent runs on infrastructure, and the infrastructure can break.
They are not enough.
An agent dashboard needs to show decision health:
Decision trace. Every decision the agent makes, in order, with the context that led to it. The useful trace shows the input, the available options, the selected action, and the reason the system recorded at the time. Without it, you end up debugging from outputs and guessing at the reasoning.
Action audit. Every action the agent took, with the authority level it used. Did it read data? Write data? Call an external service? Was the action within its permitted scope? The audit trail is both security evidence and operational evidence.
Outcome tracking. What happened after the agent acted? Did the action achieve the intended goal? Did it produce side effects? Did it trigger another decision? Outcome tracking connects the decision to its consequences. Without that loop, you only know what the agent did, not whether it helped.
Drift detection. Is the agent making different decisions than it used to for the same inputs? Behavior drifts as context changes, tools move, and the surrounding system evolves. Drift detection tells you something changed before you know what changed.
Observability changes the agent's behavior
Observability is runtime architecture. Monitoring changes the system being monitored. Scraping changes timing. Tracing changes allocation.
For agents, the effect is stronger.
When you add observability to an agent, you change the agent's context. The agent now knows it's being observed (if you include the observability in the prompt), or its behavior changes because the observability adds latency and tokens (if you don't). Either way, the observed agent is not the same as the unobserved agent.
The observer effect is operational, not theoretical. If you log every decision to a dashboard, the agent's context window fills up faster. If you add an explanation step for auditability, the agent takes longer and produces more tokens. If you add a human check for high-authority actions, the workflow changes. The observability is part of the runtime, and it affects the behavior you are trying to understand.
Agent observability has to be planned, not bolted on. You cannot add decision tracing after the fact without changing behavior.
What gets logged, when it gets logged, and how that logging affects context and latency are design decisions.
The failure mode you can't see
The most dangerous agent failure is the one that looks like success.
The agent takes an action. The action produces the intended outcome. The dashboard shows green. Everything looks fine.
But the agent took the action for the wrong reason. It reached the right answer through a path that happens to work this time but won't work next time. Or it took an action that was within its authority but for a reason that reveals a misunderstanding of the system. Or it made a decision that's correct in isolation but creates a state that will cause a problem three decisions later.
Traditional observability cannot catch this because the outcome is correct. The metrics are fine. The action was permitted.
The only way to catch it is to inspect the decision trace and notice that the path to the correct outcome was wrong.
Decision traces matter because the action log only tells you what happened. It does not tell you why the system believed that action was appropriate.
For agents, "why" is where the bugs live. The reasoning is the system, and it is produced at runtime.
Agent observability still needs the normal infrastructure signals. Latency, errors, saturation, and cost still matter. They just no longer describe the whole failure surface. For agents, the decision path is part of the runtime state, and the system is hard to operate if that state disappears.
The one-line version
Agent observability has to preserve the decision path, because actions alone do not explain the system.