AI Systems

Agentic Evals — Scoring the Trajectory, Not Just the Answer

Standard evals score a single input-output pair. Agentic systems make that insufficient: an agent that reaches the right final answer by calling the wrong tool, in the wrong order, five more times than necessary, has a serious production problem that final-answer accuracy alone will never surface. Agentic evals score the full trajectory — the sequence of reasoning steps, tool calls, tool results, and intermediate decisions the agent took to arrive at its answer.

Trajectory evaluation

Scores the path taken, not only the destination. Exact-match trajectory evaluation checks whether the sequence of actions matches a labelled gold trajectory step for step — strict, and often too rigid, since multiple valid paths can reach the same correct answer. A more practical approach uses an LLM judge to assess whether each step was reasonable given the state at that point, independent of whether it matches a single reference path — the generalization of LLM-as-judge scoring to a multi-step setting: instead of judging one output, the judge walks the trajectory and scores coherence, necessity, and correctness of each step.

Tool-call correctness

Precision and recall computed over the set of tool calls the agent made versus the set it should have made, given the task. Precision catches unnecessary or hallucinated tool calls — calling a search API when the answer was already in context. Recall catches missed steps — failing to call a verification tool before taking a destructive action. A further layer checks argument correctness: did the agent call the right tool with the right parameters, since a correct tool choice with malformed or wrong arguments is functionally a failure even though it may look correct at a glance.

Efficiency and groundedness metrics

Efficiency metrics track the number of steps, tool calls, and tokens consumed to reach a correct outcome — two agents that both succeed are not equally good if one takes twelve steps and the other takes four, and this directly maps to production cost and latency. Groundedness metrics check, at each step, whether the agent's stated reasoning is actually supported by the tool results it has received so far, catching a specific and dangerous failure mode: an agent's chain-of-thought fabricating a justification disconnected from what its tools actually returned.

Productionizing this pattern

Real-world applications

• Booking/transaction agents — an agent that searches, compares, and submits a booking through an API needs trajectory evaluation to isolate whether failures are search errors, comparison-logic errors, or booking-API misuse.
• Coding agents — tool-call precision/recall separates "wrote correct code" from "wrote correct code after five unnecessary file reads," which matters for both cost and trust.
• Research/analysis agents — groundedness checking catches an agent that cites a conclusion its own retrieved sources don't actually support.
• Customer-service agents — efficiency metrics catch an agent that resolves a ticket correctly but takes an unreasonable number of tool calls to get there, driving up cost per resolution.

Embedded applications

• Physical consequences make trajectory scoring non-negotiable — an agent controlling a robot arm, a drone, or an industrial actuator that reaches the "right" final state via a dangerous or inefficient sequence of intermediate moves has a serious problem final-state checking alone will never surface — this is the same "path matters, not just the destination" idea as CAN's arbitration guaranteeing a deterministic message order, just applied to an agent's decisions instead of bus traffic.
• Step-count ceilings map to real-time deadlines — the "hard step-count or token-budget ceiling" recommendation above isn't just a cost control on embedded/real-time systems, it's often a correctness requirement — an agent-driven control loop that blows past its deadline is exactly the kind of missed-deadline failure covered in RTOS scheduling.
• Tool-call correctness extends to hardware calls — for an agent that can read a sensor, write a GPIO, or issue a UDS diagnostic command, "tool calls" are physical I/O — precision (no hallucinated hardware writes) and recall (no skipped safety checks before a destructive action) are the exact same metric, with a much higher cost of a false negative.
• Groundedness catches the specific fabrication failure that's most dangerous on hardware — an agent whose reasoning claims a sensor reading supports an action it's about to take, when the actual tool result said something else, is precisely the "confidently wrong action reaching the real world" scenario friction by design exists to catch as a last resort — groundedness checking is how to catch it earlier, in evaluation, before it ever reaches production.

Gotchas