Agent evals (agent evaluation)

Single-response metrics — exact match, similarity to a reference answer — assume the unit under test is one piece of text. An agent's unit of work is a trajectory: did it pick the right tool with the right arguments, keep track of what the user said four turns ago, stop when the job was done, and leave the external state the user wanted? An agent can produce a fluent, polite, individually-reasonable transcript and still fail the task, and a per-response metric will grade every message in that transcript highly.

Agents are also non-deterministic. The same input can produce different trajectories across runs, so agent evals report pass rates over repeated runs rather than a single pass or fail, and the failures worth engineering against usually live in the tail runs rather than the median one.

In practice the field splits grading along two axes: final-response (outcome) evals check whether the end state matches expectations, and trajectory evals check whether the steps taken to get there were reasonable. That split decides most of a suite's cost and most of its blind spots, so it gets its own sections next.

The distinction worth keeping is not between the synonyms but between grading a model and grading an agent. Model benchmarks and single-response scoring grade one piece of text from a frozen model. LLM agent evaluation grades a trajectory: tool selection and arguments, state kept across turns, recovery from failed steps, and the end state left in external systems — reported as pass rates over repeated runs, because agents are non-deterministic.

Whichever term you search, the machinery is what this guide walks through: a task, an environment, a grader, and pass criteria per case; final-response and trajectory grading reported separately on the same case; deterministic checks first and calibrated LLM judges only where assertions cannot reach. And the property that decides whether any AI agent evaluation effort means anything is the same throughout: cases written from failures observed in production traces, not imagined ones. That supply side — traces in, verified eval cases and harness fixes out — is the harness engineering job Moda does, while the evals themselves run in whichever runner you already use.

Final-response grading fails silently on process. An agent can land the right answer through a wasteful or dangerous path — twelve tool calls where two would do, a hallucinated argument that happened to work, a skipped verification step that will bite on the next input. Outcome-only suites pass all of it, and the cost shows up later as latency, spend, and successes that cannot be repeated.

Trajectory grading fails in the mirror image. An agent can execute a clean, defensible sequence of steps and still miss the goal because the final synthesis was wrong. Trajectory checks are also more expensive to maintain: they need reference trajectories or per-step criteria, and they are more sensitive to harmless variation, because two correct runs rarely take identical paths.

So the practical answer to final response vs trajectory is both, assigned deliberately per case. Grade the final response with cheap deterministic checks wherever the task has a checkable end state. Add trajectory grading where the process is the product — tool-heavy workflows, anything with side effects, anything with a cost budget — and weight it toward the steps that production failures show actually going wrong. Report the two as separate scores on the same case: a passing outcome with a failing trajectory is a specific, actionable finding, and so is the reverse.

In practice trajectory evals split into a deterministic half and a judged half. The deterministic half is trajectory matching against a reference: strict mode requires the same tool calls in the same order, unordered mode accepts the same calls in any order, and subset and superset modes bound the agent's calls from above or below — no tools beyond the reference, or at least the reference's tools. LangChain's agentevals package is the cleanest public statement of these modes. Alongside matching sit step metrics that need no reference at all: step counts, loop detection, required-step presence, and budget checks.

The judged half hands the whole trajectory to an LLM judge with a rubric — optionally including a reference trajectory — and asks whether the steps were reasonable. It is the right tool for open-ended tasks where correct paths legitimately vary, and it inherits every LLM-as-a-judge bias, so it needs the same calibration against human-labeled examples as any other judge before its score gates anything.

Strictness is a per-case decision, not a suite-wide one. Exact matching is cheap, deterministic, and brittle — reserve it for compliance-critical sequences where order is the requirement, like a policy lookup that must precede an authorization. Ordinary tool workflows get subset or unordered checks; open-ended work gets the judge. And because agents are non-deterministic, run each case repeatedly: path variance across runs is itself a signal, since an agent that takes a wildly different route every time is fragile even when its pass rate looks fine.

