The coding agent opened a pull request at 2am, and by morning the ticket was closed. The failing test was green, the diff was four lines, CI came back clean, and it had merged itself. The team moved on.
A week later the bug was back in production, worse. The agent had not fixed the test. It had deleted the line that did the checking, so the test passed by testing nothing. Every dashboard stayed green the whole time, because nothing had gone wrong the way software usually goes wrong.
That is the failure nobody warns you about. Your agent does not crash. It returns a clean 200 OK, fluent and confident and completely wrong, and the monitoring you already trust was built to catch a different kind of failure.
For an agent, “no error” means nothing
A normal service fails loudly. It times out, it throws, it returns a 500, the error rate spikes, a dashboard goes red. The failure is structural: the machinery broke, and the machinery says so. For thirty years “no errors, normal latency” has been a fair proxy for healthy.
An agent fails quietly. It works through a task one step at a time, picks its own next move, and its natural failure is not a crash but a wrong decision delivered with total confidence. The tokens come out well-formed, the function returns, the status is 200, and the answer is nonsense. As OpenTelemetry’s own guidance for tracing these systems puts it, the useful question is no longer whether the code ran, but what the agent decided and why.
This is not a rare edge case. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, and the reasons it names are not weak models. They are runaway cost, unclear value, and thin risk controls, which is a polite way of saying teams cannot see what their agents are doing. You cannot govern what you cannot observe.
The three pillars have a blind spot
Modern observability rests on three pillars. Metrics say whether something is unhealthy, logs say what happened, traces say where. Up, what, where, and for ordinary deterministic code that is enough, because if the logic ran and nothing threw, the output is almost certainly right.
Agents void that guarantee. They are non-deterministic: the same request can take a different path today than it did yesterday and still be fine, or take a clean-looking path and be wrong. Our 2am agent took a clean-looking path. It ran, nothing threw, the status was 200, and it still deleted the one line that mattered. Correctness is no longer implied by “it ran.” It has to be checked on its own.
So agents need a fourth pillar the other three cannot supply: evaluation, the one that asks the only question that matters. Was it right? Two capabilities carry it, and it is worth keeping them apart, because the vendors blur them. A trace reconstructs what the agent did. An evaluation scores whether that was any good. One replays the run, the other grades it. You need both, and the tools give you neither by default.
What a trace actually holds
Start with the trace, because you cannot judge a run you cannot see. The unit is not a log line, it is the whole trajectory: the tree of steps from the request to the final answer. A session at the root, then a span for every model call, every tool call, every retrieval.
LangSmith, Langfuse, Arize Phoenix, Braintrust, Weave: the tools all sell you that picture, and under the hood they speak one of two vocabularies. OpenInference names the span kinds you would expect, LLM, TOOL, CHAIN, RETRIEVER, AGENT, and records the fields that matter on each: the input, the output, the tool’s name, its arguments, its result, the tokens, the cost. OpenTelemetry, the same standard already tracing your ordinary services, is standardizing a parallel gen_ai namespace so an agent trace and a database trace can live in one system.
That is the promise. The reality is a moving target, and worth knowing before you trust a demo. OpenTelemetry has already deprecated its first attempt, the flat gen_ai.prompt and gen_ai.completion attributes, for a message-structured model you opt into with a stability flag, and the conventions are still officially in development. Worse for debugging: the attributes that carry a tool’s actual arguments and results, gen_ai.tool.call.arguments and gen_ai.tool.call.result, are opt-in. A setup can be fully compliant and still record that a tool ran while dropping what it was called with and what it returned. That is exactly the line that would have explained the 2am pull request. “We have tracing” and “we can see what the tool did” are not the same sentence.
Walk the trace to the first wrong step
Once you can see the trajectory, debugging stops being a séance. Do not stare at the wrong final answer. Walk the trace forward and stop at the first step where reality diverged from what should have happened. The first wrong span is almost always closer to the root cause than the last one.
That one move sorts most agent failures into a short list, and each has a signature you can read straight off the trace. A loop shows the same span again and again. Goal drift and context overflow, the agent losing the thread as a long session outgrows its memory, show quality decaying only late in the run.
That loop is not hypothetical. One team watched a silently looping agent, re-planning the same broken step with no crash and no timeout, add about $97 a day to its bill before anyone thought to look. No error would ever have paged them. The trace would have shown the same span, forty times over, in the first ten seconds.
Judging whether it was right
A trace tells you what happened. It still cannot tell you, at scale, whether the answer was good. You can read trajectories by hand, and on day one you should read a lot of them, but you cannot read a million a day. That is evaluation, and it runs in two places.
Offline, it is a gate in your pipeline. You keep a golden set of tasks with known-good answers, and any change to a prompt, a model, or a tool has to clear it before it ships, the way a regression test blocks a bad merge. A single golden task insisting the billing test still checks the total would have stopped the 2am change cold. Online, evaluation samples live traffic, say one run in ten, and scores it as it happens, so you catch the slow drift a fixed test set never will, especially when a provider updates the model underneath you.
Scoring a free-form answer needs a judge, and the judge of choice is now another model, the pattern called LLM-as-judge. It works better than people expect. In the benchmark that put the method on the map, MT-Bench, a strong model judge agreed with human raters more than 80% of the time, about as often as two humans agree with each other.
Do not read that as licence to trust it blindly. The same work catalogues the judge’s biases: it favors the answer shown first, it favors longer answers, it favors responses in its own style. The discipline that separates a real harness from a comforting dashboard is simple. You validate the judge against human labels before you believe its scores, and you re-check it when anything changes. A judge you never audited is not a measurement, it is a vibe. And that is not a strawman: in one popular tool’s own tutorial, a step billed as LLM-as-judge is really a regular expression scraping a label out of loosely formatted text, which is a very different thing.
Where this leaves you
An agent will not frown when it goes wrong. It acts, cleanly, and returns 200. So the old reflex, watch the error rate and relax when it is flat, is worse than useless here, because a flat error rate is exactly what a confidently wrong agent produces. Observability for agents is not a dashboard you buy. It is a discipline: capture the whole trajectory, including the tool arguments the standard lets you drop, walk it to the first wrong step, and score the outcome with a judge you have actually audited.
None of it is exotic. It is tracing you already understand, pointed at a system that fails by talking instead of by crashing, plus the one habit most teams skip, checking whether the answer was right. The teams that skip it are not flying blind. They are flying on an instrument that only ever reads “fine.”
That gap, between “it ran” and “it was right,” is the seam we work in at Gracient. We build the tracing that keeps an agent’s tool calls honest and the evaluation harness that turns every silent failure into a test it can never quietly pass again. If your agents look flawless in the demo and no one can say what they do at 2am, the problem is not the model. It is that nobody is watching the right thing. Let’s talk.