The bottleneck has moved.

Prompt-and-response is a useful interface. It is a poor proxy for whether a model can operate software. Work has state, sequence, constraints, and consequences. A gap separates a model that can explain a workflow from one that can complete it, and current benchmarks fail to measure it.

We start from tasks executed inside stateful environments because downstream work needs models that finish the job across variations without supervision.

Models improved faster than the environments available to train them, and few teams have noticed. Teams can use stronger models but have nowhere rich enough to train them for interactive work.

Thin environments, a screenshot, a few API calls, a scalar reward, teach thin behaviors. Richer environments, with real state machines, plausible data, and strict constraints, teach planning, restraint, error recovery, and follow-through. The quality of your training environments limits what the model learns.

A pass/fail score on a benchmark tells you almost nothing about why a model failed. Was it a planning error, a state-tracking mistake, a UI misread, or an inability to recover after an early wrong turn? Without criterion-level grading, you cannot distinguish between a model that nearly succeeded and one that was lost from the first step.

Evaluation should be diagnostic. It should explain what held, what broke, and how the final state diverged from expectation. That is the least feedback worth keeping, for researchers tuning training and for models that train on grading signal.

A session that returns only a grade has discarded most of its value. The trace of actions, the intermediate states, the decision points where the model hesitated or chose wrong. These records show what happened and why. They are also the training data.

Sessions should stay available as objects you can inspect, replay, fork, and export. If you cannot go back to a specific moment in a session and ask what the model saw and what it chose, your evaluation infrastructure hides more than it reveals.

Most evaluation pipelines treat failure as a dead end, a zero in a spreadsheet. This is a waste. A failure recorded with full state can sharpen a task, reveal a blind spot in a rubric, generate a harder scenario, or become the kind of training example the model needs most.

The compounding happens here. A platform that converts failures into better training inputs, automatically and without manual curation, does more than one that only reports grades.

Benchmarks give the field a common reference point and that matters. But what matters more is what happens after the grade: inspect the trace, diagnose the failure, adjust the task or the training data, run again. The fastest teams are the ones that get from failure to the next useful session first.

A good training platform should shorten this cycle until failures shape the next round of training environments, and new tasks land where the model is weakest.

Model capabilities arrive years before the tooling to use them responsibly. We have seen it with language generation, with code synthesis, with image understanding. Computer use follows the same pattern. The models are getting closer to real production work. The training and evaluation infrastructure is not keeping up.

This gap is an urgent problem and a real opening. The teams that will train the most dependable computer-use agents need infrastructure precise enough for research and clear enough for production decisions. That is what we are building.