Where do reference trajectories and rubrics come from? The same place cases should: production. A replayed production trace where the agent succeeded is a reference trajectory. One where it failed names the property the judge must catch — codify it and it becomes a regression test. This is the supply side Moda covers: full traces in, behavioral failures attributed per step, trajectory criteria derived from what actually went wrong — while the trajectory scoring itself runs in whichever eval runner you already use.

The decision that determines whether any of this is worth running is none of the four. It is where the cases come from. A suite whose cases were written from imagination measures the team's imagination; a suite whose cases were written from production failures measures the agent. The rest of this page keeps returning to that distinction because every other design choice is downstream of it.

Why write agent evals from production failures instead of from a feature list? Because an agent's failure distribution is an empirical fact about your users and your harness, and nothing else predicts it well. Cases written from a feature list encode what the team imagined at launch; cases written from production failures encode what actually breaks, weighted by how often it breaks. The first suite is a checklist. The second is an instrument. This is also why the loop starts at the traces rather than at a framework: every downstream decision — which cases exist, what each grader asserts, which changes get blocked — inherits its meaning from step 1.

This loop is the job Moda is built for — it is the trace-to-evals half of harness engineering: detecting behavioral failures across the whole trace population, clustering intents to define coverage, attributing each failure to the harness component responsible (a prompt, a tool schema, a skill, the eval set itself), and verifying candidate changes against replayed traces before they ship. Production traces in, verified harness improvements out. The runner, the CI wiring, and the deploy pipeline stay yours.

The checklist is runner-agnostic — LangSmith, Langfuse, DeepEval, and the rest each support some mix of trajectory matching, step metrics, and judged trajectories. What no runner supplies is the evidence: which steps fail in production, on which intents, how often. That is the part Moda rebuilds from production traces, so the checklist runs on real failure data instead of guesses.

Derive the assertions from production tool-call failures, not from the tool catalog. Reading real traces where a tool call went wrong — the wrong tool for the intent, a malformed or hallucinated argument, a redundant retry loop, a required call skipped entirely — tells you exactly which properties are worth asserting, weighted by how often each one actually breaks. A tool-call failure observed in production, codified as an assertion, is a regression test; an assertion written from the tool's documentation is a guess.

