How to Evaluate Computer-Use Agents Beyond Task Completion

A computer-use agent can watch a screen, operate a browser or desktop, call tools, and change real application state. That makes an impressive demo easy to recognize—and a dependable system surprisingly hard to measure.

A single “task completed” score hides important differences. One agent may reach the target cleanly. Another may submit a duplicate form, expose private data, ignore an unexpected warning, or finish by taking a shortcut that violates policy. Both can receive the same final score if the evaluator checks only one field.

Public benchmarks established useful foundations. WebArena introduced realistic, reproducible websites with functional task validators. WorkArena moved toward common knowledge-work tasks in enterprise software. OSWorld expanded evaluation to 369 tasks across real operating systems, web and desktop applications, file operations, and multi-application workflows.

These benchmarks answer important capability questions. A production acceptance suite must go further: it should model your applications, permissions, policies, failure costs, interface changes, and recovery expectations.

Define a Task as a State Transition

Do not score a list of clicks. Specify the intended transition:

given: initial application state + actor identity + instruction
when: agent observes and acts within allowed capabilities
then: required post-conditions are true
and: prohibited side effects are false
and: evidence is sufficient to verify both

For an expense-submission task, the contract might require:

• The correct receipt is attached to the correct report.
• Merchant, date, currency, tax, amount, and category match the source.
• The cost-center assignment is permitted for the active employee.
• A policy exception is visibly flagged.
• The report remains a draft until the named approver confirms.
• No duplicate report, message, attachment, or payment is created.
• No unrelated employee or report is opened.
• The audit trail links source receipt, extracted fields, agent actions, and final record.

This contract separates outcome, authority, safety, and evidence. It also permits multiple valid action paths. The agent should not fail merely because it clicked different controls from a human-authored trace.

Model the Initial State Precisely

Computer tasks are stateful. A result is not reproducible unless the starting state is reproducible.

Capture:

• Application and operating-system versions.
• Locale, timezone, number and date formats, theme, zoom, display size, and accessibility settings.
• Authentication state, role, tenant, and granted scopes.
• Relevant database fixtures, files, inbox messages, and browser storage.
• Network conditions and available external services.
• Window order, open tabs, focus, and active application.
• Known pop-ups, consent banners, update notices, and expired sessions.
• Clock and effective policy version.
• Allowed GUI actions, APIs, scripts, and MCP tools.

Use disposable environments and reset them between trials. A failed run can otherwise contaminate later trials by leaving a draft, changing a preference, accepting a cookie banner, or incrementing an identifier.

OSWorld’s use of initial-state setup and execution-based evaluators is a strong pattern. But your acceptance environment should also reflect organization-specific roles and controls. A benchmark run as an administrator does not validate the least-privilege employee experience.

Score Six Dimensions, Not One

1. Functional outcome

Did all required post-conditions become true? Prefer direct state inspection—database, API, file checksum, or application record—over a screenshot that merely looks correct.

Use partial credit only when it corresponds to meaningful business progress. Opening the correct page is not 50% of making a compliant payment.

2. Side-effect integrity

Did anything else change? Define negative invariants such as:

• No extra message was sent.
• No unrelated file was modified.
• No permission was broadened.
• No irreversible action occurred before approval.
• No duplicate record was created.
• No sensitive content appeared in logs, clipboard, URL, or third-party tool input.

This dimension prevents an unsafe shortcut from being scored as a success.

3. Policy and intent adherence

Did each consequential action remain within the user’s instruction and the actor’s authority? A technically possible action may still be out of scope. Preserve the original instruction and compare tool actions to it throughout the run.

Human approval design explains how to place confirmation at the boundary where a decision becomes costly or irreversible.

4. Recovery and escalation

Can the agent detect a stale session, moved control, changed record, conflicting instruction, missing dependency, or ambiguous identity? Score:

• Correct diagnosis of the obstacle.
• Safe retry or alternate path.
• Idempotent resume without duplicate side effects.
• Useful request for missing information.
• Timely escalation rather than repeated guessing.
• Preservation of completed work and evidence.

An agent that safely stops may be better than one that completes more tasks through unbounded improvisation.

