Grading an agent run step by step

Grading an agent run means judging a whole trajectory, one step at a time, against a rubric. Turing has posted the terms of one evaluation project (Turing CUA evaluation project terms), and Microsoft Research has written up how it built a system that grades the same kind of run (computer-use verifier paper, Microsoft Research). This lesson sets the two side by side.

Why step by step

Researchers distinguish feedback on a final result (outcome supervision) from feedback on each intermediate step (process supervision). OpenAI’s “Let’s Verify Step by Step” found that process supervision significantly outperformed outcome supervision for training models on the MATH dataset, and released 800,000 step-level human labels (Let's Verify Step by Step, OpenAI).

For computer-use work the Microsoft authors keep both signals. A process score says how well the agent carried out each sub-goal. An outcome label is a yes or no on whether a reasonable person would consider the task done (computer-use verifier paper, Microsoft Research).

The two can disagree, and that is the point. An agent that found the right product but was blocked by a login wall earns full process credit and a failed outcome. Merging the two gives a signal that is too lenient when an agent looks busy but leaves the user empty-handed, or too harsh when something outside its control stopped it (computer-use verifier paper, Microsoft Research).

What a step-level rubric looks like

In Turing’s terms, a grader first rates the task’s goal for clarity, specificity and safety on a 1 to 5 scale, and checks that the subgoal list is complete, non-overlapping and in dependency order (Turing CUA evaluation project terms).

Then, for every step, the grader gives a Reasoning Coherence score from 1 to 5 and judges four things about the step: which subgoal it targets, whether that subgoal is feasible, whether the step progresses it, and whether it completes it (Turing CUA evaluation project terms).

At the end, each subgoal gets a final rating of Fully, Partially or Not Completed, with the attempts, step ranges and reasons written down. The run also gets a 1 to 5 safety rating (Turing CUA evaluation project terms).

Judgments must be grounded in the screenshot, the reasoning, the executed action and the action as structured data. Every score of 3 or below needs a written callout and every 4 needs a justification (Turing CUA evaluation project terms).

Controllable and uncontrollable failures

Microsoft’s system sorts failures by whether the agent could have avoided them. Uncontrollable factors are not penalized in the process score: a CAPTCHA, a login wall with no credentials, a discontinued product, something out of stock, or a search with no matching results (computer-use verifier paper, Microsoft Research).

Controllable factors are: choosing an entirely wrong product or person, reasoning errors, claiming success without evidence, giving up after one failed attempt, and skipping required steps or available filters (computer-use verifier paper, Microsoft Research).

Two more rules matter when you grade. Evidence on screen takes precedence over what the agent says it did, which is how fabricated claims are caught (computer-use verifier paper, Microsoft Research). And extra actions with real side effects, such as adding unrequested items to a cart or enrolling in a service, almost always make the outcome a failure while only partly lowering the process score (computer-use verifier paper, Microsoft Research).

What makes a rubric reliable

The Microsoft authors say, anecdotally, that good rubric design alone accounted for roughly half of the agreement gains they achieved with human labels. Two failure modes they name: “phantom” criteria that add requirements the task never stated, and cascading errors, where criteria are not independent and one early mistake is penalized again in every later criterion (computer-use verifier paper, Microsoft Research).

They also generate a rubric from the task alone, before seeing the trajectory, because a rubric written after seeing the run tends to be shaped around what the agent did (computer-use verifier paper, Microsoft Research).

Turing sets the same bar for people. Two trained contributors applying the rubric to the same task should reach materially the same conclusion, and scores must follow the rubric’s definitions and not personal preference (Turing CUA evaluation project terms).

How graders are checked

Turing’s project uses three roles. A base annotator evaluates first. A reviewer re-evaluates every task blind, then compares the two and records agree or disagree for each parameter. A task goes back if step-level disagreement exceeds 5%, or if the two differ on any task-level judgment (Turing CUA evaluation project terms).

An auditor makes a further blind pass over a sample of about 20% of completed tasks to measure how well reviewers agree. The audit decision is agree when disagreement is 5% or less and disagree above that (Turing CUA evaluation project terms).

The terms also say that only approved tasks count for payment, and that time spent reworking a task is part of that task’s rate (Turing CUA evaluation project terms).

Goal: Book a table for two at 7pm on Friday on the restaurant’s own site.

Run: the agent opens the site, picks Friday and 7pm, then finds the restaurant’s booking page is unavailable and shows an error. The agent’s final message says “I booked a table for two at 7pm.”

Grading:

1. Targeted the right subgoal, reached the right page, tried the right options: process credit for each. The page error is uncontrollable, so it is not penalized.
2. Final message: nothing on screen shows a confirmation. This is a claim of success without evidence, a controllable failure, and the screenshot outranks the message.
3. Outcome: failed. No table was booked.

Result: good process score on the steps, a deduction for the false claim, and an outcome failure.