AI Agent Reliability Is Not One Score: A Practical Scorecard

An agent can improve average task success while creating a rare safety failure. It can answer correctly but violate a routing rule, call the wrong tool, or take long enough that the user abandons the workflow. Combining those outcomes too early makes a clean dashboard and a weak decision.

Treat reliability as a vector: R = [outcome, behavior, safety, latency, recovery]. Add tool and evaluator metrics when they affect the workflow. NIST's 2026 post-deployment monitoring report separates functionality, operations, human factors, security, compliance, and broader impacts, while noting that monitoring methods remain use-case-specific and immature. There is no official universal agent score waiting to be adopted.

Start with the failure costs and decisions for one workflow. The formulas below are a practical operator template, not an industry standard. A metric is useful only when its event, denominator, cohort, window, version, and gate are explicit.

Most reliability arguments are denominator arguments in disguise. Suppose an agent receives 1,000 conversations. Of those, 120 are spam, 80 lose an upstream tool before the agent can act, and 100 have no observable business outcome. The agent succeeds in 640 of the 700 attempts your policy calls eligible and observable.

Reporting 640 successes as 64 percent of all received traffic or 91.4 percent of eligible observable attempts can both be defensible if the policy is declared. Reporting 100 percent by retaining only the 640 observed successes cannot. Every exclusion needs a reason and a count.

A missing metric must stay missing. Turning it into zero can manufacture either a pass or a failure, depending on whether lower or higher is better. Use explicit states in the scorecard and block any claim that requires evidence you do not have.

The labels below are an operator convention, not a formal standard. What matters is that the system, reviewer, and decision rule can distinguish no event from no measurement.

Precision and recall describe the measurement instrument, not the agent. Precision asks how often a flagged failure is real. Recall asks how many real failures the evaluator catches. A judge with weak recall can make an unreliable agent look clean; weak precision can flood reviewers with false alarms.

Google's classification guidance shows why accuracy can be misleading on imbalanced data and why metric choice should follow the cost of false positives and false negatives. Calibrate each material detector against a reviewed cohort, preserve its threshold and version, and report unresolved denominator-zero cases as missing rather than silently assigning a perfect value.

Absolute scores show how one version performed on one cohort. A release decision usually asks a different question: did the challenger improve the same cases? Run the baseline and challenger against the same persona, scenario, starting state, and tool conditions, then calculate d_i = score(challenger_i) − score(baseline_i) for each valid pair.

Report the valid-pair count, mean paired lift, wins, ties, losses, uncertainty, and protected-scenario regressions. Do not subtract averages from unrelated test mixes. Converra's testing workflow uses the same personas and scenarios for baseline-versus-challenger comparison; the companion sample-size guide explains why pair count, variance, effect size, and coverage belong in one plan.

OpenTelemetry recommends operation-duration metrics with contextual error types so teams can derive throughput and error rates. Its current GenAI semantic conventions also define operation-duration and token-usage metrics. Those are valuable operational signals, but low latency and zero technical errors do not establish that the agent achieved the user's goal or followed the right rule.

Keep operational telemetry beside behavioral evidence. Neither layer replaces the other.

A tool timeout, ambiguous request, missing permission, or downstream rejection does not have to become a failed user outcome. Define recoverable episodes before looking at their outcomes. Then record detection, bounded retry, clarification or escalation, final outcome, added latency and cost, and any new safety issue.

Recovery rate = successful recoveries / recoverable failure episodes. Pair it with a retry-cost ceiling and a loop detector. An agent that eventually succeeds after ten uncontrolled retries did not recover reliably.

If an executive view needs one composite, define composite = sum(weight_k × normalized_metric_k). Publish who owns the weights, why they exist, how lower-is-better metrics are normalized, and which versions and cohorts they apply to. Keep every component visible next to the total.

Apply safety, policy, and other hard gates before the composite. Never impute a favorable value for an unobserved dimension. Strong latency, sentiment, or task completion must not average away a critical failure.

Pre-deployment metrics can select and protect a candidate under tested conditions. After deployment, measure the same defined production outcome on fresh traffic with preserved version identity. Account for prompt, model, routing, traffic, tool, and evaluator changes that can confound the comparison.

The production result may be verified, not fixed, or confounded. A green simulation suite or approved pull request proves only that the candidate cleared those gates. It does not prove that real behavior improved.