AI Agent Evaluation Metrics: What to Measure and Why

Correctness Metrics

Correctness is the foundation metric that everything else builds on. An agent that is fast, cheap, and safe but produces wrong answers has no value. The challenge is that correctness means different things depending on the task type, and the measurement approach must match.

Task completion rate measures the percentage of requests where the agent produces a final answer at all, without crashing, timing out, or entering an infinite loop. This is the most basic correctness metric and should be at or near 100% for production agents. A task completion rate below 95% indicates fundamental reliability problems that must be fixed before fine-grained quality metrics become meaningful. Track this by task category, because an agent might complete 99% of simple queries but only 70% of complex multi-step tasks.

Factual accuracy measures whether the claims in the agent's output are verifiable and true. For agents that retrieve information (RAG agents, research agents, data lookup agents), factual accuracy is the primary quality metric. Measure it by having a judge (human or LLM) verify each factual claim against source documents or known ground truth. Express it as the percentage of claims that are correct, not just whether the overall answer is acceptable. An answer with ten facts where two are wrong has 80% factual accuracy, and that matters even if the overall answer passes a holistic quality check.

Instruction following measures whether the agent did what was asked rather than something adjacent. A user who asks for a three-paragraph summary and receives a five-paragraph essay has an agent with poor instruction following even if the content quality is high. Measure instruction following by decomposing the request into concrete requirements (format, length, tone, specific inclusions or exclusions) and checking each one independently. This decomposition also makes it easier to identify which types of instructions your agent consistently fails to follow.

Output format compliance matters for agents that produce structured output like JSON, SQL queries, code, or formatted reports. Measure it with schema validation for JSON outputs, syntax checking for code, and template matching for formatted text. Format compliance should be near 100% because downstream systems that consume structured agent outputs will break on malformed data. A 2% format failure rate sounds small until you realize it means two out of every hundred API calls return unusable results.

Semantic correctness handles cases where the exact wording does not matter but the meaning must be right. For open-ended generation tasks (writing emails, creating summaries, answering questions), semantic correctness is measured through embedding similarity to reference answers, through LLM-judge scoring against rubrics, or through human evaluation. The key is establishing a clear rubric that defines what constitutes correct versus incorrect versus partially correct, and validating that your automated scoring method agrees with human judgment on a calibration set.

Efficiency Metrics

Efficiency metrics reveal whether the agent is solving problems elegantly or brute-forcing its way through them. Two agents with identical correctness scores can differ dramatically in efficiency, which directly impacts cost, latency, and scalability.

Steps to completion counts the total number of LLM calls and tool invocations required to finish a task. An agent that needs twelve steps to answer a question that could be answered in three is wasting resources and introducing unnecessary failure points at each step. Track the distribution, not just the average, because you want to identify the outlier cases where step count explodes. A reasonable baseline for most single-turn agent tasks is three to seven steps; anything above fifteen warrants investigation.

Token consumption measures total input and output tokens across all LLM calls in a task. Input tokens accumulate from system prompts, conversation history, tool responses, and few-shot examples. Output tokens come from the model's reasoning and responses. Track both separately because they are priced differently and optimized differently. High input token usage often indicates that the agent is stuffing too much context into each call; high output token usage may indicate verbose reasoning that could be condensed with better prompting.

Tool call precision measures what fraction of tool calls actually contributed useful information to the final answer. An agent that calls five tools but only uses results from two has 40% tool call precision. The remaining three calls wasted time, tokens, and possibly rate limit budget. Low tool call precision usually indicates that the agent is exploring rather than planning, calling tools speculatively rather than reasoning about which tool would provide the needed information before calling it.

Latency breakdown decomposes total response time into its components: time spent in LLM inference, time spent waiting for tool responses, and time spent in framework overhead (parsing, routing, context assembly). This breakdown identifies where optimization effort should focus. An agent with three seconds of LLM inference and twelve seconds of tool wait time needs faster tools or parallel tool execution, not a faster model.

Retry rate measures how often the agent needs to retry a step due to failures, invalid outputs, or self-correction. A high retry rate on tool calls indicates either unreliable tools or poor argument formatting. A high retry rate on LLM calls indicates that the model frequently produces outputs that fail validation, which usually means the prompt or output schema needs refinement.

