A confirmation screen can show that a request was accepted without proving the required business result exists. Define completion evidence before the agent starts: the correct record and state, an authoritative operation result, or an inspected export. Compare that evidence with the accepted brief. If processing is pending or verification fails, report that specific state and reconcile the outcome before retrying or announcing success.
Define what the business means by complete
For a report task, completion might mean that the correct period and entity are present in an inspected file. For a service-request task, it might mean that the requested draft exists under the right customer record. These are different evidence requirements. A generic rule to look for a green message does not establish either result.
Write the expected state in the brief alongside the task’s boundaries. If the approved scope ends at preparing a draft, a submitted request is not a better result. If staff approval is still required, the agent must not announce that the overall business process is finished simply because its preparation step succeeded.
Identify where the reviewer can observe the authoritative state and what access is needed. If the portal provides no suitable readback or operation view, record that limitation before the pilot. Do not silently turn a weak screen message into stronger evidence because verification is inconvenient.
Interpret the screen according to its actual meaning
A message such as request received can mean that a system has queued work. A download notification can mean that bytes reached a folder. A saved banner can refer to the last edited field rather than the complete record. Capture the wording and context, then compare them with the system owner’s accepted interpretation.
Source: OpenAI function calling describes a model requesting a tool and application code executing it before returning a result. This distinction is useful when designing the proposed verification process. A request or attempted click should not be reported as a verified outcome.
Keep an observed screen reference if it helps locate the operation later, but check what that reference identifies. A request identifier, job identifier and final document number can belong to different stages. Record the relationship where the system supports it rather than assuming they are interchangeable.
Account for asynchronous processing
Source: Stripe webhook documentation instructs webhook endpoints to return a successful response quickly before complex downstream logic. It is a documented example of acknowledgement being separate from later work. It does not establish how your portal behaves or recommend a payment provider for a particular business.
Ask the portal or integration owner which stages are asynchronous and where final state can be checked. A request may be accepted while a report is still being generated or a business record awaits processing. Represent those stages explicitly in the task status, with an owner for verification.
Agree an observation and escalation policy suited to the operation. Avoid inventing a universal waiting period. If the agreed check cannot establish completion, leave the task pending or uncertain and explain the evidence needed next. Repeated refreshes do not become a substitute for a supported status view.
Compare the output with the accepted brief
Read the actual record fields or inspect the file contents required by the brief. Identity, account context, period, quantity and status may matter in different workflows. The reviewer should be able to see expected and observed values, not just a model-generated sentence saying they match.
Source: OpenAI Structured Outputs supports schema-constrained response fields. A proposed completion receipt can require outcome, evidence reference, observation time and unresolved questions. A valid receipt structure does not prove that the underlying record exists or that a comparison is accurate.
Keep partial evidence precise. Finding the correct draft establishes existence, but it may not establish that all required fields are populated. Verifying a report filename does not establish its contents. Avoid inflating a useful partial check into a complete acceptance decision.
Browser-task completion evidence checklist
Task reference: ______ | Accepted brief/version: ______ | Evidence reviewer: ______
| Check | Evidence to record | Accepted result or unresolved owner |
|---|---|---|
| Attempt | Requested action, account, target and attempt time | Distinguish intention from execution. |
| Screen response | Exact visible status and reference, where supplied | Interpret only what the screen establishes. |
| Authoritative state | Actual record, operation status or inspected export | Confirm identity and the required final state. |
| Content match | Fields or file contents compared with the brief | Show mismatches and unknown fields explicitly. |
| Asynchronous work | Processing status, pending steps and verification route | Pending remains pending; name the next owner. |
| Uncertain outcome | Last known step and repeat-action risk | Reconcile before retrying or announcing success. |
| Duplicate check | Existing matching work and earlier attempt reference | Do not treat another click as an independent task. |
| Freshness | Verification time and relevant version | Recheck changed state rather than reusing an old receipt. |
| Final decision | Accepted, rejected, pending or uncertain | Record reviewer, evidence reference and next action. |
Completion rule: a reviewer can connect the accepted brief to the actual output and explain every remaining limitation. If required evidence is unavailable, the task remains pending or uncertain instead of receiving a success label.
Work through confirmed, pending and misleading results
Consider a hypothetical internal service task. The agent prepares a draft under customer reference TEST-CUSTOMER-C. A banner appears and the permitted record view shows the draft under that same customer, with the required issue category and unsubmitted status. The reviewer accepts draft preparation. The record does not imply that a customer was contacted or the issue was resolved.
In a second hypothetical case, the portal displays report requested and provides a processing reference. The output file is not available yet. The agent records a pending result and hands the verification reference to the responsible operator. It should not announce that the report has been downloaded.
In a misleading-export case, the browser downloads a file named like the report, but opening it reveals a sign-in page. The file check rejects it. The original request may still exist in the portal, so the operator investigates its state before issuing another request. A failed download check does not establish that the earlier generation request failed.
An ambiguous identity case is also important. The portal shows a completed record with a similar customer name but a conflicting account reference. Treat the match as unresolved. The reviewer must establish identity through the accepted fields rather than accepting the closest-looking record.
Recover without duplicating completed work
A timeout can occur after the system performed the action. Preserve the attempt reference and last verified step, then inspect for matching work before retrying. If a reliable match cannot be established, the owner should investigate under the accepted recovery process. A new attempt should not erase the first uncertain outcome.
When another person completes the task manually, record that evidence and stop the agent’s pending action where the supported workflow permits. Otherwise both paths may produce work. The task history should identify who completed which step and which result was accepted.
Test duplicate requests, delayed processing, missing evidence, wrong-record matches and changed values in a controlled pilot. Assess whether the final status tells staff exactly what is known. A process that handles uncertainty clearly can be more useful than one that produces a confident success message for every screen transition.
Retain the minimum evidence needed for that decision, with access and handling rules approved by the information owner. Full screenshots and complete account histories are not automatically necessary. A restricted record reference and relevant field comparison may support the same review with less unrelated information.
FAQ about completion evidence
Is a green confirmation banner reliable evidence?
It is evidence of the specific screen response. Its meaning depends on the operation. Define the required final state and check an authoritative record, status or file before treating the business task as complete.
What if the action probably worked but the record cannot be checked?
Report the outcome as uncertain and preserve the attempt evidence. Do not convert probable success into confirmation or probable failure into an unchecked retry. The designated owner should reconcile the actual system state.
Does an accepted draft mean the customer’s request is resolved?
No. Draft preparation and resolution are different stages. State which stage was verified and who owns the remaining action. The completion rule must follow the approved task scope rather than the agent’s optimistic interpretation.
If your business needs help scoping this workflow, explore Custom AI agents, our AI automation services, and the custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the options. To discuss your systems and approval rules, get in touch.