An agent that is right most of the time and unpredictable about when is not reliable — it is correct on average, which is a different and much weaker property. Reliability is about the distribution, not the mean: whether the same request gets the same quality of answer, whether failures are recoverable, and whether you can state a bound anyone would bet on.
Two agents both score 90%. One fails on a predictable class of input. The other fails at random. These are not the same product.
The first agent is manageable: characterise the failing class, route it to a human, and ship the rest with a known boundary. The second cannot be shipped responsibly at all, because there is no rule that describes when to trust it. A single accuracy number cannot distinguish them, which is why accuracy is a poor primary metric for anything that runs unattended.
This is the same reason software reliability engineering does not report "the service worked 99% of the time" and stop there. It reports which requests, in what conditions, with what recovery behaviour, and what happens at the tail. Agents need the same treatment, and mostly do not get it — the field standardised on a single quality score early, and the vocabulary has not caught up.
These are separated because they break separately, and because the remedy for each is different. An agent can be perfectly grounded and hopelessly inconsistent; it can recover beautifully from tool errors and quietly omit half of what was asked. Averaging them into one figure destroys exactly the information you would act on.
Did the run produce the right outcome. The property everyone measures, and the only one most teams measure. Necessary, insufficient, and — measured alone — actively misleading, because it says nothing about the six below.
Run the same task n times. How often does the quality change? Passing sometimes is a different result from passing, and single-shot evaluation cannot see the difference. This is the property that most often collapses on contact with production.
What the request required that the output never addressed. Omission is silent by construction: nothing in a fluent, confident, incomplete answer signals what is missing from it.
Is each claim supported by something the agent actually retrieved on that run. An agent can be correct and ungrounded — right by luck or by memorised training data — and that run will fail the next time the fact changes.
Four questions, not one: was the tool permitted, was it the right tool, were the arguments correct, and was the result interpreted correctly. Most tool failures are argument failures, and a single "tool success rate" hides them completely.
When a step fails, what happens next. Does it retry sensibly, escalate, degrade gracefully — or loop, silently swallow the error, and proceed on a false premise. Recovery behaviour is what separates a robust agent from a lucky one, and it is invisible until something breaks.
Variance in tokens, latency, and tool calls for comparable work. An agent that usually costs four calls and occasionally costs sixty has a reliability problem expressed in dollars, and it is usually the first symptom of a loop nobody has noticed.
Because the remedies differ. Inconsistency is a sampling or prompt problem. Poor recovery is an orchestration problem. Ungroundedness is a retrieval problem. A composite score tells you something is wrong and gives you nowhere to go.
The single biggest gap between how agents are evaluated and how they behave: almost every evaluation runs each case once. A model with non-zero temperature, a retrieval layer whose index moves, and an agent that plans its own path together guarantee that one run is a sample, not a measurement.
Running each case n times changes what you can say:
The cost objection is real and mostly solvable: repeat a stratified sample rather than the whole suite, and repeat more heavily around cases that have failed before. You do not need n = 5 on everything to learn where the variance lives.
Borrowing SLOs from service reliability is the right instinct and it needs one adjustment. A conventional SLO covers properties the service fully controls — availability, latency, error rate. An agent's correctness is not such a property: it depends on the request, the corpus, and a model you do not control and did not train.
So split the objectives by what is actually controllable:
The mechanism worth keeping is the error budget: state the tolerance in advance, measure against it continuously, and let exhausting it trigger a defined response rather than a debate. That works for agents precisely because the argument happens once, when the budget is written — which is the same reason evaluation criteria belong in a contract rather than in a reviewer's head.
These seven properties are what evaluation produces and what continuous evaluation keeps producing after launch. They are inputs. None of them decides anything on its own — someone still has to look at seven honest numbers and their failure cases and say whether that is acceptable for this use, at this scope, with this blast radius.
That decision, and the evidence organised so a reviewer can check rather than trust it, is clearance.
Agent TrustKit scores these from the OpenTelemetry you already emit, with the evidence attached.
Book a call →[email protected]