When the Agent Must Ask the Human

BrowserSkill's human boundary is not a single “allow automation” switch. This chapter explains two independent decisions: whether an agent may borrow an existing user tab, and whether it may ask the person to complete a human-only step. The distinction helps interpret confirmation, denial, timeout, continuation, completion, and disabled outcomes without turning a prompt into a secret-extraction path or treating a pause as proof that the larger task succeeded.

Borrow approval and human help answer different questions

Borrow confirmation is about browser ownership. When a task identifies a tab in an ordinary user window and needs to operate it inside the Agent Window, the browser's saved automation preference decides whether confirmation is required. The default is confirmation. The user can approve or deny through an in-page overlay or an operating-system notification, and the result governs whether the tab may move into the session's controlled space.

Human help is about task participation. A session may already control the correct tab and still reach a login form, a CAPTCHA, a payment confirmation, a consent dialog, or another step where the person should decide or act. The help request can focus the relevant Agent Window, display a prompt, highlight targets, and wait for the user to continue or finish. It does not give the agent a new tab, a new credential, or permission to bypass the user's decision. The agent remains bound by the same session and target rules before and after the pause.

The two preferences are stored independently. A user may require confirmation before borrowing but allow human-help requests, or may allow borrowing automatically while disabling help requests. That combination is meaningful: it says something about who may enter the user's existing tabs and something else about whether the agent may interrupt the person for assistance. A session can report the effective interaction policy to the daemon, but the policy comes from the browser settings rather than from an agent's private command-line intention.

This is why older unattended-style inputs cannot be treated as a universal override. Compatibility flags may still be accepted so existing clients do not fail at parsing, but the saved browser preferences remain authoritative. A flag that says “do not wait” cannot silently turn a confirmation-required browser into an auto-approval browser. The design places a consequential choice where the user can see and change it: in the browser's automation settings.

The distinction also prevents a common conceptual mistake. A user who approves a borrow has authorized a change in tab ownership, not the contents of every future action. A user who completes a CAPTCHA has supplied a human step, not necessarily approved a later payment or submission. Conversely, an agent that receives a disabled help result has not been denied all browser work; it has been told that this particular human-help route is unavailable and should continue only with existing tools and authorization.

The settings matrix is useful precisely because none of its combinations collapses the two questions. With borrow confirmation on and help on, a task may need two different user-facing moments.