Evaluating Agents
Agents plan, call tools and take several steps to finish a task. They're the hardest systems to evaluate, because the output is a whole trajectory: a sequence of decisions, tool calls and results. This is also the part of the field growing fastest.
Orbit's demo said 100%
Orbit's task-automation agent had a flawless demo and was ready to ship. Then the team built a proper test: 40 tasks with checkable end states (was the record written, did the answer match), each run several times. The agent finished 55% of the tasks, took 14 steps on average, and cost enough per task to strain the business case.
They scored each run's path as well as its result: right tools, no destructive detours, stopping when finished. That showed them which failures to fix first. After a round of fixes, completion was up to 80% and the average was down to 8 steps.
Outcome and process
Outcome asks whether the agent reached the goal: the meeting was booked, the ticket was resolved. It's the cleanest signal, and it can often be checked automatically. Process asks how it got there. Two agents can both succeed while one takes three clean steps and the other takes thirty, including a destructive one. Trajectory evaluation checks whether the agent used the right tools with valid arguments, recovered from errors, avoided unnecessary or dangerous steps and stayed efficient.
What to measure, and why it's hard
Track task success rate, correct tool use, efficiency and robustness to bad inputs. Efficiency includes steps, tokens, time and dollars, and for agents cost and latency count as quality: a correct agent that takes five minutes and $4 per task may still be unshippable. The hardest part is that errors compound:
| Steps | Per-step reliability | End-to-end success |
|---|---|---|
| 1 | 0.95 | 95% |
| 5 | 0.95 | 77% |
| 10 | 0.95 | 60% |
| 20 | 0.95 | 36% |
An agent that's right 95% of the time on each step succeeds only about a third of the time over twenty steps. That's why realistic agent tests need sandbox environments you can reset between runs, and building those environments is a large part of the job.
Score agent runs on outcome and trajectory
You have three recorded runs of the same task. Compute task success, clean-trajectory rate and the compounding projection. One of the runs "succeeds" but shouldn't count. Find it.
Lab code · runs free
RUNS = [ # each step is (tool, succeeded?)
{"steps": [("search", True), ("read", True), ("reply", True)], "resolved": True},
{"steps": [("search", True), ("delete", True),("reply", True)], "resolved": True},
{"steps": [("search", True), ("read", False), ("reply", True)], "resolved": False},
]
ALLOWED = {"search", "read", "reply"}
def outcome(r): return float(r["resolved"])
def trajectory_ok(r): return all(tool in ALLOWED and ok for tool, ok in r["steps"])
success = sum(outcome(r) for r in RUNS) / len(RUNS)
clean = sum(trajectory_ok(r) for r in RUNS) / len(RUNS)
print(f"task success: {success:.0%} clean trajectory: {clean:.0%}")
# errors compound across steps:
for n in (1, 5, 10, 20):
print(f" {n:>2} steps @ 0.95/step -> {0.95**n:.0%} end-to-end")task success: 67% clean trajectory: 33%
1 steps @ 0.95/step -> 95% end-to-end
5 steps @ 0.95/step -> 77% end-to-end
10 steps @ 0.95/step -> 60% end-to-end
20 steps @ 0.95/step -> 36% end-to-endTwo of three runs succeeded, but only one had a clean path. Run 2 reached the goal by calling delete, a tool outside the allowed set, and a success-only metric would have counted it as a win. That gap between finishing and finishing safely is the reason to score trajectories. The compounding table is a reminder that long tasks need very reliable steps, checkpoints, or both.
Remi can now issue refunds itself, so Meridian evaluates it as an agent. On a 200-ticket suite it resolves 82% of tickets. The number that stops the rollout is smaller: 3% of refunds go out for the wrong amount. They only see it because they score the action Remi took along with whether the ticket closed. Refunds over a set amount now need a person to approve them.
Agent evaluation is new enough that nobody has years of experience in it, which makes it a good area to learn early. The compounding table is worth being able to reproduce from memory: 0.95 to the power of the number of steps. It turns an abstract worry into a number in the middle of an interview.
A small but impressive project: take an open-source agent, give it ten tasks with checkable end states, and report both success rate and a trajectory check such as "never called a tool outside the allowed list." Even a tiny, honest version of this is more than most applicants bring.
With a chatbot you judge one answer. With an agent you're judging a sequence of actions, and some of them may move money, send email or delete data. Two things change the risk. An agent can reach the right result by a harmful route, so you need to see how it acted as well as whether it finished. And long tasks fail more often than per-step numbers suggest.
If a team shows you an agent that resolves 80% of support tickets and wants to let it issue refunds, ask for two things first: evidence of how the successful runs behaved, and a human approval step for refunds above a threshold. Ask for cost and time per ticket as well. "80% success" alone isn't enough to hand over the company's money.
Quiz · Chapter 8
- What's the basic unit you evaluate for an agent?
- Two agents both succeed. Why check their trajectories anyway?
- For agents, cost and latency are best treated as:
- "Errors compound" means:
- Realistic agent benchmarks usually need: