Evaluating And Operating Agents
Evaluating Agents
search ──► search ──► search ──► list_all_orders
JrCodex·7 min read
Jr Codex Agentic AI Notes
Level: Advanced Prerequisites: Module 6, Chapter 5; Gen AI Notes, Module 5 Time to complete: ~25 minutes
Table of Contents
- Why the Endpoint Is Not Enough
- Outcome Metrics
- Trajectory Metrics
- Efficiency and Safety Metrics
- RAGAS for Retrieval-Backed Agents
- Benchmarks and Their Limits
- The Scorecard
- Summary & Next Steps
1. Why the Endpoint Is Not Enough
Two Runs, Same Answer
─────────────────────────────────────────
RUN A
get_customer ──► list_orders ──► answer
3 steps, 1,800 tokens, 2.1s, $0.004
RUN B
search ──► search ──► search ──► list_all_orders
──► filter ──► search ──► get_customer ──►
delete_draft ──► answer
9 steps, 24,000 tokens, 18s, $0.11
...and it called a destructive tool it did not
need.
Outcome-only evaluation scores these IDENTICALLY.
─────────────────────────────────────────
What Endpoint Scoring Hides
─────────────────────────────────────────
- 27x the cost
- 9x the latency
- an unnecessary destructive action
- a path that got the right answer by luck and
will not generalise
An agent is a PROCESS. Evaluating only its output
is like reviewing code by running it once.
─────────────────────────────────────────
2. Outcome Metrics
Start here — these are necessary, just not sufficient.
The Four
─────────────────────────────────────────
TASK COMPLETION did it accomplish the goal?
Binary, judged EXTERNALLY —
never ask the agent (Module 2,
Chapter 1).
CORRECTNESS is the answer right? Needs
ground truth, so build cases
where you know it (Chapter 2).
GROUNDEDNESS is every claim supported by a
tool result in this run? The
agentic version of hallucination
detection.
COMPLETENESS did it address the WHOLE
request, not the easy part?
Catches Module 4's premature
completion.
─────────────────────────────────────────
def score_outcome(run, case) -> dict:
return {
"completed": case.completion_check(run.final_answer, run.state),
"correct": case.expected is None or matches(run.final_answer, case.expected),
"grounded": all(claim_supported(c, run.tool_results)
for c in extract_claims(run.final_answer)),
"complete": all(req in run.final_answer for req in case.required_elements),
}3. Trajectory Metrics
The ones that separate a good agent from a lucky one.
The Five
─────────────────────────────────────────
TOOL SELECTION what fraction of calls were
ACCURACY the right tool for the moment?
STEP EFFICIENCY actual steps ÷ minimum
necessary steps. 1.0 is
optimal; above ~2.5 means
wandering.
REDUNDANT CALL identical or near-identical
RATE calls. Directly measures
Module 4's loop pathology.
RECOVERY RATE when a tool failed, how often
did the agent recover rather
than loop or give up? This is
the single best predictor of
production robustness.
PLAN ADHERENCE for planning agents, what
fraction of planned steps were
executed?
─────────────────────────────────────────
def score_trajectory(run, case) -> dict:
calls = run.tool_calls
keys = [(c.name, canonical(c.args)) for c in calls]
failures = [i for i, c in enumerate(calls) if c.failed]
recovered = sum(1 for i in failures
if i + 1 < len(calls) and keys[i + 1] != keys[i]) # tried something ELSE
return {
"tool_accuracy": sum(c.name in case.appropriate_tools_at(i)
for i, c in enumerate(calls)) / max(len(calls), 1),
"step_efficiency": case.min_steps / max(len(calls), 1),
"redundancy": 1 - len(set(keys)) / max(len(keys), 1),
"recovery_rate": recovered / len(failures) if failures else None,
"plan_adherence": executed_fraction(run.plan) if run.plan else None,
}Why Recovery Rate Matters Most
─────────────────────────────────────────
Tools fail in production. Constantly. Networks
time out, records are missing, permissions are
wrong.
An agent with 95% task completion in a clean test
environment and a 20% recovery rate will perform
badly in production. One with 85% completion and
an 80% recovery rate will perform well.
Deliberately inject tool failures into your eval
set (Chapter 2) to measure this at all.
─────────────────────────────────────────
4. Efficiency and Safety Metrics
EFFICIENCY — track per run, report percentiles
─────────────────────────────────────────
total tokens, total cost
wall-clock latency, p50 and p95
number of LLM calls
cost per SUCCESSFUL task
── the honest denominator: failed runs still
cost money, so divide total spend by
SUCCESSES, not by runs
SAFETY — these are pass/fail, not averages
─────────────────────────────────────────
UNAUTHORISED ACTIONS destructive tools called
without approval. Target:
ZERO. Any occurrence is a
release blocker.
SCOPE VIOLATIONS tools called outside the
task's remit.
INJECTION SUSCEPT- did adversarial content in
IBILITY a tool result change
behaviour? (Module 8, Ch.1)
BUDGET BREACHES runs hitting the hard
ceiling — a high rate means
the bounds or the tasks are
wrong.
─────────────────────────────────────────
The Rule for Safety Metrics
─────────────────────────────────────────
Never average them. "99.7% of runs took no
unauthorised action" describes a system that
deleted something it should not have.
Report the COUNT, and investigate every one.
─────────────────────────────────────────
5. RAGAS for Retrieval-Backed Agents
For agents that retrieve, RAGAS supplies established metrics that decompose the pipeline.
from ragas import evaluate
from ragas.metrics import (faithfulness, answer_relevancy,
context_precision, context_recall)
dataset = {
"question": [c.question for c in cases],
"answer": [r.final_answer for r in runs],
"contexts": [r.retrieved_chunks for r in runs], # what the agent actually saw
"ground_truth": [c.expected for c in cases],
}
print(evaluate(dataset, metrics=[faithfulness, answer_relevancy,
context_precision, context_recall]))Reading the Four Together
─────────────────────────────────────────
FAITHFULNESS is the answer supported by the
retrieved context?
LOW ──► the model is inventing.
ANSWER RELEVANCY does the answer address the
question?
LOW ──► it drifted off-task.
CONTEXT PRECISION is the retrieved context mostly
relevant?
LOW ──► retrieval is noisy;
wasted budget.
CONTEXT RECALL did retrieval find everything
needed?
LOW ──► the answer CANNOT be
complete, whatever the model
does.
Low recall with high faithfulness means your
RETRIEVAL is the problem and no prompt change will
help. That diagnosis is the value of splitting
them.
─────────────────────────────────────────
6. Benchmarks and Their Limits
The Public Benchmarks
─────────────────────────────────────────
AgentBench multi-environment agent tasks —
OS, database, web, games
WebArena realistic web navigation
SWE-bench resolving real GitHub issues
GAIA multi-step reasoning with tools
τ-bench tool use in customer-service
settings with policy rules
─────────────────────────────────────────
What They Are Good For
─────────────────────────────────────────
✓ comparing MODELS as agent backbones
✓ tracking whether the field is improving
✓ sanity-checking that your setup is not broken
✗ predicting performance on YOUR task
✗ justifying an architecture choice
✗ anything you would report to a customer
The Reason
─────────────────────────────────────────
Benchmarks use their own tools, their own
environments and their own success criteria. Your
agent's quality is dominated by YOUR tool
descriptions, YOUR context management and YOUR
domain.
A model that tops AgentBench may perform worse on
your task than one that ranks lower. Use
benchmarks to pick a starting model; use your own
eval set to decide anything.
─────────────────────────────────────────
7. The Scorecard
What to Report, Per Release
─────────────────────────────────────────
OUTCOME
task completion % ▲ higher better
correctness % ▲
groundedness % ▲
TRAJECTORY
tool selection accuracy ▲
step efficiency ▲ (1.0 is optimal)
redundant call rate ▼ lower better
recovery rate ▲
EFFICIENCY
cost per SUCCESSFUL task ▼
p95 latency ▼
SAFETY
unauthorised actions = 0, absolute
injection successes = 0, absolute
─────────────────────────────────────────
How to Read It as a Whole
─────────────────────────────────────────
Completion up and step efficiency DOWN means you
bought success with brute force — it will not hold
as tasks get harder, and the bill will show it.
Completion flat and redundancy down is a real
improvement even though the headline number did
not move.
Any safety count above zero outranks every other
column.
─────────────────────────────────────────
8. Summary & Next Steps
Key Takeaways
- Two runs reaching the same answer can differ 27x in cost and take an unnecessary destructive action — outcome-only scoring treats them as identical.
- Trajectory metrics separate good agents from lucky ones, and recovery rate is the strongest single predictor of production robustness.
- Safety metrics are counts, never averages: any unauthorised action is a release blocker, not a percentage.
- Public benchmarks compare model backbones but do not predict performance on your task, because your tools and context dominate.
Concept Check
- Give two things a correct final answer can conceal about how the agent got there.
- Why is cost per successful task the honest denominator rather than cost per run?
- RAGAS shows high faithfulness and low context recall. What is broken, and why will prompt changes not fix it?
Next Chapter
→ Chapter 2: Building an Agent Eval Set
Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index | Back to Agentic AI Index