Why AI Agent Observability Requires More Than Tool Call Logging

Most teams building agent systems have a logging setup. They log which tools got called, what each one returned, how long each hop took. That's the right instinct. It's aimed at the wrong layer. Tool calls are the infrastructure layer of an agent. They tell you whether the plumbing worked. What they don't capture is the reasoning step that decided which tool to reach for, why, and with which arguments — and that reasoning step is exactly where agents fail silently while every metric you're watching stays green. An agent that calls the right tools, gets valid responses, and still produces the wrong outcome doesn't throw an error. It just quietly reaches the wrong conclusion, three steps before the part you can see. 1. What a Trace Covers and What It Misses A stack trace tells you where execution stopped and why. That's what you need when code crashes. But an agent that approves a refund it shouldn't, or escalates a low-priority ticket to a senior engineer at 3 AM, doesn't crash. Every individual call succeeded. The failure lives in the reasoning step that decided escalation was warranted, and that step produces no trace span by default. It produces a chain of tokens in a context window that nobody's logging in a form you could query during an incident review. Most teams aren't saving the reasoning because it's verbose and storage-expensive. You end up with a trace that's complete in the parts that don't matter and empty in the one that does. 2. A Week That Looked Perfect Until It Didn't An agent triages incoming support tickets and routes the ones it judges urgent to a PagerDuty escalation. Over one week, it correctly escalates 340 tickets and your dashboards show healthy tool-call latency, a 99.8% success rate on the routing tool, and zero exceptions. Buried in that week, eleven tickets about a minor UI bug get escalated as critical because the agent latched onto the word "urgent" in the customer's subject line and never weighed it against the actual severity in the ticket body. Every metric you have says the system is healthy. The actual signal — that the agent's judgment is miscalibrated on a specific pattern — doesn't appear anywhere, because nothing about those eleven escalations looked anomalous at the infrastructure layer. The dashboard was right. The system was still wrong. 3. Why Traditional Tracing Stops One Layer Too Early Distributed tracing got good at showing the path a request took through services — which function called which, how long each hop took, where latency went. Applied to an agent, tracing shows which tools got called in which order. What it doesn't show is why the agent chose that order, or what it considered and rejected. That reasoning happens inside the model's context, not across a service boundary, so the tracing tools built to instrument service boundaries have nothing to attach to. You end up with a trace that's complete in the parts that don't matter and empty in the part that does. This isn't just my read on the situation. OpenTelemetry's own GenAI observability working group has spent the last year building semantic conventions for agentic systems specifically because the standard tracing model has nowhere to attach an agent's reasoning step — the effort now spans agent spans, decision events, and orchestration metrics that didn't exist in the original spec, with Datadog, Honeycomb, and New Relic all building support before the convention has even settled. When the people who invented distributed tracing are extending it to cover this gap, that's a structural admission, not a hot take. 4. Old Way vs New Way The old way of debugging a misbehaving system meant reading code, finding the conditional that took the wrong branch, and fixing the logic. Deterministic, if tedious. The new way means reading a transcript of a model's reasoning, which is non-deterministic, context-dependent, and won't reproduce the same way twice if you rerun it. That's a real loss, and pretending otherwise doesn't help anyone. You can mitigate it — log full transcripts, capture the context window at decision points, sample reasoning traces the way you'd sample profiling data — but you can't get back the certainty of stepping through a deterministic function. Teams that don't accept this upfront keep trying to debug agents with tools built for the old certainty, and keep being surprised when it doesn't work. 5. What Actually Needs Instrumenting Treat the model's decision points as first-class spans, not an afterthought attached to the tool calls around them. That means capturing the relevant slice of context the model saw before it acted, the tool calls it made, and — where your framework supports it — some representation of why it ranked one action over another. The most useful rule I've applied: full logging on anything that touches an irreversible action — a payment, an escalation, a write to a customer record — and sampled logging on everything else. The reasoning is simple. You will need that transcript exactly once per incident, and you won't know which run until after the fact. An escalation you can't explain is an escalation you can't defend in a postmortem. Log it in full. A routine read-only lookup doesn't carry the same cost if you miss it. Sample it. Every team that skips this distinction ends up logging either everything (expensive and noisy) or the wrong thing (useless when it matters). 6. The Tradeoff Nobody Wants to Admit Full logging on every agent decision gets expensive fast — in storage and in the noise you have to wade through during a real review. Sampling helps, but sampling means you'll occasionally miss the exact run you needed. There's no clean answer here, and any article telling you there is one is overselling it. What I've seen work is the irreversible-action boundary above, combined with a shorter retention window for sampled traces and a longer one for anything touching money, escalations, or customer state. It's a tuning problem, and you should expect to revisit the boundary every quarter as you learn where your actual incidents come from. Build the logging first. Tune the boundary after you've seen a few real failures. 7. Make the Review the Habit, Not Just the Logging Logging reasoning traces doesn't help if nobody reviews them until something breaks. Build a lightweight, recurring sample review into your on-call rotation — not because every sample reveals a bug, but because the practice of looking regularly is what catches miscalibration before it becomes a pattern of eleven mis-escalated tickets. This is unglamorous work, closer to a code review habit than a monitoring dashboard. Tooling can surface the data. Only a human looking at it regularly will catch the thing the metrics aren't measuring. Schedule it the same way you'd schedule a review of slow-query logs. Not after an incident. Before one. The agents most teams are running today are passing every metric they're measured against, and that's exactly the problem — those metrics were designed for a system that fails by throwing errors, and agents mostly don't fail that way. The fix isn't a better dashboard. It's accepting that the interesting failures live one layer below what your current tooling can see, and building a deliberate habit of logging at the decision layer and reviewing it before an incident forces you to. Log the tool call, yes. But log the decision first. That's the layer that tells you whether the agent actually did the right thing or just did a thing very cleanly.