Skip to content

PreviewAll content, scores and forecasts here are illustrative sample data — not reporting, and not measurements.What this means

Agitology
Perspective8 min readSample

The demo-to-deployment gap is not a detail, it is the problem

Four years of shipping agents into environments where mistakes cost money. What actually breaks is never what the benchmarks measure.

The position

Reliability, not capability, is the binding constraint on autonomy — and it is not on the trajectory the capability curves suggest.

Jonas HalvorsenFounder · Independent

I have spent four years putting agent systems into environments where being wrong costs someone money. In that time the capability of the underlying models has improved beyond what I would have predicted. The fraction of tasks I am willing to leave unsupervised has improved far less, and I want to explain why those are different numbers.

The failures are not capability failures

When a deployment fails, it is almost never because the model could not do the task. It is because the task was underspecified and the system confidently resolved the ambiguity in a way nobody wanted. Or the environment changed mid-run. Or an API returned an error the system retried nine times without reading.

None of these appear in evaluations, because evaluations specify the task, freeze the environment and mock the tools. Those three choices are what make a benchmark a benchmark. They are also the three things that break in production.

8 hours

Unsupervised window on well-specified tasks

The same systems, on open-ended tasks, need intervention within the hour.

The eight-hour number is real and narrower than it sounds

We genuinely do run agents for a full working day without intervention now, which was impossible two years ago. But read the qualifier: well-specified engineering tasks. Clear goal, verifiable success, an environment I control.

On open-ended work the number is closer to forty minutes, and it has not moved nearly as fast. The gap between those two figures is the entire remaining problem in autonomy, and it is a specification problem, not a capability one.

Silent failure is what keeps the human there

If systems failed loudly I would have removed the human from most of these loops already. A crash is cheap: you see it, you fix it, you re-run. What I actually get is eight hours of plausible work with a wrong assumption threaded through the middle of it, discovered in review two days later.

I do not need the system to be smarter. I need it to know when it is guessing, and to stop.

Self-halting has started to appear, and it is the most encouraging development I have seen in two years — more encouraging than any capability release. It is also early, unevenly distributed, and nowhere near reliable enough to justify the trust it would need.

What I would tell someone forecasting from the outside

  • Discount benchmark scores near saturation entirely. They stopped discriminating before they stopped being cited.
  • Ask for intervention rate on production tasks. Almost nobody publishes it, and the silence is the answer.
  • Watch calibration, not capability. The system that knows it is wrong is worth more than the system that is right more often.
  • Assume the demo was the best run. It always was, including mine.

Autonomy at 53 feels about right to me, which surprised me — I expected to think it was generous. What I would add is that the number moves when verification moves, and verification is not a model capability. It is going to come from somewhere else.

Continue

Other perspectives