Evaluating AI Agents: Beyond Task Completion

The rise of AI agents -- systems that use LLMs to plan, execute multi-step tasks, use tools, and interact with environments -- has exposed a fundamental gap in how we evaluate AI. Traditional benchmarks were designed for stateless, single-turn interactions: give a model a prompt, get a response, score it. Agents operate in a fundamentally different paradigm, and evaluating them requires fundamentally different approaches.

Task completion rate -- "did the agent accomplish the goal?" -- is the most common agent evaluation metric, and it is dangerously insufficient. An agent that completes a task by making 47 API calls, crashing twice, and spending $3.50 in compute is not equivalent to an agent that completes the same task in 4 clean API calls for$0.02. An agent that completes 80% of tasks but fails catastrophically (deleting files, sending incorrect emails) on the remaining 20% may be worse than an agent that completes 60% but fails gracefully on the rest.

This article lays out a framework for multi-dimensional agent evaluation that captures what actually matters.

Why Agent Evaluation Is Different#

Three properties of agents make traditional evaluation approaches inadequate:

1. Non-Determinism and Path Dependence#

Agents make sequences of decisions, and each decision shapes the available future decisions. The same agent given the same task may take different paths on different runs due to LLM sampling, timing of API responses, or state changes in the environment. This means:

• Single-run evaluation is unreliable. You need multiple runs per task to estimate performance.
• Variance is itself a metric. An agent that succeeds 9/10 times reliably is different from one that succeeds 9/10 but with high variance in how it succeeds.
• Evaluation cost scales multiplicatively. N tasks times M runs per task times the cost of each run adds up fast.

2. Process Matters, Not Just Outcome#

Two agents can both complete a task while exhibiting radically different behavior quality:

If you only measure task completion, these agents score identically. In practice, Agent A is dramatically better.

3. Failure Modes Are Critical#

For agents that operate in real environments (file systems, APIs, databases, user-facing systems), the type of failure matters enormously:

• Graceful failure: Agent recognizes it cannot complete the task, reports what it tried, and stops. Low cost, no side effects.
• Partial completion: Agent completes part of the task, clearly reports what was and was not accomplished. Potentially useful.
• Silent failure: Agent reports success but did not actually complete the task. Dangerous.
• Catastrophic failure: Agent takes harmful actions -- deletes data, makes unauthorized changes, sends incorrect communications. Unacceptable.

An evaluation that does not distinguish between these failure modes is incomplete at best and irresponsible at worst.

Key Dimensions for Agent Evaluation#

We propose evaluating agents across six dimensions. No single score can capture agent quality; a profile across these dimensions is necessary.

Dimension 1: Task Completion (Outcome Quality)#

The baseline metric, but applied with nuance:

• Full completion rate: Percentage of tasks fully completed to specification
• Partial completion scoring: Credit for meaningful partial progress (requires task-specific rubrics)
• Consistency: Variance across multiple runs of the same task (report confidence intervals, not just means)

Dimension 2: Tool Use Accuracy#

Agents interact with tools (APIs, file systems, databases, web browsers). Tool use quality includes:

• Call correctness: Were tool calls made with valid parameters?
• Call necessity: Were unnecessary calls made? (Measures planning efficiency)
• Error handling: When a tool call fails, does the agent adapt appropriately?
• Sequencing: Were tools called in a logical, efficient order?

Example metric: Tool Use Efficiency Score

efficiency = correct_and_necessary_calls / total_calls

A score of 1.0 means every tool call was both correct and necessary.
A score of 0.5 means half the tool calls were either incorrect or unnecessary.

Dimension 3: Planning Quality#

How well does the agent decompose complex tasks and sequence its actions?

• Plan coherence: Does the agent's approach make logical sense for the task?
• Adaptivity: Does the agent update its plan when encountering unexpected results?
• Decomposition depth: Does the agent break complex tasks into appropriate subtasks?
• Dead-end avoidance: How often does the agent pursue approaches that cannot possibly work?

Evaluating planning quality typically requires human review of agent traces or LLM-as-judge applied to the action sequence (not just the final output).

Dimension 4: Error Recovery#

When things go wrong -- and they always do -- how does the agent respond?

• Detection rate: Does the agent recognize when an action has failed or produced unexpected results?
• Recovery success rate: When an error is detected, how often does the agent successfully recover?
• Recovery efficiency: How many additional steps does recovery require?
• Escalation appropriateness: Does the agent know when to stop and ask for help vs. when to retry?

Dimension 5: Cost Efficiency#

Agent runs consume real resources -- tokens, API calls, compute time, and sometimes money (for paid tool APIs). Cost efficiency includes:

• Token usage: Total input + output tokens per task
• API call count: Number of external tool/API calls
• Wall-clock time: End-to-end time to completion
• Dollar cost: Actual monetary cost of the run

