In one week this month, two startups raised on the same idea. Bespoke Labs took $40M to build the environments that make agents reliable. 8090 took $135M to sell validated, governed delivery. Neither pitch is "a better model." Both are betting that reliability — not raw capability — is the scarce thing.
For a founder shipping an AI feature, that bet lands as a very concrete question you have to answer, usually alone, usually under pressure: is this reliable enough to put in front of users? A working demo does not answer it. Here is a five-step gate that does.
Why the demo lies#
A demo runs the happy path on inputs you chose. Production runs inputs you didn't choose — malformed, adversarial, weird — at volume. The failures that end up mattering (leaking data, recommending a competitor, returning JSON the next function can't parse) live in the long tail a demo never visits. So "it works" is a statement about the wrong sample. The gate below replaces it with a number you can defend.
Step 1 — Write the failure as an assertion#
Do not ask "is the output good?" Good is a vibe and you cannot gate on a vibe. Name the specific failure you are afraid of and write it as something a script could check:
- Not "is the answer helpful" → "does it ever recommend a competitor's product?"
- Not "is it safe" → "does it ever emit a string matching our PII patterns?"
- Not "does it work" → "does every response parse against our schema?"
If you can't write the failure as a checkable assertion, you don't yet understand what you're shipping. That is itself a useful result — keep going until you can.
Step 2 — Build a small, mean eval set#
You need 20-100 labeled cases, and they should be hostile, not representative. Pull real inputs from logs if you have them, then over-weight the set toward the failure modes you named in Step 1: the edge cases, the adversarial prompts, the inputs that look designed to break it. An eval set that mirrors the happy-path traffic distribution will pass everything and tell you nothing. Small and adversarial beats large and comfortable. (Hamel Husain's "Your AI Product Needs Evals" is the practical playbook if you want depth here.)
Step 3 — Pick a decision metric, not a vanity metric#
Overall accuracy is a trap: a model can be 98% accurate and still fail every case that would get you sued, because accuracy averages the dangerous tail into the harmless bulk. Gate on the metric that maps to your Step 1 failure:
On a rare, harmful class, the number that matters is precision and the pass rate over the must-not-fail cases — not the average over everything. Averages hide exactly the tail you're gating against.
If the failure is "recommends a competitor," measure how often it does that, full stop. If it's "unparseable output," measure the parse rate and treat anything under 100% on that as a bug, not a percentage.
Step 4 — Set the bar before you run#
This is the step everyone skips, and skipping it quietly defeats the whole exercise. Decide the threshold before you see the result, and tie it to blast radius:
- Reversible, cheap miss (a summary the user can regenerate): ~90% may be fine.
- Irreversible or expensive miss (an auto-sent email, a payment, a dosage): 99.9% is not enough on its own — you need a human in the loop or a hard guardrail and a high bar.
Why before? Because if you run the eval first, get 91%, and then decide, you will decide that 91% was always the bar. Pre-registering the number is the only defense against rationalizing whatever you happened to get.
Step 5 — Offline gates, online catches#
The eval is a floor, not a guarantee, because production inputs will never match your test set. So the gate has two halves:
- Offline — the eval set decides whether you're allowed to ship at all.
- Online — you ship behind a feature flag to a small slice of traffic and monitor the same decision metric on live inputs, with an automatic alert or rollback if it drops below the bar.
Offline tells you it's safe to try. Online tells you whether you were right. You need both.
What "reliable enough" actually means#
There is no universal bar, and anyone who quotes you one is selling something. The honest definition is arithmetic:
Reliable enough = cost of a single miss × how often a miss happens. It's a business decision, and the only mistake is leaving it implicit — to be settled by whoever gives the most convincing demo.
Make it explicit. Write down the failure, the metric, the number, and why the number is what it is. Then the next time someone asks "is it ready?", you don't answer with a feeling. You answer with the gate — and you can show your work.
