Evaluating and monitoring agents in production

I’ve written about building eval sets for agents — the pre-launch discipline of measuring whether an agent completes its tasks across a representative set. That’s necessary, but it answers only one question: does the agent work on the cases you thought to test? Production answers a different and harder one: does it work on reality — the messy, unanticipated, adversarial inputs real users actually send? The gap between those two questions is where agents quietly fail, and only continuous monitoring in production closes it. This is a deep-dive on observing agents in the wild: what to log, what to measure, how to catch the degradation that happens silently, and how production failures feed back into the evals so the whole system gets better over time.

Why pre-launch evals aren’t enough

Start with the limit, because it motivates everything. A pre-launch eval set measures the agent against cases you chose — and however representative you made it, it is a finite, anticipated sample. Production traffic is neither finite nor anticipated: real users send inputs you never imagined, in distributions that shift over time, including adversarial ones designed to break the agent. So an agent that scores well on your eval set can still fail in production, because production contains cases your set didn’t — and the only way to know is to watch it run on real traffic. Evals tell you the agent is ready to launch; monitoring tells you whether it’s actually working now. You need both, and the second is the one teams most often skimp on, because it’s ongoing work rather than a launch gate.

What to log

Monitoring an agent starts with observability, and an agent demands more than a single LLM call because there’s a whole trajectory to capture. For every run, log enough to reconstruct what happened:

The full trajectory. Every step — each decision, each tool call and its result, each intermediate output — not just the final answer. When an agent produces a bad outcome, the trajectory is where you see how it got there, and without it a failure is uninvestigable. This is the agent equivalent of the “log every interaction” rule, scaled up to the multi-step reality.
Inputs and outputs. What the agent was asked and what it ultimately did or returned, so you can see the cases reality is actually sending and judge the outcomes.
The cost and resource footprint of each run. Steps taken, tokens spent, time elapsed, tools used — because for agents, efficiency is a health metric, and a run that completed but took twenty steps is a signal even if the outcome was fine.
Failures and their kind. When a guardrail fired, when a step limit was hit, when a tool errored, when the agent gave up — categorized, so failures are countable and patterns are visible.

The principle is that you can’t monitor what you didn’t record, and an agent’s behaviour is the whole trajectory, not the endpoint. Log richly, because the run you most need to understand is one that’s already over.

What to measure

Logs are raw material; monitoring is the metrics you derive from them and watch over time. The ones that matter for an agent:

Task completion rate in the wild. The headline: how often is the agent actually accomplishing what users want, on real traffic? This is your eval’s task-completion metric, but measured continuously on reality instead of once on a test set — and the two can diverge, which is exactly the thing you want to catch.
Efficiency trends. Average and tail steps, tokens, latency, and cost per task over time. A creeping rise in steps-per-task or cost-per-task is an early warning that something is degrading, often before the completion rate visibly drops.
Failure rates by category. How often each kind of failure happens, trended. A spike in a particular failure type points you straight at what’s breaking.
Drift signals. Shifts in the distribution of inputs or outcomes over time — a sign that reality has moved away from what you built and tested for, which is one of the most common and most silent ways an agent degrades.

The unifying goal is to catch silent degradation — the agent getting worse without anything throwing an error. An agent can decline gradually, in quality or efficiency, with no exception ever raised; only watching the metrics over time reveals it. A clear alert when task completion drops or cost spikes turns a slow, invisible decline into a noticed, actionable event.

Catching silent degradation

This deserves its own emphasis because it’s the failure mode unique to non-deterministic, long-lived systems and the one monitoring exists to catch. An agent doesn’t only fail by crashing; it fails by slowly getting worse — completing fewer tasks, taking more steps, drifting off-target — while every individual run looks superficially fine. Causes are everywhere: a model provider updates a model under you, your input distribution shifts as your user base changes, a dependency the agent relies on changes its behaviour, a prompt tweak interacts badly with real traffic. None of these throw an exception. The only defense is watching the trends: a completion rate ticking down, a cost-per-task ticking up, a failure category creeping in. Set thresholds and alert on them, so the question “is the agent still working as well as it was?” has a continuously-monitored answer rather than being discovered when a customer complains.

Closing the loop back to evals

The most valuable thing production monitoring produces isn’t just alerts — it’s material that makes your evals better. This is the feedback loop that makes the whole system improve over time, and it’s the payoff for logging richly:

Production failures become eval cases. Every new way the agent fails in the wild is a case your eval set didn’t have. Capture it, add it to the eval set, and now a future change can’t silently reintroduce that failure — your eval grows to cover the reality your imagination didn’t.
Real traffic reveals what to test. The distribution of actual inputs tells you where to focus eval effort — the common cases that matter most and the edge cases that actually occur, rather than the ones you guessed at.
Monitoring validates eval relevance. If the agent scores well on your evals but poorly in production, your eval set has drifted away from reality and needs updating. Production is the ground truth that keeps your evals honest.

This closes the loop: evals gate the launch, monitoring watches reality, and reality’s failures feed back into the evals — so the agent’s safety net grows to match the world it actually operates in, rather than staying frozen at what you imagined before launch. An agent whose eval set never learns from production is an agent whose tests slowly drift away from the truth.

Verdict

Pre-launch evals tell you an agent works on the cases you thought to test; production tells you whether it works on reality, and only continuous monitoring closes that gap — because real traffic is infinite, unanticipated, and shifting in ways no finite eval set can contain. Monitoring an agent starts with logging the whole trajectory — every step, decision, tool call, and result, plus inputs, outputs, cost, and categorized failures — because an agent’s behaviour is the trajectory, not the endpoint, and you can’t investigate what you didn’t record. From those logs you derive the metrics that matter — task completion on real traffic, efficiency trends, failure rates by category, drift signals — all watched over time to catch silent degradation, the unique failure mode where an agent slowly gets worse with no exception ever thrown, defended against only by trending the numbers and alerting on them. And the highest payoff is closing the loop back to evals: production failures become new eval cases, real traffic reveals what to test, and the gap between eval and production scores keeps your tests honest — so the agent’s safety net grows to match the world rather than staying frozen at launch. Evals gate the launch; monitoring keeps the agent honest in the wild; and the two together, with reality feeding back into the tests, are what turn a launched agent into one that keeps working — which, as ever with agents, is the part the demo never has to do.