AI Engineer Dojo Contents
Chapter 8

Evaluating Agents

Agents are unusually hard to measure. The same task can succeed through a good path or a lucky one, and fail through a wrong answer or a thirty-step slog. Evaluating agents means scoring both the result and the path, with a harness you build yourself.

Case study

TaskForge: the demos said 100%

TaskForge was ready to ship on the strength of flawless demos. Then it built a real evaluation: 40 tasks with checkable end states (did the test pass, was the record written, did the answer match), each run several times. The agent completed 55% of them, took 14 steps on average, and cost enough per task to worry the finance team.

They scored the path as well as the result: right tools, no destructive mistakes, stopping when done. With those numbers they fixed the biggest failure types and raised completion to 80% while cutting average steps to 8.

Result and path

Outcome evaluation asks whether the agent reached the goal. For tasks with a checkable end state ("the order exists," "the right number came back," "the file contains X"), check it in code. Asking a model "did it succeed?" is softer and easier to fool.

Trajectory evaluation asks how it got there. Two agents can both succeed while one takes 3 steps and the other 18, or one makes five redundant calls. Scoring only outcomes hides this, and you find out from the bill.

What to measure

Report task success rate, steps per task (a stand-in for cost and time), cost per task, and a breakdown of why failures happen: wrong tool, bad arguments, gave up, wrong final answer. The breakdown tells you what to fix.

Success rate alone misleads

An agent that succeeds 90% of the time at 15 steps per task can be worse than one that succeeds 88% of the time at 4 steps, which is nearly four times cheaper and faster. Always report success together with steps and cost.

A fixed task set

Build a set of representative tasks with checkable outcomes and freeze it, so every change is a before-and-after on the same tasks. Twenty to fifty tasks is enough to answer the questions that matter: did this prompt change raise success, or just move it around? Did adding a review step (Chapter 11) help enough to justify its cost?

Run it more than once

The same agent on the same task can take a different path, and sometimes get a different result, on a second run. One run isn't a measurement; a rate over a set is. For important tasks that are flaky, run each a few times and report the pass rate. Calling an agent "working" after one lucky success is the most common mistake in agent evaluation.

Try it · ~25 minFree · no API key

Build an agent evaluation harness

Evaluate two agent configurations on a fixed set of tasks and report success rate and average steps for each. One is thorough, with more steps and more successes; the other is lean. Decide which you'd ship and defend it.

Starter code

TASKS = [f"task{i}" for i in range(8)]

# Recorded outcomes: (succeeded, steps) per task, per config.
RESULTS = {
  "lean":     [(True,4),(True,3),(True,5),(False,6),(True,4),(True,3),(True,4),(False,3)],
  "thorough": [(True,14),(True,16),(True,15),(True,18),(True,13),(False,20),(True,15),(True,14)],
}

def evaluate(cfg):
    rows = RESULTS[cfg]
    success = sum(ok for ok,_ in rows)/len(rows)
    steps   = sum(s for _,s in rows)/len(rows)
    return success, steps

# TODO Step 3: print both, then argue the ship decision on success AND steps.
Worked solution
for cfg in ("lean","thorough"):
    s, st = evaluate(cfg)
    print(f"{cfg:9} success {s:.0%}  avg steps {st:.1f}")
# => lean      success 75%  avg steps 4.0
#    thorough  success 88%  avg steps 15.6

The thorough configuration wins on success, 88% against 75%, but takes about four times the steps, 15.6 against 4.0, and so about four times the cost and time. Whether 13 more points of success are worth that depends on what the task is worth, and you can only discuss it because you measured both. A harness that reported only success would have picked the thorough one by default. To go further, record a reason for each failure and print the breakdown.

Running case · Ridgeline

Ridgeline builds a set of 30 representative tickets with checkable outcomes and runs the agent on all of them every night, reporting completion, average steps and cost per ticket. The first honest number, 61% completion, shows exactly where to work.

If you're starting out

A small agent with a real evaluation harness is one of the strongest portfolio projects you can build. Twenty tasks with checkable outcomes, run a few times each, reporting success, steps and cost, will set you apart from applicants who only have demos.

If you run the team

Never approve an agent on a demo. Ask for results on a fixed set of real tasks, run more than once, with success rate, steps and cost per task side by side. If one version is more successful but costs four times as much per task, that's a business decision you should make, and you can only make it if both numbers are in front of you.

Quiz · Chapter 8

  1. For a task with a checkable end state, what's the most trustworthy outcome check?
  2. Two agents both succeed every time, one in 4 steps and one in 18. Why is outcome-only evaluation risky here?
  3. What is a failure breakdown mainly useful for?
  4. Why is one successful run not proof that an agent works?
  5. What is the foundation of agent evaluation?
Back Continue

The AI Agent Engineer · aiengineerdojo.com