5. Evidence and explainability

Can a reviewer reconstruct what the agent observed, decided, and changed? Record observation references, selected action, arguments, tool response, resulting state, approval event, and post-condition result. Sensitive data can be masked while preserving identifiers and structure.

6. Efficiency and experience

Track task time, model and tool latency, number of steps, retries, tokens, cost, user interruptions, and unnecessary UI exploration. Optimize only after correctness and safety. A two-second shortcut that doubles duplicate submissions is not an improvement.

Safety Must Be Evaluated Alongside Capability

Capability benchmarks often ask whether the agent can reach a goal. Safety evaluations ask whether it refuses harmful goals, resists malicious context, and avoids unsafe paths even for benign instructions.

The 2025 OS-Harm benchmark adds computer-use tasks covering deliberate misuse, prompt injection, and model misbehavior. The 2026 OSGuard preprint makes another crucial distinction: an agent can achieve the nominal task through an unsafe shortcut, so evaluators need explicit state-based safety invariants in addition to the original success condition.

Build safety variants from ordinary tasks:

• A filename collision where overwrite would destroy an unrelated document.
• A webpage containing an instruction to upload confidential data.
• Two contacts with similar names, only one authorized.
• A payment form whose amount changes after a refresh.
• A hidden or off-screen destructive confirmation.
• A request that is feasible only with broader permissions than the user granted.
• A legitimate task with a suspicious request to disable security controls.
• A workflow where the safest outcome is a draft, not final submission.

Test both action-level judgment and end-to-end behavior. A guard may classify an isolated action correctly yet fail to stop a harmful sequence of individually plausible steps.

The OpenAI Operator system card is a vendor-specific example of evaluating prompt injection, mistakes, prohibited actions, confirmations, and third-party red teaming for a computer-using model. Use system cards as inputs, not substitutes for workflow-specific testing.

Add Real Interface Variation

An agent that memorizes one layout is not robust. Vary:

• Desktop and mobile viewport.
• Light, dark, high-contrast, and increased-text modes.
• English, Persian/RTL, and mixed-script content.
• Different date, decimal, currency, and digit formats.
• Keyboard navigation and accessibility-tree differences.
• Reordered lists, pagination, lazy loading, and virtualized tables.
• Pop-ups, notifications, banners, and overlapping windows.
• Slow rendering, partial loading, and stale DOM snapshots.
• Similar icons, labels, filenames, and contact names.
• Minor version changes and feature flags.

Include metamorphic tests: change a detail that should not affect the decision, such as window position, and verify the outcome remains stable. Then change one material fact, such as recipient or amount, and verify the agent notices.

For Persian workflows, do not stop at translated labels. Test RTL geometry, Persian and Arabic digits, right-to-left cursor behavior, mixed Latin identifiers, calendar conversion, and copy/paste normalization.

Test Interruptions and Recovery Deliberately

Production interfaces fail midway. Inject:

• Authentication expiry after data entry.
• A 429 or timeout from a tool.
• A record changed by another user.
• A file upload that completes after the UI times out.
• Browser crash or lost network.
• A modal that blocks a later action.
• An approval declined or modified.
• A tool response with incomplete or malformed data.

The evaluator should know whether the original action actually committed. Give the agent an idempotency key or reconciliation path where appropriate and score whether it checks before retrying.

The distinction between “request failed” and “business state unchanged” is essential. A payment API timeout may occur after the payment committed. Blind retry turns a recoverable ambiguity into a duplicate transaction.

See durable agent workflows for checkpoint and resume patterns.

Use Multiple Graders With Clear Authority

No single grader is sufficient.

Deterministic state graders

Use APIs, database queries, files, checksums, and structured logs for exact post-conditions and negative invariants. These should be the primary authority where available.

Rule-based trajectory graders

Check prohibited domains, out-of-scope tools, missing approval, duplicate calls, dangerous argument patterns, and access to unrelated objects.

Model-based graders

Use them for ambiguous semantic quality, communication usefulness, or whether an escalation adequately describes missing information. Calibrate against human labels, blind the grader to vendor identity, and do not let an LLM judge override a contradictory system-of-record check.

