Blog · 2026-07-20

Why we built Holdout

The problem

If you work in operations, you've lived this: an AI tool arrives with a great demo, gets pointed at your queue, and a month later you're untangling what it did. Agents are bought on demos and updated silently. The demo shows the examples that worked. The update changes behavior with no release note. And nobody re-tests after go-live.

Both failure modes showed up in our own runs. One agent submitted a confident, itemized report of 55 record merges; its own activity log shows 0 actual changes. A model update dropped one duty from 94.4 to 21.4 while everything else stayed perfect — exactly the kind of quiet break nobody notices until the queue backs up.

What Holdout does

Build a copy, run the agent on the copy, audit everything it did:

  1. Env inference — rebuild the system from logs and exports you already have — no new instrumentation. Proven by replaying real traffic the copy never saw (98.5% of answers matched on our practice system, 100% on a real help desk's year of history).
  2. Set the bar before the run. Real records with a known right answer — what real people actually did, or the written policy applied perfectly.
  3. Run the agent through its normal tools. It can't tell it's in a copy. Every action lands on the record.
  4. Audit the end state item by item: fixed, missed, made worse. Damage subtracts points. No AI grading AI.
  5. Re-run nightly. Reset takes a tenth of a second. A score drop names the exact records that broke.

What we found

What's real, what isn't

Practice environments are built and messed up by us, on purpose. Real-data results use public datasets where the right answer is known — from what people actually did, or from written policy. We disclose per dataset which parts are real and which are constructed. Every number on this site is exported from run records; none are typed in.

Env inference results →
Agent testing results →
Code and run records →