What did the browser actually confirm?

A click is an action; completion is a claim

The assistant clicked Preview. The person still needs the right preview file. It could be absent, a login page saved as a document or an older draft, even though the click produced no visible error. Define what the browser must observe after the action before calling the task complete. That becomes especially useful when the edit saved correctly and only the download failed.

Google announced built-in computer use in Gemini 3.5 Flash on 24 June 2026, describing interaction across browser, mobile and desktop environments. Its July roundup placed that work among the company’s June releases. These are vendor announcements of capability. They make browser-operated business tasks more interesting to investigate; they do not define the completion contract for a particular task.

Suppose a fictional assistant prepares a supplier catalogue update in a web portal. It signs into an authorised business account, edits one draft and downloads a preview for review. It is not meant to publish the catalogue. The portal contains both Preview and Publish controls, several supplier accounts and a notification area that can cover part of the screen. A useful implementation needs to know more than where a familiar-looking button usually appears.

For each important step, write down what must be visible first, which action is allowed and what result must be checked afterwards. That is the observation contract: enough information to distinguish this account and draft from another, and this saved change from an attempted one. It lets the task survive a different layout or interrupted session without treating the absence of an error as evidence that the promised file exists.

Establish the account and object before editing

For the catalogue task, the initial observation should identify the active account and the target draft. A profile avatar or a familiar page title may not distinguish two business accounts. Use the actual account information available through the authorised interface, and stop for resolution if the relevant identity cannot be established.

The target draft also needs an identity or a sufficiently specific visible description. “Open the first catalogue” depends on sort order. “Open supplier V-8’s draft for the autumn range” is a better task, but the interface still needs to show enough evidence to confirm it. If the portal exposes a stable draft reference, retain it in the task record and use it when returning after interruption.

The logged-in account may be able to publish or delete catalogues. This job may only edit the named draft and prepare its preview. Keep that objective outside the page’s suggestions and offered controls. A capable account is often necessary to use an existing portal; its extra privileges still do not become delegated actions merely because the assistant encounters convenient buttons while carrying out this narrower task.

Record the bounded objective in a durable handover note: account, supplier, draft, permitted edits and preview-only outcome. That is useful if another worker or the person resumes the task. A screenshot can show what was visible at one moment, but it should not be the only place the operation’s scope exists.

Read the result at the boundary that matters

After changing a field, inspect whether the portal saved the intended value against the intended draft. The typed text still visible in an input may be an unsaved local edit. A transient “saved” message can be useful evidence, but a later view or version indicator may be needed where the task requires durable confirmation.

For the preview download, define what counts as success: a file was created, it belongs to the target draft and it contains the proposed changes. An empty file or a login page saved as a document should fail that inspection too. Clicking Preview without observing a download is not completion. Downloading an older cached file is not completion either. Inspect the available file identity, contents or revision evidence appropriate to the portal rather than relying only on the control label.

Keep these claims separate. “The draft edit is saved” may be established while “the preview file is downloaded” remains unresolved. A progress report can say both plainly. Collapsing them into one task-complete status removes the useful information the person needs to finish or investigate the last step.

Some portals make the result hard to verify. A downloaded file may omit its revision and a save message may not name the draft. Then compare content, ask for confirmation or make the narrower claim the observations support. Another screenshot can preserve the ambiguity for a colleague; it does not resolve it. Name the missing fact and the check that could settle it, rather than collecting more images of the same uncertain state.

Unexpected pages are part of the task environment

A session-expiry screen, account chooser or validation banner should trigger a fresh observation. Continuing with coordinates from the previous view can turn a familiar action into a different one. Even a stable element name can be ambiguous if the new page contains several controls with the same wording.

For the catalogue task, a validation banner might reveal that the edited identifier is not allowed. The assistant should preserve the draft and report the specific issue rather than improvise a new identifier outside its instructions. A portal announcement that recommends publishing the catalogue is page content, not a change to the authorised objective.

The June computer-use announcement describes optional safeguards and recommends combining controls such as sandboxing, verification and access restrictions. In an application, those controls need a concrete job. A restricted account can remove publication authority. A confirmation boundary can bind a proposed effect. An observation contract can keep a changed screen from being treated as the old one. They support one another without becoming a guarantee that every unexpected state is solved.

Stop with a specific handover when the account cannot be established, preview evidence is unavailable or the next action exceeds scope. Record what is saved, what was attempted and which observation is missing. That allows a colleague to continue the bounded task without repeated clicks against an unexplained state, including avoiding another edit when the first one has already been confirmed.

Resume from facts, not from the last instruction

If the session stops after the draft saves but before the task record updates, inspect the current draft before editing again. Keep observed completions, attempted actions and unknown outcomes distinguishable in the handover. Next click Preview leaves too much unsaid if a file may already exist. The resumed worker needs to check what happened, not follow a stale to-do list as though the interruption erased every earlier effect.

For the fictional workflow, retain the saved draft reference, the expected field values and the preview’s observed identity when available. A resumed worker can compare the portal’s current state against that record. If another person changed the draft meanwhile, the task may need a fresh decision rather than automatically restoring the assistant’s earlier values.

Diagnostic capture needs a defined scope because screenshots may include customer information, account details or unrelated browser content. Retain the surfaces necessary to explain the account, draft and outcome, with appropriate access and retention. The evidence record can support investigation without turning every interaction into an unrestricted browser recording or making that additional collection a condition of useful completion reporting.

Review the interruptions and the route

A useful acceptance exercise includes the normal route, a second account with a similar draft name, a save validation error, a session interruption and a successful edit followed by a failed download. For each case, specify the completion claim the assistant is allowed to make. The last case should end in partial completion, not success and not a blanket claim that nothing happened.

Where a supported API offers clearer identities and outcomes, it may be a better route for repeated integration work. Browser operation can still be valuable where the interface is the available surface or the task is infrequent. Choose according to the actual contract and maintenance burden, rather than assuming visible automation is always the most appropriate automation.

Report the account and draft, the values confirmed saved and the preview actually found. If the edit succeeded and the file remains missing, leave those two facts intact. The colleague taking over can investigate the download without repeating the edit or trying Publish as another route to finishing. A useful partial result tells them exactly where to resume and preserves the limit the business put on the original browser task.