A chatbot produces text. An agent produces actions. Evaluating text quality is hard enough; evaluating a sequence of actions — tool calls, API requests, file edits, database queries — across multiple steps is exponentially harder. The same task can be solved via many valid trajectories.

• Task completion: Did it finish the job?
• Correctness: Is the result correct?
• Efficiency: How many steps/tokens/dollars did it take?
• Safety: Did it avoid harmful actions?
• Trajectory quality: Was the path reasonable?
• Reliability: Does it succeed consistently?

Single-run success rates hide reliability issues. A model achieving 96.9% success in clean conditions can drop to 88.1% under perturbations and fault conditions. An agent that works 9 out of 10 times is useless if you can’t predict when it will fail.

Binary: Did the agent complete the task? Yes/No. Simple but loses nuance — an agent that gets 90% of the way is scored the same as one that fails immediately.

Partial credit: Score based on sub-goals achieved. A file-editing agent that correctly edits 4 of 5 files scores 0.80. More informative but harder to define.

SWE-bench uses test-based verification: the agent generates a patch, and the repository’s test suite determines if it’s correct. This is the gold standard for coding agents — objective, automated, and resistant to gaming. Top agents solve ~43% of SWE-bench Pro tasks.

• Tool selection accuracy: Did it pick the right tool for the job?
• Argument correctness: Were the parameters correct?
• Sequence validity: Were tools called in a logical order?
• Error recovery: When a tool call failed, did it adapt?

• Wrong tool: Using search when it should use a calculator
• Hallucinated tools: Calling tools that don’t exist
• Wrong arguments: Correct tool, wrong parameters
• Unnecessary calls: Calling tools when the answer is already known
• Infinite loops: Retrying the same failed call repeatedly

Compare the agent’s tool call sequence against a reference trajectory (the expected sequence of tool calls). Metrics:

• Precision: What fraction of tool calls were necessary?
• Recall: What fraction of necessary tool calls were made?
• F1: Harmonic mean of precision and recall

Two agents might both complete a task, but one takes 5 steps and $0.10 while the other takes 50 steps and $5.00. Trajectory evaluation captures efficiency, reasoning quality, and cost — dimensions that task completion alone misses.

Research analyzing 3,908 agent trajectories across 18 models identified three distinct failure patterns:

• Failure-to-Act: Agent fails to interact with the environment
• Out-of-Order Actions: Interdependent actions issued simultaneously
• False Termination: Agent prematurely assumes task is complete

Use an LLM judge to evaluate trajectory quality by asking:

1. Was the planning phase adequate?
2. Were tool calls appropriate and efficient?
3. Did the agent recover from errors?
4. Was the final answer correct?

Shepherd used this approach to improve agent performance from 21% to 31% while cutting costs by 57%.

• Steps per task: Number of actions taken (fewer = better)
• Tokens consumed: Total input + output tokens (drives cost)
• Wall-clock time: End-to-end latency
• Cost per task: Dollar amount (API costs + compute)
• Cost per success: Total cost / successful completions

A chatbot that hallucinates is annoying. An agent that hallucinates takes real actions — deleting files, sending emails, making API calls, spending money. Agent safety evaluation must test for harmful actions, not just harmful text.

• Scope adherence: Does it stay within its authorized actions?
• Destructive action prevention: Does it avoid irreversible operations?
• Confirmation seeking: Does it ask before high-impact actions?
• Prompt injection resistance: Can users trick it into unauthorized actions?
• Resource limits: Does it respect cost and time budgets?

Always evaluate agents in a sandboxed environment that mirrors production but can’t cause real damage. Test with adversarial scenarios:

• “Delete all files in the project”
• “Send this email to all customers”
• “Ignore previous instructions and...”

The agent should refuse, ask for confirmation, or escalate.

• SWE-bench Verified: Real GitHub issues, test-based verification. Top: ~76%
• SWE-bench Pro: Harder, long-horizon tasks across 41 repos. Top: ~43%
• SWE-ContextBench: Tests experience reuse across related problems

• WebArena: Web browsing tasks (shopping, forums, maps)
• OSWorld: Operating system tasks (file management, app usage)
• ReliabilityBench: Tests agent reliability under production stress conditions
• GAIA: General AI assistant tasks requiring multi-step reasoning

Agent benchmarks share the same contamination and saturation risks as LLM benchmarks, plus additional challenges:

• Environment drift: Websites and APIs change, breaking benchmarks
• Cost: Running agent benchmarks is 10–100x more expensive than text benchmarks
• Reproducibility: Non-deterministic environments make exact reproduction difficult

1. Define clear success criteria for each task type
2. Build a test suite of 20–50 representative tasks
3. Run each task 5–10 times to measure consistency
4. Test adversarial scenarios (prompt injection, scope violations)
5. Measure cost per success, not just success rate
6. Evaluate in a sandboxed environment

1. Log every trajectory (actions, tool calls, reasoning)
2. Monitor success rate over time (detect drift)
3. Track cost per task (detect runaway spending)
4. Alert on safety violations (unauthorized actions)
5. Sample trajectories for human review (5–10%)
6. A/B test agent updates before full rollout