The demo always works. The agent answers the question, calls the right tool,
returns a clean result, and everyone in the room nods. Three weeks into
production it is confidently telling a customer their refund was processed when
it was not, and nobody noticed for two days. This is the gap between an agent
that runs and an agent you can trust, and observability is what closes it.
Traditional monitoring tells you the server is up and the API returned a 200. An
AI agent can return a perfectly healthy 200 while doing something completely
wrong: hallucinating a fact, calling a tool with bad arguments, looping until it
burns your token budget, or quietly degrading as the model provider ships an
update you did not ask for. Gartner expects 60% of software teams to use AI
evaluation and observability platforms by 2028, up from 18% in 2025, and the
reason is simple. Once an agent makes decisions on your behalf, "is it up?" is no
longer the question. "Is it doing the right thing?" is. This post is about how to
answer the second one.
Why agents break normal monitoring
A normal web request is deterministic. Same input, same output, and when it
fails it fails loudly with a stack trace. An agent is none of those things. It is
non-deterministic, multi-step, and it fails silently with a fluent, plausible
wrong answer.
The failure modes that matter do not show up in CPU graphs:
The model hallucinates a fact or an API field that does not exist.
A tool call fires with malformed arguments, or the agent misreads the
result and proceeds on a false premise.The agent loops, retrying or reasoning in circles until latency and cost
spike.Quality drifts over weeks as inputs shift or the underlying model changes
under you.
None of these trip a 500. That is exactly why teams who only watch uptime get
blindsided, the theme we dug into in
why AI agents fail in production.
Observability is how you make these invisible failures visible.
What to trace in an agent
The unit of observability for an agent is the trace: the full record of one
run, broken into spans for each step. If you only log the final answer, you are
debugging blind. You need to see the whole chain.
For each run, capture the input, every reasoning step, each tool call with its
arguments and response, the retrieval results if you use RAG, the tokens and cost
consumed, the latency per step, and the final output. When something goes wrong,
you want to replay that exact run and see where the chain bent, not guess from a
one-line log.
Log the whole chain, not just the answer
The single highest-leverage thing you can do early is capture span-level traces:
every tool call, argument, and intermediate step. The bug is almost never in the
final message. It is three steps back, where the agent picked the wrong tool or
misread a result, and you can only see that if you logged it.
Evaluation: scoring quality, not just speed
Tracing tells you what happened. Evaluation tells you whether it was any good,
and this is where agent observability departs hardest from classic APM. You are
measuring output quality, faithfulness to source data, and safety, not just
latency and error rate.
Two layers work together. Offline evaluation runs a fixed test set of inputs
against the agent whenever you change a prompt, a model, or a tool, so you catch
regressions before they ship. Online evaluation scores a sample of real
production traces continuously, often using a second model as a judge plus
human review on the disagreements, and alerts you when quality or faithfulness
drops. The combination is what lets you change things without praying, and notice
drift before a customer does.
Build, buy, or self-host
You do not need to write a tracing framework from scratch. The 2026 landscape has
matured fast: tools like Langfuse, LangSmith, Arize Phoenix, MLflow and Braintrust
all do trace capture and evaluation, several of them open source and self-hostable.
The real decision is data governance, not features. If your agent handles
personal or regulated data, sending full production traces to a third-party SaaS
may be exactly the kind of transfer your compliance team forbids, a concern that
overlaps with everything we covered on
GDPR and AI for SMEs. For
those cases, self-hosted tools like MLflow or Langfuse are often the only viable
option. Pick the tool after you have answered where the traces are allowed to
live.
Where to start
If you are running an agent in production today with nothing but uptime
monitoring, do these in order:
Add trace capture first. You cannot improve what you cannot see. Span-level
traces are the foundation everything else sits on.Set hard ceilings on cost and steps. A per-run token budget and a max-step
limit turn a runaway loop into a clean, logged failure instead of a surprise
invoice.Build a small offline eval set. Even 30 to 50 representative cases will
catch most regressions when you change a prompt or swap a model.Sample and score production. Start judging a slice of real traffic so drift
shows up on a dashboard, not in a complaint.Alert on quality, not just errors. Wire alerts to faithfulness and quality
scores, because the worst failures return a confident 200.
The takeaway
An agent without observability is not a product, it is a liability that happens
to demo well. The teams shipping agents people actually rely on in 2026 are not
the ones with the cleverest prompts. They are the ones who can see every run,
score its quality, and catch a bad answer before it reaches a customer.
If you are moving an agent from pilot to production and want it instrumented
properly, traces, evals, cost guardrails and all, talk to us. The
model is the easy part. Knowing what it did, and whether it was right, is the
work.
Top comments (0)