Written by Cyprian Aarons, founder and principal engineer at Topiax.
Reviewed September 14, 2026 by Cyprian Aarons
About the authorThe conversation I keep having with teams shipping AI:
βIt worked when I tested it.β
I hear a version of this 3 times a week from developers in my network.
And honestly⦠I get it.
The model answered the test prompt.
The benchmark score looked good.
The demo felt smooth.
Then production added 10,000 users, real tools, concurrency, latency, retries, and a bill nobody had modelled.
Academic benchmarks can tell you what a model can do.
They do not tell you whether the agent you built will survive contact with the system around it.
Benchmarks measure capability.
Production evals measure reliability.
The Benchmark Trap π―
A benchmark usually gives the model a controlled task and checks the answer.
Your product looks more like this:
User input
β Router
β Model
β Retrieval
β Tool call
β Database or API
β State update
β User-facing result
Every arrow can change the outcome.
The final answer can be correct while the tool parameters are wrong.
The tool can succeed while the result is misinterpreted.
The average latency can look fine while P99 users wait through a timeout.
The token cost can look low while retries make each successful task expensive.
A passing model is not a passing product.
What should you evaluate?
The system you actually built β with its real tools, real data, real users, and real failure paths.
Benchmark capability compared with production reliability
10 Metrics That Actually Matter π§
1οΈβ£ Accuracy π―
Start with the obvious question:
Did the system produce the correct result?
Necessary.
Insufficient.
Accuracy needs a task-specific pass condition.
βThe answer sounded rightβ is not a pass condition for a payment, a customer record, or a deployment.
Define the expected outcome at the business boundary:
- Exact match β did it return the right value?
- Partial credit β which fields or steps were correct?
- Outcome β did the userβs task actually finish?
- Severity β is this a harmless wording issue or a destructive action?
One overall accuracy number hides the failures that cost you.
Track the score by workflow, input type, model route, and consequence.
2οΈβ£ Faithfulness π
Can important claims be traced back to evidence?
Fluent is not grounded.
An agent can produce a beautifully written answer that cites the wrong document, invents a policy, or quietly combines 2 unrelated records.
For retrieval and summarization tasks, evaluate:
- Evidence selection β did it retrieve the right source?
- Claim support β does each important claim follow from that source?
- Coverage β did it omit the evidence that would change the decision?
- Attribution β can a reviewer locate the supporting passage?
TopiaX mascot tracing an AI claim back to source evidence
The test is not βdid the response contain citations?β
The test is whether the citations support the claims that matter.
3οΈβ£ Tool-Call Success π οΈ
Do not collapse tool performance into one green check.
Measure 4 separate stages:
- Tool selection β did the agent choose the right capability?
- Parameter accuracy β were the arguments valid and correctly scoped?
- Execution success β did the tool complete without an error or timeout?
- Result interpretation β did the agent understand what came back?
Tool-call evaluation funnel from selection to useful result
Each stage produces a different fix.
Wrong tool selection needs routing or descriptions.
Wrong parameters need schemas, validation, or better state.
Execution failures need service and retry work.
Wrong interpretation needs output contracts and evaluation cases.
βThe tool returned 200β is not task success.
4οΈβ£ Tool Calls Under Concurrency π¦
The single-user test is the easiest possible environment.
Run the same evaluation at:
| Load | What it reveals |
|---|---|
| 1 user | Basic correctness and a clean dependency path |
| 100 users | Queue behaviour, rate limits, and connection pressure |
| 1,000 users | Pool exhaustion, state mixing, tail latency, and saturation |
Concurrency exposes bugs a benchmark cannot see.
Requests share queues.
Database pools fill.
Rate limits fire.
One userβs state can appear in another userβs result if the boundary is wrong.
TopiaX mascot monitoring a production evaluation queue under concurrent load
Do not report βtool success: 98%β without the load condition.
98% at 1 user and 72% at 1,000 users are 2 different products.
5οΈβ£ Latency Under Load β±οΈ
Track P50, P95, and P99 β not only averages.
The average tells you very little about the tail:
βWhat does the slowest 1% experience?β
Your worst user lives in the tail.
| Measure | Practical question |
|---|---|
| P50 | Is the normal path fast enough? |
| P95 | What does a slow but common request feel like? |
| P99 | What happens at the edge of the systemβs capacity? |
Track latency for the full task and for each stage:
Route β model β retrieval β tool β database β response
A slow P99 retrieval layer can make the model look guilty.
A slow tool can make the whole agent look unreliable.
Position matters.
Measure the spans before changing the model.
6οΈβ£ Cost Per Successful Task πΈ
Cost per token is a component metric.
The business metric is closer to:
Total evaluation cost
Γ· successful useful tasks
= cost per successful task
Include the costs that disappear in a happy-path demo:
- Retries β how many extra calls did recovery require?
- Routing β did the task use the correct model tier?
- Tools β what did retrieval, APIs, queues, and database work cost?
- Human review β how much operator time did the task consume?
- Failure work β how many runs produced no useful outcome?
A cheap model with a high false-action rate is not cheap.
An expensive model that finishes the task correctly in 1 pass may be the better product choice.
Measure the dollar required to produce a useful outcome.
7οΈβ£ False-Action Rate π¨
How often does the agent act when it should not?
This metric catches the most expensive category of confidence.
Examples:
- Write instead of read
- Send instead of draft
- Execute instead of ask
- Delete instead of archive
- Escalate data instead of requesting permission
TopiaX mascot stopping an agent before it takes an unauthorized action
Measure both sides:
False action = acted when policy required pause
Missed action = paused when safe automation was allowed
The first creates risk.
The second creates friction and operator overload.
Your target is not βthe agent never acts.β
Your target is the agent acts only inside the authority it has earned.
8οΈβ£ Escalation Accuracy π€
Does the system know when to route the task to a stronger model or a human?
Escalation is part of the answer.
It is not a failure state to hide from the dashboard.
Evaluate:
- True escalation β did a risky or uncertain task reach the right reviewer?
- Missed escalation β did the system continue when it should have stopped?
- False escalation β did an easy task create unnecessary human work?
- Recovery quality β did the handoff include enough context to continue?
The strongest model is not the right model for every task.
The reliable router knows when not to pretend.
9οΈβ£ Cache Hit Rate β‘
Caching can reduce latency and spend.
That does not mean every cache is helping.
Measure:
- Hit rate β how many eligible requests reused a result?
- Latency saved β did the hit shorten the user-visible path?
- Spend avoided β did it remove model or tool work?
- Freshness β was the cached result still valid for this user and state?
A high hit rate for stale or wrongly scoped results is not a win.
Cache keys need the right identity, permissions, locale, model version, and data freshness boundary.
Sometimes moving the cache decision earlier fixes everything.
Sometimes it moves the bug earlier too.
π Routing Accuracy π£οΈ
Did the router send the task to the correct model or tier?
Routing errors show up as other failures:
- A simple task sent to a slow expensive model.
- An ambiguous task sent to a weak model.
- A tool-heavy task sent to a route without the right capability.
- A high-risk task sent past the required approval path.
Score routing as its own evaluation.
Input β expected route β actual route β task outcome
The router is part of the product.
If it is wrong, the model may never get a fair chance to succeed.
The Production Eval Scorecard π
Here is the scorecard I want before calling an agent reliable:
| Metric | What to record |
|---|---|
| Accuracy | Correct result by workflow and severity |
| Faithfulness | Supported claims, evidence coverage, attribution |
| Tool selection | Right capability for the task |
| Parameter accuracy | Valid, scoped, correctly typed arguments |
| Tool success under load | Completion at 1, 100, and 1,000 users |
| P95/P99 latency | Full-task and per-stage tail latency |
| Cost per successful task | Total spend divided by useful outcomes |
| False-action rate | Actions taken outside policy or authority |
| Escalation accuracy | Correct stop, handoff, or stronger-model route |
| Routing accuracy | Actual model/tier versus expected route |
| Cache hit rate | Valid hits, latency saved, spend avoided |
Production AI evaluation scorecard for capability, reliability, and risk
Do not turn this into a vanity dashboard with 11 green numbers.
Attach every metric to a decision:
- Ship β the task meets its reliability and risk threshold.
- Conditional ship β the workflow stays bounded while evidence grows.
- No-go β the failure mode is too costly or too invisible.
The scorecard is useful when it changes what you do next.
The Real Bottom Line β‘
Run the benchmark.
Then benchmark the system you actually built.
The metric that matters most is closer to:
Successful useful tasks
Γ· dollars spent
at an acceptable risk level
That number only means something when you also know the P95/P99 latency, concurrency level, false-action rate, escalation behaviour, and evidence quality behind it.
The future is not a model leaderboard with your product bolted underneath.
It is a production eval loop that tells you what works, what breaks, and what to fix before real users become the QA team.
Your Turn π
Which metric is missing from your current AI dashboard?
Accuracy?
Tool-call success?
P99 latency?
Cost per successful task?
False actions?
Drop it below π
Let's compare the scorecards π
Choose your next move
Keep learning or check one workflow before release.
Production Agent Dispatch turns each week's field note into one failure pattern, one practical control, and one next move. Four minutes or less.
Use the gap profile when this article describes a real workflow your team expects to release.
Get your production AI gap profile