How do I verify what my computer-using agent actually did — not just whether its final answer looks right?

October 31, 2026 · 6 min read

SentX SI

The final answer is a claim about what happened, not a record of it. Verifying an agent's work means auditing the process record — the sequence of actions and observations it left behind — against the task's requirements, and treating the agent's own summary as one witness among several rather than as ground truth. That is exactly the gap addressed by VeriCUA (arXiv:2610.40578, Sun et al., submitted 29 Oct 2026), a preprint that treats verification as dynamic evidence gathering instead of a single read of a log. The paper is listed as work in progress, but its framing gives practitioners a concrete way to think about checking trajectories, and the reasoning translates to manual review even without running the framework itself.

Source: VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

When you delegate a multi-step task — filling a form, exporting a report, reconciling a spreadsheet — the agent's last message is usually a confident summary built from its own account of the run. Two things go wrong there. Summaries compress: skipped steps, retried steps, and quiet failures drop out. And even the raw trace is incomplete by nature, because screenshots capture only what was visible, and background tabs, server-side state, and files written outside the viewport never appear in an image. A plausible-looking final screen can coexist with an earlier step that was silently undone.

Source: VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

The partial-view gap

Automated verification hits the same wall, and that is where VeriCUA starts. Typical approaches, according to the abstract, prompt vision-language models to judge trajectories or generate programs to inspect application state. Both rely on partial views of complex digital environments: a VLM judge is restricted to the observations supplied to it, while a generated program depends on whatever state is accessible. Those views can omit decisive evidence or leave completion judgments unsupported, and tailoring a separate verifier to every platform and access setting adds engineering cost on top.

Source: VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

The practical takeaway for a reader: a green checkmark from an automatic verifier carries the same caveat as a confident final message. Both rest on a partial view.

Source: VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

What VeriCUA changes

VeriCUA is presented as a platform-agnostic framework for verification through agentic exploration. Rather than one fixed pass over the log, the verifier works inside a shared procedure that covers online and offline settings across platforms and observation modalities.

Source: VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

The mechanism comes in three moves. First, it inspects the available context and constructs a task rubric, breaking the original request into requirements that evidence can address. Second, it selects GUI or code checks for the requirements the record does not resolve, choosing whether to re-examine the interface or query state programmatically. Third, it combines the findings under explicit evidence rules, so the completion judgment follows stated logic instead of drifting with confidence.

Source: VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

The shift is that the verifier explores. Where a passive judge reads only what was handed over, this one gathers evidence actively — the move from a static read to exploration that the title points at.

Source: VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

What the results establish

At the level the abstract supports: experiments show improved agreement with reference labels over the compared baselines across these settings, with the largest offline gains on hard cases and stronger rejection of false completion claims online. Further analyses connect those gains to complementary evidence and test-time exploration. The abstract reports no numeric values, and the listing marks the work as in progress, so read these as directional results from the authors' own description, not settled benchmarks.

Source: VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

Notice the shape of the outcome: the strongest reported improvement is rejecting false completion claims, which is precisely the failure mode a practitioner feels when an agent says "done" and something is quietly wrong.

Source: VeriCUA: Verification as Agentic Exploration for Computer-Using Agents

How this differs from the other checks

This sits in a different slot from the other layers of agent oversight. Static checks catch configuration and environment problems before a run, and their documented weakness is that green static results can still fail in production. Trust-calibration work addresses what to do after receiving output — how much weight a confident answer deserves. Instruction-adherence tools such as DIAL set the strictness bar before a run. VeriCUA operates after the fact, on the record of what actually happened: it does not make the agent more obedient or you less trusting; it makes the process record auditable.

A protocol you can run on your own traces

The following is an editorial adaptation of VeriCUA's mechanism into a manual checklist. It is a suggested method, not a procedure measured in the paper, and nothing here establishes that any product implements it.

1. Before reading the trace, write the task's requirements down as a list of checkable items. Phrase each so evidence could confirm or contradict it — "a PDF named X exists in folder Y," not "the report was exported correctly."
2. Read the full trace, oldest step first. Mark each requirement as supported, contradicted, or not evidenced by the record. Do not resolve "not evidenced" into "supported" because the summary said so.
3. For each unresolved item, pick a check. If the environment is still reachable, re-examine the interface directly — the manual version of a GUI check. If you have programmatic access, query state instead — the manual version of a code check. Prefer whichever leaves a durable artifact, a saved screenshot or command output, that you can re-read later.
4. Decide by rule, not by feel. A reasonable default: a completion claim stands only if every requirement has at least one piece of positive evidence, and any contradiction overrides all support. Anything left unevidenced means the task is not verified.
5. File the findings next to the trace — which items passed, which failed, which stayed open — so the next run starts from a record rather than a memory.

To make the rule concrete: suppose an agent reports that it uploaded a quarterly report to a shared drive. The trace shows the upload dialog opening and a success indicator appearing, but no filename is logged, and the drive's file list, pulled afterward, does not contain the report. Under step 4, the indicator is one piece of evidence, the absence in the file list is a contradiction, and the correct verdict is that the upload is unverified — not done, not failed, open. That scenario is an illustration, not an observed incident.

The same discipline, applied to us

SentX's model card states plainly that answers can contain incorrect facts, citations, or calculations, and its known-limits section directs users to open cited sources and check the supporting passage. The instruction transfers almost unchanged to agent work: the trace is the cited source for what an agent did, and the supporting passage is the specific step that supposedly satisfied the requirement. Checking it takes minutes and removes the most common way a plausible answer hides a real gap. One boundary belongs at the point of use: under SentX's privacy policy, submissions are not confidential, so paste only traces and task details you are allowed to share.

Source: Victoria AI Model Card | Capabilities, Evidence and Limits | SentX SI