Report cost metrics alongside completion metrics. A model that completes 5% more tasks at 10x the cost may not be the better choice for production deployment.

Dimension 6: Safety and Side Effects#

The most critical dimension for production agents:

• Boundary adherence: Does the agent stay within its authorized scope?
• Reversibility: Are the agent's actions reversible if something goes wrong?
• Information leakage: Does the agent expose sensitive information in logs, tool calls, or outputs?
• Environment cleanliness: Does the agent clean up after itself (close connections, remove temporary files)?

Process vs. Outcome Evaluation#

A key methodological choice is whether to evaluate the agent's process (the sequence of actions taken) or its outcome (the final result). Both matter, but they answer different questions.

Outcome evaluation answers: "Did the agent produce the right result?"

• Easier to automate (compare final state to expected state)
• Misses important behavioral differences between agents
• Sufficient for simple, well-defined tasks

Process evaluation answers: "Did the agent behave competently?"

• Requires reviewing action traces, which is expensive
• Captures efficiency, safety, and robustness
• Essential for complex tasks and production deployment decisions

The strongest evaluations combine both: automated outcome checks provide scale, while sampled process reviews (human or LLM-as-judge) provide depth.

The Reproducibility Challenge#

Agent evaluation has a reproducibility problem that is worse than standard LLM evaluation:

1. Environment state changes. If agents interact with real services (web APIs, databases), the environment may change between evaluation runs. A web scraping agent evaluated today may face different content tomorrow.

2. Non-deterministic execution. Even with temperature=0, agents make sequential decisions where small variations compound. Two runs of the same agent on the same task may take very different paths.

3. Evaluation infrastructure complexity. Agent evaluations require sandboxed environments, tool mocks or real integrations, state reset mechanisms, and trace logging. Each of these is a potential source of variation.

Practical mitigation strategies:

• Snapshot environments where possible. Use Docker containers, database snapshots, and recorded API responses to create reproducible starting states.
• Run multiple trials (minimum 3, ideally 5-10) per task per agent and report distributions, not point estimates.
• Version everything: the agent code, the evaluation harness, the environment configuration, and the tool versions.
• Separate deterministic from stochastic evaluation. Some checks (e.g., "did the agent call the right API endpoint?") can be evaluated deterministically from traces, even if the overall task outcome varies.

A Practical Evaluation Framework#

For teams building or selecting AI agents, here is a minimum viable evaluation framework:

Step 1: Define Task Suites by Complexity#

Level 1: Single-tool, single-step tasks
  (e.g., "Look up the current price of AAPL stock")

Level 2: Single-tool, multi-step tasks
  (e.g., "Find all files modified in the last week and summarize changes")

Level 3: Multi-tool, multi-step tasks
  (e.g., "Research competitor pricing, create a comparison spreadsheet,
   and draft a summary email")

Level 4: Open-ended tasks with ambiguity
  (e.g., "Improve the performance of this API endpoint")

Step 2: Run and Collect Traces#

For each task, capture:

• Complete action trace (every tool call, every LLM generation)
• Timing information for each step
• Token counts per step
• Final environment state
• Any errors encountered and how they were handled

Step 3: Score Across Dimensions#

Apply automated scoring where possible (outcome checks, cost metrics, tool call analysis) and sampled human/LLM review where necessary (planning quality, process evaluation).

Step 4: Report Multi-Dimensional Profiles#

Do not collapse scores into a single number. Report a profile:

Agent: CodeAssistant v2.1
Task Suite: Software Engineering (Level 3)
Runs per task: 5

Task Completion:    82% (+/- 6%)
Tool Use Accuracy:  91%
Planning Quality:   B+ (human-rated sample)
Error Recovery:     73% successful recovery
Median Cost:        $0.12 per task
Safety Incidents:   0 in 200 runs

This profile gives a decision-maker far more useful information than "82% task completion rate" alone.

Looking Forward#

Agent evaluation is still in its early stages, and many open problems remain:

• Long-horizon evaluation: How do you evaluate agents on tasks that take hours or days?
• Multi-agent evaluation: How do you assess systems where multiple agents collaborate?
• Continuous learning: How do you evaluate agents that improve over time through experience?
• User interaction quality: For agents that work with humans in the loop, how do you assess the quality of their communication and collaboration?

These are hard problems, and solving them will require the evaluation community to move well beyond the benchmark paradigms designed for single-turn language models. The framework presented here is a starting point -- a minimum standard for taking agent evaluation seriously.

The field cannot afford to reduce agent quality to a single task completion number. The stakes are too high, and the behavior space is too complex. Multi-dimensional evaluation is not a luxury; it is a necessity.