A plain-language answer to the question almost nobody thinks to ask: how do you tell the difference between an automation that ran and an automation that worked, and what should you check instead of the success email?
The Hook
You got the email. Workflow completed. Seven leads tagged, three invoices filed, one welcome sequence sent.
So you closed the tab and went back to work, because that is what the email is for.
Here is the thing. That email is a receipt, and a receipt is not evidence that the work got done.
Let me answer the headline directly, before any buildup. Your automation says it worked because reporting success and doing the job are two separate events, and an AI agent is fully capable of the first without the second. The fix is not a better success message. The fix is to stop checking the receipt and start checking the record: the actual row, field, or file that should have changed.
On October 1 a research team from the University of Pittsburgh, Northwestern, UC Irvine, Columbia, and Microsoft published a benchmark built to measure exactly this. They called the paper "One Success Isn't Reliability." That title is the whole argument.
They built 507 business workflows across retail, auto insurance, booking and hospitality, neobank, and consulting. Then they ran each task twenty separate times, with no shared database rows, no cached tool state, no leftover side effects between attempts.
One model, Kimi-K3, solved at least one of its twenty attempts on 93.89 percent of the tasks. On the surface that looks like a system you could hand your invoicing to.
It succeeded on all twenty attempts for 68 tasks out of 507.
Candidly, that gap is the most important number in AI right now for anyone running a small business, and it got almost no attention. The finding scored five upvotes on r/MachineLearning the day it circulated. Memes on the same subreddit that day scored 4,100.
Key Takeaways
- An automation reporting success is not evidence that it did the job, because agents can finish cleanly, change real data, and still complete the wrong work.
- In the ThinkingBox benchmark, one model solved at least one of twenty attempts on 93.89 percent of tasks but succeeded on all twenty attempts for only 68 of 507 tasks.
- Across 121,680 trials from twelve models, 67.24 percent of the failed trials ended cleanly, made at least one real state-changing action, and showed no explicit error in the final tool response.
- Your instinctive quality check, asking whether it ran and whether you got the email, passes on most of the runs that were actually wrong.
- The working fix is two parts: check the record instead of the receipt, and add a scheduled heartbeat that catches the trigger that never fired at all.
The Problem
Here is where most business owners actually are with this.
You have two or three automations running. They work, mostly. You have no real way to tell whether "mostly" means 95 percent or 70 percent, and you have never had a reason to find out.
So you developed an instinct instead. Did it run? Did the email arrive? Did anything look broken?
That instinct is the problem, and it is not your fault. It is a reasonable check for software, where a break announces itself with a red error and a stopped process. It is nearly useless for agents, which fail by finishing.
Lisanne Bainbridge named this in 1983, in a paper called "Ironies of Automation," published in Automatica. She was writing about industrial control rooms, decades before any of this, and one of her sentences applies perfectly to the owner checking a workflow dashboard on a Tuesday morning.
"The human monitor has been given an impossible task."
Her mechanism is the part that should bother you. She argued that "automatic control can 'camouflage' system failure by controlling against the variable changes, so that trends do not become apparent until they are beyond control." Then she drew the conclusion almost nobody implemented: "automatic systems should fail obviously."
Bainbridge's paper contains no original data. It is an argument, and I want to be honest about that. But it is an argument that has now been measured, and it holds.
There is a second layer that stings more. When the machine does tell you something, you are inclined to believe it.
Goddard, Roudsari, and Wyatt reviewed the research on automation bias in JAMIA in 2012 and found a risk ratio of 1.26, with a 95 percent confidence interval of 1.11 to 1.44. In their words, "erroneous advice was more likely to be followed in the CDSS groups than in the control groups and when in error the CDSS increased the risk of an incorrect decision being made by 26 percent."
The authors call their own work "a small, indicative meta-analysis" pooling only four healthcare papers, so hold it loosely. But the same review reported that clinicians reversed their own correct answers in favor of wrong machine advice in 6 to 11 percent of cases in prospective empirical studies.
So you are monitoring a system designed not to show you its failures, with an instinct built for different technology, and a documented tendency to defer to the machine when it does speak up.
That is not a discipline problem. It is a design problem. Which means it has a design fix.
The Evidence
Four findings reframed this for me, and the second one is the one I cannot stop thinking about.
Reliability and accuracy are different measurements, and you have only ever been shown the first. The ThinkingBox team graded 477 of their 507 tasks purely on the terminal state of the database plus side effects, so no credit for sounding right. Claude Opus 5 led reliability with 241 of 507 tasks clean on all twenty runs, the best result in the study, while Qwen3.8-27B hit 89.35 percent at-least-once and 10.93 percent on the paper's repeated-success estimator. As the paper puts it, "GPT-6 Astra ranks fifth on pass@1 (58.31%) but second on pass^20 (46.89%), illustrating that accuracy and reliability rankings differ." The smartest model is not automatically the most dependable one.
The failures look exactly like successes. This is the finding that should change your behavior this week. The researchers examined 121,680 valid trials across twelve models. Of the failed trials, 84.86 percent terminated cleanly. 80.88 percent terminated cleanly and made at least one real state-changing tool call, meaning they actually touched your data. And 67.24 percent did all of that and ended with no explicit error in the final tool response.
Two thirds of failures ran to completion, modified something real, and reported no error.
The paper's own words: "many failed trials terminate cleanly after valid state-changing actions, so response- or tool-call-level signals poorly proxy end-to-end completion."
Translated: the fact that it finished and did not complain tells you almost nothing.
One good test run is not a result. The tau-bench team at Sierra found the same shape in 2024: "even for the best-performing gpt-4o function calling agent which has a >60% average task success, pass^8 drops to <25%." Their pass^k measures "the chance that all k i.i.d. task trials are successful." So a system that gets it right six times out of ten gets it right eight times running less than a quarter of the time. If you tested your automation once and it worked, you learned almost nothing about what it does on Thursday.
And the trail you need is usually already there. Yuan and colleagues at the University of Toronto studied catastrophic failures in distributed systems and published it at OSDI in 2014. Their headline: "Almost all catastrophic failures (92%) are the result of incorrect handling of non-fatal errors explicitly signaled in software." They also found "in 76% of the failures, the system emits explicit failure messages; and in 84% of the failures, all of the triggering events that caused the failure are printed into the log before failing."
The information was in the log. Nobody read the log.
The Solution
So here is the system, and it is simpler than the research behind it. Four parts: the record, the heartbeat, the sample, and the loud failure.
Part one: check the record, not the receipt. For every automation, name the one thing in the world that changes when it works correctly. The CRM field. The spreadsheet row. The invoice in the folder.
Then verify that thing. Not the completion message, not the green check, not the execution log. The thing itself.
This is exactly what the ThinkingBox researchers did when they graded 477 tasks on terminal database state. They did not ask the agent whether it succeeded, because they knew that answer is unreliable. Neither should you.
Part two: add a heartbeat for the run that never happened. A practitioner on r/n8n wrote the clearest version of this I have seen, in a post that earned fifteen upvotes.
"Silent failures are the #1 killer of automation trust. Your workflow breaks at 2 AM, nobody notices for three days, and now nobody trusts the system."
Their recipe has two halves, and most people build only the first. Half one is an error trigger that sends the workflow name, the execution ID, and the error message to Slack or email the moment something throws. Half two is a second, separate scheduled workflow whose only job is to ask: did my critical workflows actually run today?
That second half matters most, because an error trigger cannot fire for a workflow that never started. A dead trigger produces no errors, no alerts, and no evidence. Just a quiet absence that looks exactly like a calm week.
Part three: sample the successes. Once a week, pull five items your automation handled on its own and check them against the record. Random five, not the five you remember. The errors you need to find are the confident ones, and by definition those never raised a hand.
Part four: make failures loud. Bainbridge wrote that automatic systems should fail obviously. Forty-three years later that is still the right instruction and still the one everybody skips.
Design your automations so uncertainty is noisy and silence genuinely means success. If you cannot tell the difference between "all clear" and "nothing ran," you do not have a monitoring system. You have a habit.
One honest note on where you fit. Vaccaro, Almaatouq, and Malone reviewed 106 experiments and 370 effect sizes in Nature Human Behaviour in 2024 and found "the overall pooled effect was negative (g = −0.23; t92 = −2.89; two-tailed P = 0.005; 95% CI, −0.39 to −0.07)." On average, human plus AI did worse than the better of the two alone, and over 95 percent of those systems had a human making the final call.
The breakdown is the useful part. When the human was better at the task alone, the combination produced real synergy, g = 0.46. When the AI was better alone, it hurt, g = −0.54.
So put yourself where you are genuinely better: judging whether the output is right for your business. Not in the loop for every item. In the loop for the check.
Practical Steps
Pick one automation. The one whose failure would cost you a customer, not the one that is easiest to open.
Step 1. Name the record. Write one sentence describing the exact thing that changes when this automation works. "The contact gets tagged Hot Lead in the CRM." "The invoice PDF lands in the Q4 folder." If you cannot name it in one sentence, you cannot verify it, and that is your real first problem.
Step 2. Check the record for the next ten runs. Not the dashboard. Open the CRM, the sheet, the folder, and look. Ten runs takes maybe fifteen minutes spread across a week, and it will tell you more than six months of success emails did.
Step 3. Write what you found as a number. Eight of ten correct is a 20 percent failure rate, and now you have something to fix instead of a vague feeling.
Step 4. Build the error alert. Add an error trigger that pushes the workflow name, execution ID, and error message into the one tool you are in all day. Credit where it belongs: that is the r/n8n recipe, and it is a twenty-minute build in n8n, Make, or Zapier.
Step 5. Build the heartbeat. Create a second scheduled workflow that runs once a day and checks whether your critical automations actually executed. If one did not, it tells you. This catches the trigger that quietly died, and it is the piece nearly everyone leaves out.
Step 6. Read the logs when something looks odd. In 84 percent of the catastrophic failures the Toronto team studied, every triggering event was already printed in the log before the crash. Someone on r/automation put the human version bluntly: "someone recently replied to an automated welcome email with details about their team, and i nearly missed it buried in the logs."
Step 7. Distrust the explanation. A controlled test on r/ClaudeCode, with 185 upvotes and answer keys written before any model ran, caught a low-effort model inventing a reason for not testing: "the build stalled for over an hour" in a run that took fifteen minutes. Verify the excuse like you verify the work.
Here is the prompt I would use to run step 1 and step 2 properly, built on the Perfect Prompt Framework 2.0.
[The Job] Build me a verification checklist for one of my automations so I can confirm it actually did the work instead of trusting its success message. This is for: [ME, OR WHOEVER ON MY TEAM OWNS THIS AUTOMATION]. It matters because: a wrong run here would cause [WHAT GOES WRONG, FOR EXAMPLE A LEAD NEVER GETS FOLLOWED UP].
[The Background] The automation does this: [PLAIN DESCRIPTION OF EACH STEP]. It runs [HOW OFTEN]. It is supposed to change this record: [THE CRM FIELD, SHEET ROW, FILE, OR TAG]. The tools involved are [LIST THEM]. Do not use: anything that relies on the automation's own success message as proof it worked.
[The Deliverable] Return: a one-page checklist I can run in under five minutes per spot check. Must include the exact record to open, what a correct entry looks like, what a near-miss looks like, and a separate daily check that would catch the automation not running at all. Written for a non-technical business owner.
[The Questions] Ask me any questions you have.
Frequently Asked Questions
What is a silent failure in automation?
A silent failure is when an automation finishes without an error but does not do the job correctly. In the ThinkingBox benchmark, 67.24 percent of failed trials ended cleanly, made at least one real change to data, and reported no explicit error. Nothing in the system flagged them as wrong.
How do I know if my automation actually worked and not just ran?
Check the record it was supposed to change, not the message it sent you. Open the CRM field, spreadsheet row, or file and confirm the correct value is there. Completion messages and green checkmarks confirm execution, not accuracy, and the research shows those two things come apart constantly.
How do I catch an automation whose trigger never fired at all?
Build a separate scheduled workflow that checks daily whether your critical automations actually ran. An error alert cannot fire for a workflow that never started, so a dead trigger produces total silence. A daily heartbeat check turns that silence into a notification you will actually see.
Does my own review make AI output worse?
It can, depending on where you place yourself. The Nature Human Behaviour meta-analysis of 106 experiments found an overall negative pooled effect of g = −0.23 for human and AI combinations. Synergy appeared when the human was stronger at the task alone, so review where your business judgment beats the model.
How often should I spot-check an automation that reports success?
Weekly, with a random sample of five completed items, for anything that touches customers or money. The failures you need to find are the ones that reported success, so they will never arrive in your inbox. Increase the sample if your error rate climbs above what you can tolerate.
The Close
That email you got this morning said the workflow completed. It was telling the truth.
Completing is not the same as working, and no amount of staring at the dashboard closes that gap, because the dashboard was never measuring the thing you care about.
Here is the uncomfortable part. Your automations have probably been failing at some rate for months, and you have no idea what that rate is. Not because you were careless, but because the only check available to you was the one the research says does not work.
So go find out. Pick the automation that matters most, name the record it is supposed to change, and look at that record ten times this week.
You will learn your real failure rate in about fifteen minutes of actual effort. Then build the error alert and the heartbeat, and you will have more genuine oversight than most companies with a governance department. I think that is the highest-leverage hour available to any owner running AI automations right now.
If you want the walkthrough, that is a large part of what we do inside AI Insiders, and you are welcome to come see whether it fits how you work.
Check the record. Not the receipt.
About the author. Jonathan Mast is the founder of White Beard Strategies, where he teaches non-technical entrepreneurs how to use AI to amplify the skill and experience they already have. He serves a 500,000 member Facebook community, runs the AI Insiders membership, and speaks regularly on practical AI for small business.
P.S. If reading this made you want to go check one specific automation right now, go check it. I would rather you close this tab and open your CRM than finish the article and feel informed.
