VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

What it claims

VeriCUA, from Google and the University of Hong Kong (arXiv v1, 29 October 2026), checks whether a computer-using agent actually finished a task. It does this by running a verifier agent that gathers evidence, instead of a single VLM pass over frames or one generated script. The verifier can return success, fail or abstain, so it can decline to judge when evidence is insufficient. The authors report three findings beyond baseline agreement. In the online study it rejects more false completion claims than a VLM judge. Adding code-based state reads allows more decisions without more false positives. At a matched number of verification passes, adding visual evidence improves agreement and decision coverage more than repeating the same configuration. The fetched text gives no numbers for any of these.

How it works

1. Context inspection. Before writing a rubric, the verifier explores the setting. Online, it finds app packages, directories and database schemas. Offline, it reviews recorded steps, frames and accessibility trees.
2. Rubric synthesis. Each requirement is marked hard (mandatory) or soft (extra check). Hard requirements must follow from the instruction. A discovered location, such as Markor's notes folder, is a place to look for evidence, not a new success condition.
3. Active exploration. The verifier picks checks for unresolved requirements and stops when the hard requirements are settled or its inspection budget runs out. Each requirement ends as met, unmet or unknown.
4. Rule-based arbitration. Explicit evidence rules turn the findings into a verdict and keep a record of which requirements were supported, refuted or unresolved.

Evidence comes from three views. The trajectory holds frames, the action log and agent reasoning. The surface is a fresh screenshot or UI dump of the live machine. Persisted state covers files, app databases, settings and system services. GUI tools (get_frame, zoom, OCR, read_a11y, screenshot) work in both settings. Code tools (find, read_file, sqlite_query, dumpsys, settings_get) work only online.

Online, the verifier can also write a "checker": a set of permitted reads plus a predicate. Structured predicates run in a restricted evaluator, and visual or semantic predicates use a model judgment. A harness, not the model, tags each read with its source attributes, such as frame timing and whether the state persists. Volatile surface evidence corroborates other findings. It decides a requirement alone only under a stricter agreement rule. The agent's own "done" claim never counts as evidence.

The paper's two worked examples show the approach. An Android Markor note task passes after 10 reads and 16 checkers, including a file_stat showing the file was modified after the run began. A GIMP contrast task on Ubuntu, verified offline, fails because a zoomed frame shows unsaved changes, despite the agent reporting completion.

Limits

The fetched text ends in the method section. It does not name the evaluation benchmarks, the backbone models, the baselines beyond "VLM judge" and "generated verifier", or any agreement figures. Inspection cost and budget size are also not stated. The page mentions no code or release. The tool inventory is said to be in Appendix A.2, which was not retrieved. Code tools need live machine access, so offline verification falls back to GUI evidence only.