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 model that can explain how to complete a workflow and a model that can actually complete it are separated by a gap that current benchmarks mostly fail to measure.

We start from tasks executed inside stateful environments because that is what matters downstream: not whether a model can discuss the work, but whether it can do it — reliably, across variations, without someone watching.

Model capability has outpaced the environments available to train against. This is an underappreciated asymmetry. Teams have access to increasingly powerful models and nowhere sufficiently rich 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 meaningful constraints, surface planning, restraint, error recovery, and follow-through. The quality of what you get out is bounded by the quality of what you train against.

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 minimum useful unit of feedback — for researchers tuning a training run, and for the model itself if you are using evaluation signal as reward.

A training run that produces only a score has discarded most of its value. The trace of actions, the intermediate states, the decision points where the model hesitated or chose wrong — these are the artifacts that let you understand what happened and why. They are also, increasingly, the training data.

Sessions should be first-class objects: inspectable, replayable, forkable, and exportable. If you cannot go back to a specific moment in a run and ask what the model saw and what it chose, your evaluation infrastructure is hiding more than it reveals.

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

The compounding happens here. A platform that converts failures into better training inputs — automatically, without manual curation — has a fundamentally different trajectory from one that merely reports scores.

Benchmarks give the field a common reference point and that matters. But the deeper leverage is in what happens after the score: inspect the trace, diagnose the failure, adjust the task or the training data, run again. The teams that move fastest are the ones with the tightest loop from failure to the next useful run.

A good training platform should shorten this loop until it becomes nearly automatic — where a model's failures directly inform the next round of training environments, and the universe of tasks expands precisely where the model is weakest.

There is a pattern in this field where 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 is following the same arc. The models are getting closer to real production work. The training and evaluation infrastructure is not keeping up.

We think this gap is both an urgent problem and a genuine opportunity. The teams that will train the most dependable computer-use agents need infrastructure that is precise enough for research, honest enough for production decisions, and ambitious enough to keep pace with the frontier. That is what we are building.