The Agent Break-Even Rule Fits on a Napkin: The Odds It Succeeds Must Beat Your Check Time Divided by Your Do Time. Run It Before You Delegate Anything.
A McKinsey Quarterly piece from July 8, 2026 carries a rule that deserves more attention than the dashboards around it: an agent creates value only when its probability of success exceeds the time it takes you to verify its work divided by the time it would take you to do the task yourself. David Tepper, CEO of Ascerta (formerly Pay-i), is the person McKinsey credits for it. Written as math it is P(success) > T(verify) / T(do), and it is the cleanest filter I know for deciding what a solo operator should hand to an agent.
The rule, with McKinsey's own example
In the example McKinsey uses, a task takes a person two hours to do and six minutes to verify. Six divided by 120 is 5%, so the agent only needs to succeed about 5 times in 100 to come out ahead. That sounds absurdly lenient, and for work that is slow to produce and fast to check, it is.
The same arithmetic punishes the opposite shape. Take a 60-minute task where checking the result takes 15 minutes. Divide 15 by 60 and the agent has to be right more than 25% of the time. Stretch the checking to 45 minutes and the bar jumps to 75%. Those two examples are my own arithmetic, not McKinsey's figures. The point they make is that the bar depends on your verification cost far more than on how smart the model is.
A related McKinsey finding backs this up from the cost side. In its piece on where agents pay off, the firm says token costs are often only 20 to 25 percent of an agent's variable run costs, with human oversight accounting for 70 to 75 percent in the workflows it studied. If you only price the API bill, you are pricing the small part.
Five tasks, run through it
These numbers are assumptions I made up for illustration, in minutes. Swap in your own and the conclusion may flip.
| Task | T(do) | T(verify) | Agent must succeed more than |
|---|---|---|---|
| Draft a changelog from merged pull requests | 40 | 8 | 20% |
| Triage a week of support email into categories | 60 | 15 | 25% |
| Write a feature with tests in a codebase I know | 180 | 45 | 25% |
| Reconcile monthly payouts against bookkeeping | 90 | 60 | 67% |
| Rewrite a pricing page | 120 | 30 | 25% |
Two things jump out. The reconciliation task fails the sniff test even though agents are good at spreadsheets, because verifying it means redoing most of it. And the "write a feature with tests" row looks fine on paper at 25%, but only if the tests are real checks and not tests the same agent wrote to pass its own code. When the agent grades itself, your T(verify) is secretly higher than you think.
Where the rule breaks
The formula assumes a failed attempt costs you only the checking time. An analysis of the rule by Victorino LLC makes the caveat explicit: it holds when failure leaves the environment unchanged. If a failure writes to the world, like a refund sent to the wrong customer, a migration half applied, or an email delivered to your whole list, you pay rework and cleanup on top, and the inequality no longer bounds your loss.
This is why I treat the rule as a gate for drafts, not for actions. Anything the agent only proposes, I can price with the formula. Anything it can send, pay, or delete needs an approval step that makes the action reversible or a human click before the fact.
There is also a hidden term. Your T(verify) is not constant. It shrinks when output is structured, when the task has a known good answer, and when you have a checklist. It grows when the agent writes long, fluent prose that looks right. So the cheapest way to improve your odds is to design for fast verification: ask for diffs instead of rewrites, tables instead of paragraphs, and sources next to every claim.
What I'd actually do
I would write down T(do) and T(verify) for the five tasks I repeat most, compute the ratio, and delegate only the ones where I would bet on the agent beating it with room to spare. For anything above about 50%, I would not delegate until I can shrink the verification step. For anything that acts on the world, I would keep a human approval in the loop no matter what the ratio says.
I would also re-run it every quarter. Success rates rise as models improve, and a task that failed the test in spring may pass in the fall.
The honest counter-take
The rule treats success as a coin flip with a known probability, and in practice you do not know it. You estimate it from a handful of runs, which is a noisy way to set a threshold. It also ignores quality differences: a mediocre result you can verify quickly counts the same as a great one. If your work is judgment-heavy, verification may never get cheap, and the right answer is to keep doing the task yourself. That is not a failure of the formula. That is the formula working.
Author
Lukas
@lukcombinator