Choose an approval boundary
Human-in-the-loop can mean anything from watching a live screen to approving an exact operation. Our editorial recommendation is to define the specific event that requires review: sending a message, submitting a form, changing a financial record, sharing a file, or performing an action outside the original task scope.
Google’s computer-use guidance explains handling required confirmation decisions, and Anthropic calls for human confirmation for meaningful real-world consequences. An application must translate that guidance into enforceable behavior. A visual Pause button is useful, but it does not itself prove that the executor waits for approval.
Present a concrete review packet
Show the destination account and record, the proposed change, the values that will be sent, and the evidence used to prepare them. If there is a financial amount, make its currency and recipient visible. If there is a file, identify the exact artifact. Include what happens when the reviewer declines.
Avoid approval fatigue from asking for every harmless navigation step. Instead, define bounded preparation that is authorized in advance and a clear consequential boundary. Sensitive data may be transmitted before a final submit, so the approval point must reflect the application’s actual behavior, including autosave and live validation.
Prevent stale or reusable approval
An approval should be tied to a run, target, operation, and payload fingerprint. If the page refreshes to a different record or the draft changes after review, the earlier decision should not authorize the changed action. Expire abandoned requests and prevent a retry from reusing approval after the operation may already have succeeded.
For high-impact workflows, let the reviewer take over the final action directly or use a narrow execution service. Keep the agent from editing the review packet after approval. Store the decision separately from the model’s own explanation of why it believed approval existed.
Test the unpleasant cases
Test a declined request, an expired request, two reviewers opening the same request, an interrupted network connection, and an action that succeeds before confirmation is observed. Each should have a defined state. A timeout should not silently mean consent, and a lost confirmation should not automatically produce a second submission.
Measure review burden during the pilot: how often requests arrive, whether they include enough context, and how many reviewers reject. These measurements help adjust task scope. They do not justify removing review simply to improve completion metrics. The aim is a workflow whose authority remains understandable to its operator.