Evals for agents that use tools, not just tokens.

The first time you evaluate an agent, you almost always evaluate the wrong thing. You run a fixture set of questions through the system, you score the answers, you feel good. Two weeks later a production trace shows the agent burning three-hundred tool calls to arrive at the answer it produced in six calls yesterday, and none of your dashboards flagged it. The “correctness” number was still high. The system was already broken.

The gap between what you measured and what actually mattered is where production agents fail. A useful eval scores the trajectory, not the terminus.

What a trajectory-level eval actually looks like

A trajectory is the ordered sequence of steps the agent took to arrive at its answer — the tool calls, the intermediate reasoning, the failures, the recoveries. Scoring a trajectory means answering questions the final answer alone can’t:

Did it call the right tool for the sub-goal?
Did it retry sensibly when a tool failed?
Did it stay inside the budget?
Did it recover from a wrong turn or double down?
Did it produce a final answer that a competent operator would also have produced given the same intermediate observations?

Each of these is a separate rubric, applied to a specific span of the trace. You don’t score the whole trajectory with a single number; you score it as a chain of decisions, then aggregate.

The eval spine

The eval spine is the fixture set you’d fight to keep if the office was on fire. On a production agent it usually contains three kinds of things:

Ground-truth trajectories. For a set of representative goals, a “canonical” trajectory that a senior operator would agree is close to right. Not the only right answer — but a reference against which you can score whether the model’s decisions were reasonable.

Failure-mode fixtures. Cases you know the previous version got wrong, and cases you’re worried about the next version getting wrong. Each with a specific rubric that catches the specific failure. These are the fixtures that go into a regressions/ directory and never leave.

Adversarial fixtures. Malformed tool outputs, empty search results, tool timeouts, permission errors. What the agent does when the world misbehaves is at least as important as what it does when the world cooperates.

Scoring at the span level

You get much more useful signal from scoring individual spans than from scoring the final answer. A single trajectory becomes a set of judgements:

- goal_understood: 1.0
- plan_reasonable: 0.8       (took a marginal detour to a related tool)
- tool_calls_correct: 5/6    (one unnecessary re-fetch after a tool timeout)
- budget_respected: pass
- recovery_from_failure: pass
- final_answer_correct: 1.0

Now you can catch regressions the final-answer rubric would have missed. If the next version of the model produces the same final answer but does so with three redundant tool calls, your span-level rubric will flag it. Cost-per-trajectory will drift; latency will drift; both will be visible before a user sees them.

The rubrics we reach for

There’s no single rubric library that covers every case, but a few patterns come up in almost every engagement:

Tool-call correctness. Given the observed intermediate state, was this the right tool with the right arguments? An LLM-as-judge rubric here works well if the judge has access to a tool-catalogue and the observation history.

Sub-goal coverage. Did every sub-goal in the plan get addressed before the agent returned an answer? An unaddressed sub-goal is often invisible in the final answer but catastrophic downstream.

Budget adherence. Steps, tokens, tool calls, wall-clock time. Hard caps that abort with a diagnostic. If your agent has ever surprised you with a bill, this is the rubric that would have caught it.

Recovery quality. When a tool call failed, did the agent retry appropriately, back off, ask for help, or spiral? “Recovery” is often where good agents visibly separate from bad ones.

Grounded finality. Every claim in the final answer traceable back to an observation. If the answer contains a fact the agent didn’t see, that’s a hallucination — regardless of whether the fact happens to be true.

Online vs offline

Offline evals — the eval spine against a fixed fixture set — are what you gate deploys against. They catch regressions before they ship.

Online evals — rubrics applied to live traces, sampled and scored — are what you gate production against. They catch drift the offline set missed, and they surface the fixtures you should add to the offline set.

The two loops feed each other. A regression caught online becomes a fixture in the offline set. A rubric that keeps firing offline becomes the target of a specific improvement. If you’re running one loop but not the other, you’re either shipping blind or debugging blind.

What we do in the first two weeks

When we come in on an agent programme, the first two weeks are almost always the same shape:

Instrument the existing system so every trajectory produces a structured trace.
Draw fifty representative trajectories from real workload data, labelled with ground truth or reference behaviour.
Define the span-level rubrics that map onto the client’s specific quality bars.
Wire a scoring pipeline that runs those rubrics over the fixture set on every commit, and against a rolling sample of production traces every hour.
Put the results in a place the on-call engineer looks anyway.

Step five is the one that gets skipped and the one that matters most. An eval that lives in a dashboard nobody visits is worth about the same as no eval at all.

So what?

Two things worth taking away.

First: if you evaluate an agent only on its final answers, you’re measuring the demo. Trajectory-level eval is what surfaces the failure modes the demo hides.

Second: eval infrastructure is not overhead. It’s the substrate that makes it safe to ship anything else. Every subsequent decision — swap the model, swap the framework, tighten the guardrails — is a bet you can only reason about if you can measure the thing you’re betting on.

Build the eval spine before you tune the agent. Everything downstream compounds off the quality of that decision.

A senior engineer’s checklist before letting an agent commit — the human-review side of the same coin.
Three ways to bound an agent loop before it eats your budget — the budget rubric, applied at the runtime.

Tagged — evaluation agents observability

Nearby in the archive.

← Older

Three ways to bound an agent loop before it eats your budget.

Every agent programme discovers, usually painfully, that "the loop won't terminate" is the default behaviour of loops. Here are three specific bounding patterns we reach for — each with the failure mode it's actually preventing.