AI Reliability in Practice
AI Reliability in Practice
Keeping an AI Process Reliable After It Goes Live
Keeping an AI Process Reliable After It Goes Live
Highlights
Reliability is not established once. Inputs change, policies change, models are retired, and a process that worked last quarter can drift. Keeping it reliable takes the same discipline as building it.
Test with real cases and clear assertions. Thunk.AI test work items carry assertions checked by rules or graded by AI. An inconclusive result is treated as a defect in the test, and a test is never weakened to make it pass.
Every complaint becomes a test. User feedback is not a test, but it should always be turned into one.
Watch behavior, not only outcomes. The Behavior tab shows how consistently a step follows the same sequence of tool calls, and flags the runs that do something unusual.
Change things in a copy. Improve a live process in a copy with stand-in tools, and move to a new model by running the test set on it and comparing pass rate, cost and time.
Know what reliability costs. In the benchmarks, the reliable workflow cost $0.03 to $0.42 per item. A smaller model on the platform is often enough.
Highlights
Reliability is not established once. Inputs change, policies change, models are retired, and a process that worked last quarter can drift. Keeping it reliable takes the same discipline as building it.
Test with real cases and clear assertions. Thunk.AI test work items carry assertions checked by rules or graded by AI. An inconclusive result is treated as a defect in the test, and a test is never weakened to make it pass.
Every complaint becomes a test. User feedback is not a test, but it should always be turned into one.
Watch behavior, not only outcomes. The Behavior tab shows how consistently a step follows the same sequence of tool calls, and flags the runs that do something unusual.
Change things in a copy. Improve a live process in a copy with stand-in tools, and move to a new model by running the test set on it and comparing pass rate, cost and time.
Know what reliability costs. In the benchmarks, the reliable workflow cost $0.03 to $0.42 per item. A smaller model on the platform is often enough.
This article describes how to keep an AI-automated process reliable once it is in use: how to test it before it goes live, how to watch it while it runs, how to change it without breaking it, and how to think about its cost.
1: Before it goes live: test with real cases
A process should not go live until it has been tested on cases that look like production, with expected results written down in advance. In Thunk.AI, a test work item is a case with its inputs and assertions about the result. Some assertions are rules, such as "the disposition is Clear" or "the refund equals the order total", which are exact, free and repeatable. Others are graded by AI, for content and meaning, such as "the summary mentions the missing invoice number". A test can pass, fail or be inconclusive. An inconclusive result means the test is not clear enough to decide, and is fixed as a defect in the test, not counted as a pass.
The help center's test-planning guidance comes down to two observations: a thunk tested on few cases, or on poor test data, will be a poor thunk. Coverage should be planned by the shapes inputs take, including invalid inputs, missing information and requests the process should refuse. For conversations, a simulated user can play the customer or the colleague on the other end. A test is never weakened to make it pass; if the expected result was wrong, it is corrected with the reason recorded.
The decision to go live rests on coverage, pass rate and the risk of the remaining failures, and it is made with the business owners of the process.
2: Review the design, not only the results
A process can pass its tests and still have weaknesses that the tests do not reach. Thunk.AI's workflow review checks the design itself: properties without descriptions, or whose type does not match their description; tools with loose schemas; steps that write properties they have no reason to write; data that is produced but never used; steps that retry actions with side effects; and directions that do not state an objective and a process. Findings are graded as critical, advisory or informational.
3: Once it runs: watch behavior, not only outcomes
Outcomes show whether a case came out right. Behavior shows whether the process is doing what it was designed to do, often before outcomes suffer. The Behavior tab analyzes a step's recent runs and reports how consistently they follow the same sequence of tool calls, and which runs took an unusual path. A step whose tool sequence starts to vary is a step whose inputs or instructions have changed in a way worth understanding.
When a run does go wrong, step diagnostics show the full trace of the run, and the "What went wrong?" analysis proposes a cause, says how confident it is, and says when a retry will not help. Tool call history records every call with its arguments, results, time and cost.
4: Every complaint becomes a test
When a user reports a wrong result, the fix is not complete until the case is in the test set. The help center puts it as "user feedback is not a test, but it should always be converted into one." Over time the test set becomes a record of every way the process has failed, and a guard against each of them coming back.
5: Change things safely
A live process should not be the place where changes are tried. Changes are made in a copy of the thunk, with stand-in tools in place of the systems that real cases would touch, and the copy is run on the test set before the change is moved across.
Model changes deserve the same care. Models improve and are retired, and a step that depends on a particular model's habits can change when the model does. In Thunk.AI, a model can be chosen per thunk, per step and per AI tool. A new model is tested by forcing it on the test work items and comparing pass rate, cost and time against the current one. When a model is retired, the platform moves steps to the closest model in the same family.
6: Know what reliability costs
The structure that makes a process reliable costs model calls. In the HiFi benchmarks, the reliable workflow cost $0.03 per alert on gpt-5-mini and $0.31 on gpt-5.1 in AML triage, and $0.11 to $0.42 per report in drug safety case intake, 2.5 to 3.8 times the cost of a single AI step. Each step run makes at least two model calls, one to do the work and one to conclude, and steps that check their work make more.
Two things follow. First, the cost of a reliable process should be compared with the cost of its failures, not with the cost of an unreliable process: a missed regulatory deadline, a wrong change to a production system, a customer given the wrong refund. Second, the most capable model is often unnecessary. On the platform, the AML models were 0.6 points apart, so the smallest model that passes the test set is usually the right one.
7: Reliability is maintained, not achieved
The benchmarks show what a well-designed process can do on a fixed set of cases. In production, the cases keep changing. A process stays reliable when its tests grow with every failure, its behavior is watched, its changes are made in a copy, and its decisions stay recorded where the next person can find them. How to measure whether an AI-automated process is reliable describes the measurements that make this possible.
This article describes how to keep an AI-automated process reliable once it is in use: how to test it before it goes live, how to watch it while it runs, how to change it without breaking it, and how to think about its cost.
1: Before it goes live: test with real cases
A process should not go live until it has been tested on cases that look like production, with expected results written down in advance. In Thunk.AI, a test work item is a case with its inputs and assertions about the result. Some assertions are rules, such as "the disposition is Clear" or "the refund equals the order total", which are exact, free and repeatable. Others are graded by AI, for content and meaning, such as "the summary mentions the missing invoice number". A test can pass, fail or be inconclusive. An inconclusive result means the test is not clear enough to decide, and is fixed as a defect in the test, not counted as a pass.
The help center's test-planning guidance comes down to two observations: a thunk tested on few cases, or on poor test data, will be a poor thunk. Coverage should be planned by the shapes inputs take, including invalid inputs, missing information and requests the process should refuse. For conversations, a simulated user can play the customer or the colleague on the other end. A test is never weakened to make it pass; if the expected result was wrong, it is corrected with the reason recorded.
The decision to go live rests on coverage, pass rate and the risk of the remaining failures, and it is made with the business owners of the process.
2: Review the design, not only the results
A process can pass its tests and still have weaknesses that the tests do not reach. Thunk.AI's workflow review checks the design itself: properties without descriptions, or whose type does not match their description; tools with loose schemas; steps that write properties they have no reason to write; data that is produced but never used; steps that retry actions with side effects; and directions that do not state an objective and a process. Findings are graded as critical, advisory or informational.
3: Once it runs: watch behavior, not only outcomes
Outcomes show whether a case came out right. Behavior shows whether the process is doing what it was designed to do, often before outcomes suffer. The Behavior tab analyzes a step's recent runs and reports how consistently they follow the same sequence of tool calls, and which runs took an unusual path. A step whose tool sequence starts to vary is a step whose inputs or instructions have changed in a way worth understanding.
When a run does go wrong, step diagnostics show the full trace of the run, and the "What went wrong?" analysis proposes a cause, says how confident it is, and says when a retry will not help. Tool call history records every call with its arguments, results, time and cost.
4: Every complaint becomes a test
When a user reports a wrong result, the fix is not complete until the case is in the test set. The help center puts it as "user feedback is not a test, but it should always be converted into one." Over time the test set becomes a record of every way the process has failed, and a guard against each of them coming back.
5: Change things safely
A live process should not be the place where changes are tried. Changes are made in a copy of the thunk, with stand-in tools in place of the systems that real cases would touch, and the copy is run on the test set before the change is moved across.
Model changes deserve the same care. Models improve and are retired, and a step that depends on a particular model's habits can change when the model does. In Thunk.AI, a model can be chosen per thunk, per step and per AI tool. A new model is tested by forcing it on the test work items and comparing pass rate, cost and time against the current one. When a model is retired, the platform moves steps to the closest model in the same family.
6: Know what reliability costs
The structure that makes a process reliable costs model calls. In the HiFi benchmarks, the reliable workflow cost $0.03 per alert on gpt-5-mini and $0.31 on gpt-5.1 in AML triage, and $0.11 to $0.42 per report in drug safety case intake, 2.5 to 3.8 times the cost of a single AI step. Each step run makes at least two model calls, one to do the work and one to conclude, and steps that check their work make more.
Two things follow. First, the cost of a reliable process should be compared with the cost of its failures, not with the cost of an unreliable process: a missed regulatory deadline, a wrong change to a production system, a customer given the wrong refund. Second, the most capable model is often unnecessary. On the platform, the AML models were 0.6 points apart, so the smallest model that passes the test set is usually the right one.
7: Reliability is maintained, not achieved
The benchmarks show what a well-designed process can do on a fixed set of cases. In production, the cases keep changing. A process stays reliable when its tests grow with every failure, its behavior is watched, its changes are made in a copy, and its decisions stay recorded where the next person can find them. How to measure whether an AI-automated process is reliable describes the measurements that make this possible.