Human expert review

Use for high-impact cases, new failure categories, policy interpretation, and regular samples of both passes and failures. Record reviewer disagreement; it often reveals an underspecified task rather than a model problem.

NIST’s 2025 note on cheating in AI agent evaluations recommends standardizing benchmark-specific affordances and restrictions. In practice, document exactly which network, files, tools, hidden tests, and external help are allowed so two scores are comparable.

Preserve a Replayable Trace Without Creating a Data Leak

For every run, record:

evaluation_version
environment_snapshot
actor_and_permissions
original_instruction
observation_reference
action_and_arguments
tool_or_ui_result
state_delta
approval_event
grader_outputs
final_post_conditions

Store screenshots or video only when necessary and apply masking at capture time. Prefer structured state diffs over indiscriminate screen recording. Keep secrets, payment details, personal contact information, and unrelated records out of model-visible and reviewer-visible traces.

Trace versioning is critical. A replay should identify the model, prompt, policy, tool schema, application build, evaluator, and dataset revision. Otherwise a regression may be caused by the environment rather than the agent.

Agent observability covers production tracing in more depth.

Report Statistics That Reflect Deployment

One run per task is rarely enough. Computer-use agents are nondeterministic and environments fluctuate.

Report:

• Success, safe-success, and unsafe-success separately.
• Pass-at-one and repeated-trial reliability.
• Confidence intervals, not only point estimates.
• Results by task family, risk tier, application, language, and interface variant.
• Recovery success conditioned on each injected failure.
• Human-intervention frequency and quality.
• Tail latency and cost, not only averages.
• Regression against the currently deployed version.

Weighting should reflect real volume and consequence. A rare payroll or deletion task may deserve more release authority than hundreds of harmless navigation tasks. Keep a public benchmark score separate from the internal go/no-go score.

Turn Production Incidents Into Regression Tests

The best acceptance suite evolves:

1. Capture a production correction, near miss, or incident.
2. Remove or synthesize sensitive data while preserving the failure mechanism.
3. Reproduce the initial state in a disposable environment.
4. Add positive post-conditions and negative safety invariants.
5. Verify the test fails on the defective version.
6. Add variants so the agent cannot memorize one screenshot.
7. Require the repaired version to pass before release.

Also sample successful runs. Hidden rework by users, unnecessary disclosure, or incorrect reasoning can be missed when the final state happens to look right.

A Production Release Gate

A practical release process has four layers:

1. Offline regression: deterministic fixtures across normal, edge, recovery, multilingual, and adversarial cases.
2. Sandbox shadowing: the agent observes real-like work but cannot cause external effects.
3. Approval-gated pilot: reversible actions for a small group with full trace review.
4. Limited autonomy: only for task classes with stable safe-success, bounded permissions, idempotent execution, and monitored rollback.

Rollback should be triggered by unsafe-success, cross-scope access, duplicate side effects, approval bypass, or unexplained degradation—not only by lower average completion.

The guide to computer-use automation helps identify suitable first workflows; browser-agent security covers the attack surface.

Frequently Asked Questions

What is the single most important metric?

For consequential work, safe task success: all required post-conditions are true and all prohibited side effects are false. Report ordinary completion beside it, not instead of it.

Should we compare agents by number of clicks?

Only as a secondary efficiency measure. Different valid paths can use different numbers of steps. Outcome, safety, permission adherence, and recovery matter first.

Can screenshots prove success?

Rarely by themselves. They may show UI state but miss hidden database state, duplicate records, wrong permissions, or changes in another application. Prefer direct post-condition inspection.

How often should the suite run?

Run a focused gate on every change to model, prompt, policy, tool schema, application UI, or evaluator. Run the broader stochastic and adversarial suite on a scheduled basis and before expanding autonomy.

Sources and Review Date

This article was substantially reviewed on July 30, 2026 using:

• WebArena
• WorkArena
• OSWorld
• OS-Harm
• OSGuard
• NIST: Cheating on AI Agent Evaluations
• OpenAI Operator System Card

A production task bench is not a leaderboard. It is a controlled model of the work, the damage a wrong path could cause, and the evidence required to trust the result.