Two things to measure: outcome and trajectory
- Outcome (did it succeed?) — task-completion rate against a golden set of tasks with checkable success criteria (the ticket was resolved, the code passed tests, the answer matched ground truth). This is the metric that matters most.
- Trajectory (how did it get there?) — the path: which tools it called, in what order, how many steps, whether it took efficient routes or wandered. Two agents can both succeed while one costs 3× as much.
Metrics to track
- Task success rate (the headline).
- Steps / tool calls per task and cost / latency per task — efficiency; a "successful" agent that takes 40 steps is a problem.
- Tool-call success rate and error-recovery rate — did tool calls work, and did it recover from failures?
- Per-step correctness — since errors compound, sample steps and check whether each decision was reasonable.
Build an eval set of tasks
Like LLM eval (see the Evaluation course), curate representative tasks with success criteria + hard cases (ambiguous goals, tool failures, injection attempts, out-of-scope requests to test "ask the human"). Gate changes on it, and mine production failures into new test tasks.
Debug with traces
The single most important agent-debugging tool is full trajectory logging — every thought, tool call, arguments, observation, tokens, and cost, viewable as a timeline (LangSmith, Langfuse, Arize Phoenix, OpenTelemetry). When an agent fails you walk the trace to the exact step it went wrong: bad retrieval? wrong tool? misread observation? bad reasoning? That routes the fix (better tool, better prompt, better guardrail) exactly like the retrieval-vs-generation split in RAG.