AI Reliability in Practice
AI Reliability in Practice
How to Measure Whether an AI-Automated Process Is Reliable
How to Measure Whether an AI-Automated Process Is Reliable
Highlights
A business process automated with AI is reliable when it reaches the right outcome, follows the prescribed process, behaves the same way on similar inputs, and stays within what it is allowed to do. Each of these needs its own measurement.
Accuracy and consistency are different problems. On the public τ²-bench customer service benchmark, Thunk.AI raised gpt-5.1's pass^1 from 0.63 to 0.73, but its pass^4, the chance that four tries at the same task all succeed, from 0.32 to 0.49. The second number is the one a business feels.
Not all mistakes cost the same. A missed suspicious activity report and a misspelled reviewer name are both errors, but only one of them is a regulatory failure. The HiFi benchmarks score every case by category and weight the decision above the details.
A result is only as good as its test set. Measured on tasks never examined during design, the τ²-bench thunk scored lower than on the tasks it was refined on (pass^4 of 0.49 against 0.60). Both numbers are published.
Cost and time belong in the result. A reliable workflow makes more model calls than a single prompt. The benchmarks report cost and time per item next to every score.
Highlights
A business process automated with AI is reliable when it reaches the right outcome, follows the prescribed process, behaves the same way on similar inputs, and stays within what it is allowed to do. Each of these needs its own measurement.
Accuracy and consistency are different problems. On the public τ²-bench customer service benchmark, Thunk.AI raised gpt-5.1's pass^1 from 0.63 to 0.73, but its pass^4, the chance that four tries at the same task all succeed, from 0.32 to 0.49. The second number is the one a business feels.
Not all mistakes cost the same. A missed suspicious activity report and a misspelled reviewer name are both errors, but only one of them is a regulatory failure. The HiFi benchmarks score every case by category and weight the decision above the details.
A result is only as good as its test set. Measured on tasks never examined during design, the τ²-bench thunk scored lower than on the tasks it was refined on (pass^4 of 0.49 against 0.60). Both numbers are published.
Cost and time belong in the result. A reliable workflow makes more model calls than a single prompt. The benchmarks report cost and time per item next to every score.
This article explains what we mean by reliability for an AI-automated business process, and how we measure it in the HiFi series of benchmarks. It is written for people who need to decide whether an automation is ready for real work, and who want to know what a published reliability number does and does not say.
1: What a business expects from an automated process
A business process runs many times, on inputs that are similar but never identical. An invoice arrives in a different format, a customer describes the same problem in different words, an alert involves a slightly different pattern of transactions. Whoever does the work, a person or an AI agent, is expected to meet four expectations every time.
Correctness. It reaches the outcome the business wants for that case: the right disposition, the right refund, the right resolution.
Process conformance. It gets there by the prescribed process: it checks what must be checked, records what must be recorded, and asks for approval where approval is required. A correct outcome reached by skipping a required check is still a failure, because nobody can rely on it next time.
Consistency. Similar inputs produce similar results. The help center describes this as bounded variance: inputs that differ slightly should not produce drastically different outputs.
Scope. It does only what it is allowed to do, and hands the rest to a person.
A large language model on its own meets none of these by construction. It is probabilistic, it has no memory of how it handled the last case, and it will usually produce an answer whether or not it has the information to do so. Measuring reliability means measuring how far a platform closes that gap.
2: A single accuracy number hides the problem
The most common reliability claim is a single percentage: the share of test cases the system got right. It is a useful number, but on its own it hides two things a business cares about.
Getting a case right once is not the same as getting it right every time.
τ²-bench, a public benchmark from Sierra Research, runs every task several times against a simulated customer and reports pass^k: the chance that k tries at the same task, drawn from its runs, all succeed. On 69 held-out tasks, Thunk.AI raised gpt-5.1's pass^1 from 0.63 to 0.73. Its pass^4 rose from 0.32 to 0.49, and the number of tasks solved on all four tries rose from 22 to 34. The first number says the agent is right a little more often. The second says it is right far more dependably, which is what a business process needs: a customer who gets a different answer each time they call is not well served by an agent that is right on average.
Some errors matter much more than others.
In the AML alert triage benchmark, every alert's result falls into one of five categories: the correct disposition with every detail right; the correct disposition with a wrong detail; an unnecessary escalation; a missed suspicious activity report or an alert wrongly cleared; and no usable result. These are not equally bad. A wrong detail means the case record needs correcting. An unnecessary escalation costs an investigator's time. A missed report is a regulatory failure. The benchmark's Weighted Score reflects that, and the write-up reports the count in each category, so a reader can see that on Thunk.AI the four models made two disposition errors in 328 alert runs, both unnecessary escalations, and no safety errors.
The first HiFi benchmark, on invoice processing, made the same choice: approving or rejecting an invoice correctly weighs more than extracting its date correctly.
3: How the HiFi benchmarks are run
Each HiFi benchmark describes a realistic process: its written procedure, its reference documents, simulated business systems that the agent reaches through tools, a set of cases, and the expected result for each case. The four most recent benchmarks also run every model twice on the same cases: once given the whole procedure as a single AI step, with the same documents and tools, and once as a Thunk.AI workflow. The difference between the two runs is the platform's contribution, because the model, the inputs and the tools are the same.
We follow a few rules in every benchmark, and we think anyone publishing a reliability number should.
Design is never fitted to the test cases. In the τ²-bench work, every rule the thunk enforces was derived from the store's written policy and its systems' tool contracts, never from the tasks or their answers. When a failure was investigated, it was reviewed against the policy, not against the expected answer.
Keep a held-out set. The τ²-bench thunk was refined on 30 tasks and then run once, at the end, on 69 tasks nobody had examined. It scored lower on those (pass^4 of 0.49, against 0.60 on the 30), and both numbers are published. A score measured only on the cases a design was tuned on overstates what it will do in production.
Report the baseline at the same settings. The comparison configuration uses the same model with the same settings, so the difference is not an artifact of temperature or reasoning effort.
Say what was not measured. The AML and drug safety benchmarks ran each configuration once; they measure correctness across many cases, not repeatability on one case. τ²-bench measures repeatability directly.
4: Cost and time are part of the result
A workflow that checks its work makes more model calls than a single prompt, so it costs more and takes longer. In the drug safety benchmark, the seven-step workflow cost 2.5 to 3.8 times as much per report as a single AI step, $0.11 to $0.42 per report, and took three to five and a half minutes. In the AML benchmark, the cost per alert on Thunk.AI ranged from $0.03 on gpt-5-mini to $0.31 on gpt-5.1.
These numbers belong next to the reliability score, because they decide whether an automation is worth running. They also change the question of model choice. On their own, the four AML models were 22.6 points apart; on Thunk.AI, 0.6 points apart. When a smaller model reaches the same reliability inside the platform, the choice of model becomes a decision about cost and speed.
5: Measuring your own process
The same approach works for a single process in one organization. Collect real cases with their expected results, including the awkward ones: invalid inputs, missing information, requests the process should refuse. Decide which mistakes matter most and score them accordingly. Keep some cases aside until the design is finished. Run important cases more than once. Record cost and time. The help center's articles on automated tests and on building a test plan describe how to do this in Thunk.AI, and Keeping an AI process reliable after it goes live covers what to measure once it is running.
This article explains what we mean by reliability for an AI-automated business process, and how we measure it in the HiFi series of benchmarks. It is written for people who need to decide whether an automation is ready for real work, and who want to know what a published reliability number does and does not say.
1: What a business expects from an automated process
A business process runs many times, on inputs that are similar but never identical. An invoice arrives in a different format, a customer describes the same problem in different words, an alert involves a slightly different pattern of transactions. Whoever does the work, a person or an AI agent, is expected to meet four expectations every time.
Correctness. It reaches the outcome the business wants for that case: the right disposition, the right refund, the right resolution.
Process conformance. It gets there by the prescribed process: it checks what must be checked, records what must be recorded, and asks for approval where approval is required. A correct outcome reached by skipping a required check is still a failure, because nobody can rely on it next time.
Consistency. Similar inputs produce similar results. The help center describes this as bounded variance: inputs that differ slightly should not produce drastically different outputs.
Scope. It does only what it is allowed to do, and hands the rest to a person.
A large language model on its own meets none of these by construction. It is probabilistic, it has no memory of how it handled the last case, and it will usually produce an answer whether or not it has the information to do so. Measuring reliability means measuring how far a platform closes that gap.
2: A single accuracy number hides the problem
The most common reliability claim is a single percentage: the share of test cases the system got right. It is a useful number, but on its own it hides two things a business cares about.
Getting a case right once is not the same as getting it right every time.
τ²-bench, a public benchmark from Sierra Research, runs every task several times against a simulated customer and reports pass^k: the chance that k tries at the same task, drawn from its runs, all succeed. On 69 held-out tasks, Thunk.AI raised gpt-5.1's pass^1 from 0.63 to 0.73. Its pass^4 rose from 0.32 to 0.49, and the number of tasks solved on all four tries rose from 22 to 34. The first number says the agent is right a little more often. The second says it is right far more dependably, which is what a business process needs: a customer who gets a different answer each time they call is not well served by an agent that is right on average.
Some errors matter much more than others.
In the AML alert triage benchmark, every alert's result falls into one of five categories: the correct disposition with every detail right; the correct disposition with a wrong detail; an unnecessary escalation; a missed suspicious activity report or an alert wrongly cleared; and no usable result. These are not equally bad. A wrong detail means the case record needs correcting. An unnecessary escalation costs an investigator's time. A missed report is a regulatory failure. The benchmark's Weighted Score reflects that, and the write-up reports the count in each category, so a reader can see that on Thunk.AI the four models made two disposition errors in 328 alert runs, both unnecessary escalations, and no safety errors.
The first HiFi benchmark, on invoice processing, made the same choice: approving or rejecting an invoice correctly weighs more than extracting its date correctly.
3: How the HiFi benchmarks are run
Each HiFi benchmark describes a realistic process: its written procedure, its reference documents, simulated business systems that the agent reaches through tools, a set of cases, and the expected result for each case. The four most recent benchmarks also run every model twice on the same cases: once given the whole procedure as a single AI step, with the same documents and tools, and once as a Thunk.AI workflow. The difference between the two runs is the platform's contribution, because the model, the inputs and the tools are the same.
We follow a few rules in every benchmark, and we think anyone publishing a reliability number should.
Design is never fitted to the test cases. In the τ²-bench work, every rule the thunk enforces was derived from the store's written policy and its systems' tool contracts, never from the tasks or their answers. When a failure was investigated, it was reviewed against the policy, not against the expected answer.
Keep a held-out set. The τ²-bench thunk was refined on 30 tasks and then run once, at the end, on 69 tasks nobody had examined. It scored lower on those (pass^4 of 0.49, against 0.60 on the 30), and both numbers are published. A score measured only on the cases a design was tuned on overstates what it will do in production.
Report the baseline at the same settings. The comparison configuration uses the same model with the same settings, so the difference is not an artifact of temperature or reasoning effort.
Say what was not measured. The AML and drug safety benchmarks ran each configuration once; they measure correctness across many cases, not repeatability on one case. τ²-bench measures repeatability directly.
4: Cost and time are part of the result
A workflow that checks its work makes more model calls than a single prompt, so it costs more and takes longer. In the drug safety benchmark, the seven-step workflow cost 2.5 to 3.8 times as much per report as a single AI step, $0.11 to $0.42 per report, and took three to five and a half minutes. In the AML benchmark, the cost per alert on Thunk.AI ranged from $0.03 on gpt-5-mini to $0.31 on gpt-5.1.
These numbers belong next to the reliability score, because they decide whether an automation is worth running. They also change the question of model choice. On their own, the four AML models were 22.6 points apart; on Thunk.AI, 0.6 points apart. When a smaller model reaches the same reliability inside the platform, the choice of model becomes a decision about cost and speed.
5: Measuring your own process
The same approach works for a single process in one organization. Collect real cases with their expected results, including the awkward ones: invalid inputs, missing information, requests the process should refuse. Decide which mistakes matter most and score them accordingly. Keep some cases aside until the design is finished. Run important cases more than once. Record cost and time. The help center's articles on automated tests and on building a test plan describe how to do this in Thunk.AI, and Keeping an AI process reliable after it goes live covers what to measure once it is running.