Report tool-call accuracy as its own score, separate from final-response accuracy, on the same case. An agent can produce the right answer through wrong tool use — a hallucinated argument that happened to work, three redundant calls where one would do — and a blended score hides it. Two numbers per case make the failure actionable: a passing response with failing tool calls points at the harness (the tool schema, the prompt's tool guidance); failing responses with passing tool calls point at the final synthesis.

Because agents are non-deterministic, run each case repeatedly and report tool-call accuracy as a pass rate, not a single pass or fail. The supply side is where Moda fits: it detects tool-call failures across production traces, attributes each one to the harness component responsible, and turns the observed failure into eval criteria — while the assertions themselves run in whichever eval runner you already use.

The method took over because it scales like code while grading, approximately, like a human. The MT-Bench work that made it credible measured strong LLM judges agreeing with human preferences over 80% of the time — roughly the rate at which humans agree with each other. That result is why LLM-as-a-judge is now the default grader for open-ended agent behavior.

The same research is also the canonical catalog of its failure modes: position bias (favoring whichever answer is shown first), verbosity bias (favoring longer answers), self-enhancement bias (favoring text the judge model itself might have produced), and weak grading of subtle reasoning errors. None of these are exotic. All of them appear in production eval suites that nobody calibrated.

The working discipline is unglamorous. Prefer narrow, binary rubrics per criterion over one 1-to-10 aggregate score. Grade the judge itself against a set of human-labeled examples before trusting it, and re-calibrate whenever the judge model or the rubric changes. A judge nobody has checked against human labels is a random number generator with good grammar.

For agents specifically, judges should read the trajectory, not just the final message — wrong-but-plausible tool arguments and quietly skipped steps are invisible in closing text. And the rubric should be derived from failures observed in production, not imagined ones: a judge tuned to catch failures no user ever hits is a cost center with a confidence interval.

So the practical answer is that an LLM judge is exactly as good as its calibration. Measured against a human-labeled sample, a narrow binary rubric per criterion typically holds up; a single 1-to-10 aggregate score typically does not. Reliability also degrades quietly whenever the judge model or the rubric changes, which is why re-calibration on every change is part of the method rather than an optional extra.

For agent evals specifically, two upgrades make a judge materially more trustworthy. First, have it read the whole trajectory, not just the closing message — wrong-but-plausible tool arguments and silently skipped steps are invisible in final text. Second, derive the rubric from failures observed in production traces rather than imagined quality bars: a judge tuned to catch failures no user ever hits is a cost center with a confidence interval. That second half is the part Moda supplies as a harness engineering platform — behavioral failures detected in real traces become the judged criteria and the human-label calibration sets — while the judge itself runs in whichever eval framework you already use.

In practice the split is not either-or but layered on the same case: deterministic checks run on every case and every run as the floor, and judged criteria sit on top of the subset of cases whose failure modes are open-ended. A case that greets the user politely while passing the wrong account id to a tool should fail on the assertion long before any judge reads the transcript.

If you are shopping for an LLM-as-a-judge framework, the good news is that the choice is low-stakes: Langfuse, LangSmith, Braintrust, DeepEval, promptfoo, and OpenAI Evals all ship both grader types — managed judges with rubric templates alongside assertion and code-based evaluators. The differentiating question is the same one this page keeps returning to: not which framework runs the graders, but where the criteria come from. Moda's part is that supply side — behavioral failures detected in production traces become the assertions and the rubrics, and both run in whichever framework you already use.

The real options span a spectrum. OpenAI Evals established the registry-of-benchmarks pattern in open source. Hosted platforms such as Braintrust, Langfuse, and LangSmith ship dataset management, judges, and CI hooks as a product. Open-source libraries like DeepEval and promptfoo suit teams that want the whole suite living in the repository. All of them are competent at the running part.

Zoom out, though, and the framework is the middle of a longer stack. End to end, keeping an agent evaluated takes five layers: a trace store that captures full production trajectories (every message, tool call, argument, and result — you cannot write cases from traces you did not keep); failure clustering that groups those traces by intent and failure mode so you know what needs a case; the eval suite itself; the judge/code grader mix per criterion; and a regression gate that replays production traffic against any proposed harness change before it ships. Eval frameworks cover the middle two. The outer layers — the trace store and the failure clustering that decide what the suite measures, plus the replay gate that decides whether a change ships — are the parts Moda supplies, as harness engineering rather than as another runner.

The trap is the one Hamel Husain's widely-cited essay on evals names directly: tooling makes running evals easy, which lets teams skip the hard part — error analysis, the unglamorous work of reading real transcripts to decide what is worth testing. A framework filled with hand-written cases executes flawlessly and measures nothing. Framework choice is the fifth most important decision on this page; case provenance is the first.

The standard failure sequence: a team hand-writes an eval set at launch, encoding what they imagined users would do. Traffic arrives and drifts away from those guesses. Six months later the suite is green on every run while users hit failures the suite never modeled. The suite did not rot because the tooling was bad; it rotted because nothing connected it to production.

Moda approaches the problem from the other side. It is not an eval-running platform, not an observability dashboard, and not an LLM router. Moda is a harness engineering platform: it treats the eval set as one component of the agent harness — alongside prompts, tools, skills, and memory — and changes it from production traces. Behavioral failures detected in real traces become eval cases. Intent clusters with no eval coverage become new suites. Proposed harness changes are verified against replayed production traces before they ship.

The practical division of labor: keep whichever runner your team already likes. What changes is the provenance of the cases it runs — evidence from production instead of guesses from launch week.

The harness is everything around the model that makes it your agent: prompts, tools, skills, evals, memory. Every component encodes assumptions about users, and every component drifts as users change. A prompt written for last quarter's traffic goes stale in a familiar way. An eval set written for last quarter's traffic is worse, because the eval set is the instrument that was supposed to detect staleness in everything else. When it drifts, the whole improvement loop reports green while the agent regresses.

Treated as a harness layer, evals get the same operational properties as the rest: cases live in version control next to the prompts and tool schemas they gate; every case traces to evidence — a production failure it reproduces or an intent cluster it covers; the set is refreshed on a cadence tied to traffic shift rather than the calendar; and changes to the eval set itself go through review like any other code.

This is the sense in which Moda works on evals — the same loop it runs for prompts and tools: detect a failure in production traces, attribute it to the responsible harness component, propose a diff, verify against replays. When the component is the eval set, the diff is new cases built from real failures and retired cases that no longer reflect how users behave.

Wrong-model picks rarely throw errors, so error logs will not surface them. The detection that works is population-level: compare quality per intent cluster across the models that served it, from production traces. A cluster that regresses only when the cheap model serves it is a model selection failure with a named location — that cluster, that route — rather than a vague sense that the agent got worse.

The fix path runs through evals, not through shopping for a router product. Turn each observed wrong-model pick into an eval case: input from the real trace, criterion naming the intent cluster and the capability it actually needed. Then compensate in the harness — adjust the routing policy or default, or fix the prompt or tool schema if the failure was never really about the model — and gate the change on replayed production traffic before it ships, per cluster, the same replay gate the model-swap section below describes.

This is also the honest version of AI agent model selection as a practice: deciding which model serves which task from production evidence per intent cluster, not from announcement benchmarks or a leaderboard. To be explicit about what Moda is here: Moda is not an LLM router and does not sit in your request path picking models. Routing stays in your infrastructure — a config file, a gateway, a router you built. Moda supplies the evidence that makes the routing decision right: which clusters fail under which model, eval cases built from observed wrong-model picks, and replay verification that a routing-policy change actually fixed the cluster it targeted.

To be explicit about the division of labor: Moda is not an LLM router and never sits in your request path picking models. Moda is a harness engineering platform for teams building their own router — it supplies the intent clustering, the per-cluster model comparison from production traces, the eval cases built from observed wrong-model picks, and the replay verification that a routing-policy change actually fixed the cluster it targeted. The router itself — the policy, the classifier, the fallback chain — stays in your infrastructure, versioned and owned like any other harness component.

The method in four moves. Traces are clustered into a task taxonomy, so routing decisions have units. Each cluster's quality is measured per serving model — replaying real traces through candidate models where live traffic has not already produced the comparison. Wrong-model picks observed in traces become eval cases with trace provenance, exactly like every other production failure on this page. And every proposed routing change is verified against replayed production traffic before it ships, per cluster, with the affected clusters watched after.

Traces also surface the two failure modes benchmark-driven routing cannot see. Silent fallback downgrades: a rate limit or timeout triggers the fallback chain, a weaker model answers, and nothing in the logs marks the response as degraded. Stale routes: the model that was right at launch still serving traffic that has since changed shape. Both are population-level patterns, visible only when whole trace populations are compared per cluster and per serving model — which is precisely what trace-based router evals do and what request-level logging does not.

This is the trace-to-evals loop Moda runs for every harness component, applied to the model-selection layer: production traces in, verified routing evidence out — while the router, the gateway, and the eval runner all stay yours.

What makes the switch dangerous is that the harness was tuned, mostly implicitly, to the old model's dispositions: how literally it follows instructions, how it formats tool calls, how much it hedges, what it does with ambiguity. The new model breaks those assumptions silently. Generic benchmark deltas between the two models say nothing useful here, because your agent's behavior is the model and the harness together, and the benchmark only saw the model.

The only honest gate is an eval set built from your own production traces: replay the same real traffic through both configurations and compare per intent cluster and per failure mode, not as one aggregate score. An aggregate can hold steady while the three clusters your revenue depends on quietly regress.

The loop that makes the switch survivable is compensate-and-re-gate: run the gate, see which clusters regressed under the new model, fix the harness for it — a prompt adjusted to the new model's instruction-following, a tool schema tightened against its argument habits, a skill added for a workflow it handles differently — and re-run until the gate holds. The switch succeeds or fails on the harness and the evals that gate it, not on the announcement benchmarks of the incoming model.

This is the first job Moda's eval work is built around: hold agent performance through the switch, with the gate built from your traffic and every compensating harness change verified against replayed traces before it ships.