Safety Metrics

Safety metrics ensure the agent operates within its intended boundaries, which is especially critical for agents exposed to public users, agents with access to sensitive data, or agents authorized to take real-world actions.

Refusal accuracy measures whether the agent correctly refuses requests that fall outside its intended scope. This has two components: true positive refusals (correctly refusing harmful or out-of-scope requests) and false positive refusals (incorrectly refusing legitimate requests). Both matter. An agent that refuses everything is safe but useless; an agent that never refuses is capable but dangerous. Measure refusal accuracy on a test set that includes both clearly in-scope requests and clearly out-of-scope requests, plus ambiguous borderline cases.

Information leakage rate measures whether the agent ever reveals internal system prompts, tool configurations, other users' data, or system architecture details in its responses. Test this with adversarial prompts that attempt to extract hidden information through jailbreaks, prompt injection, or social engineering. Even a single instance of information leakage in production is a security incident, so the target rate is zero and any non-zero measurement requires immediate remediation.

Boundary compliance measures whether the agent stays within its authorized capabilities. An agent configured to only read data should never attempt write operations. An agent scoped to one database should never query another. An agent with a spending limit should never authorize transactions above that limit. Measure boundary compliance by monitoring tool call arguments and flagging any attempt to exceed configured limits, even if the attempt is blocked by downstream validation.

Hallucination rate specifically measures how often the agent presents fabricated information as fact. This differs from factual accuracy because it focuses on cases where the agent generates content without any basis in its retrieved context or training data, versus cases where it misinterprets real data. Track hallucination rate separately from general accuracy because the remediation strategies are different: reducing hallucination typically requires better grounding in retrieved context, while improving accuracy may require better tools or more capable models.

Cost Metrics

Cost metrics translate efficiency measurements into financial terms and enable operational decision-making about model selection, feature tradeoffs, and scaling capacity.

Cost per task is the total dollar cost of one agent execution, including all LLM inference costs (input tokens, output tokens, reasoning tokens if applicable), tool API costs, and compute infrastructure costs. Track the mean, median, 95th percentile, and maximum. The maximum matters because a single runaway task that enters a retry loop can generate hundreds of dollars in API costs before timing out.

Cost per successful task divides total costs by only the tasks that completed successfully, factoring in the cost of failures. If your agent has a 90% success rate and costs $0.50 per task attempt, your cost per successful task is $0.55 ($5.00 spent on ten attempts, nine of which succeed). This metric reveals the true cost of unreliability.

Cost efficiency ratio measures the relationship between spending and quality. Calculate it as quality score divided by cost. When comparing model options or prompt strategies, this ratio identifies the sweet spot where you get the most quality per dollar rather than simply maximizing quality regardless of cost.

Cost trend analysis tracks how per-task costs change over time. Costs should generally decrease as you optimize prompts, reduce unnecessary tool calls, and implement caching. If costs are rising without corresponding quality improvements, something is degrading: perhaps a prompt change introduced more verbose reasoning, or a tool became slower and triggered more retries, or context windows are growing without pruning.

User Satisfaction Metrics

User satisfaction is the ultimate validation of all other metrics because it measures whether the agent actually delivers value to the people who use it.

Acceptance rate measures how often users accept the agent's output without modification. For code generation agents, this is whether the user commits the generated code as-is versus editing it. For research agents, this is whether the user uses the summary versus doing their own research. For customer service agents, this is whether the user's problem was resolved without escalation. High acceptance rates correlate with high automated quality scores, but the correlation is imperfect because users have preferences that automated metrics do not capture.

Follow-up rate measures how often users need to send additional messages to get a satisfactory response. An agent that requires three rounds of clarification to complete a task has a fundamentally different user experience than one that completes the task on the first try, even if both eventually produce correct outputs. Track the average number of user messages per resolved task and the distribution of conversation lengths.

Explicit feedback scores come from thumbs-up/thumbs-down buttons, star ratings, or satisfaction surveys that users voluntarily complete. These signals are sparse (most users do not provide explicit feedback) and biased (dissatisfied users are more likely to rate), but they provide ground truth that no automated metric can replace. Use explicit feedback to calibrate your automated metrics: if your automated quality scores are high but user feedback is negative, your metrics are measuring the wrong things.