Computer-use agents need checks before every consequential action

What the current interface requires

Anthropic’s computer-use documentation describes batches of actions executed in order. Execution stops at the first failure, but every requested action still needs a result, including skipped actions. Where confirmation is required, the application should check before each action block runs.

The documentation recommends restricted privileges and network access, and warns that webpage or image content can misdirect the model. Prompt-injection defenses do not remove the need for these precautions.

Source: Anthropic computer-use documentation

Editorial interpretation

An illustrative batch with two decisions

Imagine a synthetic expense workflow that opens a draft, fills a reimbursement amount and submits it. This is an editorial example, not a tested product behavior. Reading the draft and submitting a claim have different consequences, even when they appear in one model response.

Our proposed review screen would show the employee, amount, destination and action to be approved. Approval of a draft preview should refer to those specific values. If the destination or amount changes before execution, the application needs a way to recognize that the pending action no longer matches the reviewed one.

Consider an interruption after entering the amount but before submission. The next attempt should first establish what was saved or submitted. A screen that appears unchanged does not tell the operator whether the external system received the earlier request. The workflow needs an explicit place to record that uncertainty.

Editorial implications, not an independently measured result.

Editorial interpretation

Design a useful trial environment

For this proposed test, create synthetic expenses and a destination that cannot transfer money. Put an obvious submission identifier in the resulting record. Then deliberately fail the navigation step, change a draft field and interrupt the task near submission. Inspect the records left behind, not just the sequence shown in a recording.

The test should answer concrete operational questions: can the reviewer identify the pending action, can the system avoid continuing from an unexpected screen, and can someone determine whether submission occurred? Record any manual cleanup needed. A workflow that is recoverable only by its developer has an unresolved support requirement.

Also test a refusal path. If the destination is outside the allowed set, the useful result is a clear stop with enough context for the operator to investigate. Do not count every stopped task as an error; some stops preserve the boundary the user requested.

Editorial implications, not an independently measured result.

Editorial interpretation

Give recovery a place in the design

Our suggested handoff record contains the last confirmed operation, the intended next action and the evidence needed to resume. Keep the person reviewing the work separate from the model’s own completion statement. This gives an interrupted workflow an owner and a starting point.

Before expanding access, compare the successful path with the interrupted cases. The deployment decision should account for review time, recovery effort and the consequences of a mistaken action. A polished desktop demonstration offers little help with those costs unless the difficult cases are included.

Editorial implications, not an independently measured result.

The comparison

The table scrolls horizontally on smaller screens.

Read alongside Anthropic computer-use documentation.

Your next decision

Which exact action needs approval in your workflow, and how would you determine its outcome after an interruption?