Handle approvals, failures, changed pages, time limits, fallback behavior, and plan boundaries for browser-assisted conversations.

A bounded action has explicit outcomes

What happened after the browser request?

Approved and completed

The current browser session returned a result.

Then: Verify and continue

Denied or blocked

The visitor or domain boundary prevented execution.

Then: Offer a manual alternative

Failed, timed out, or changed

The result is incomplete or unsafe to infer from.

Then: Stop and retest a bounded flow

Denial, failure, timeout, or a changed page means stop, explain, and offer a safe fallback.

Run Pro Agents as supervised, page-specific assistance. A correct setup expects that some requests will be denied, time out, fail, or become unsafe as a page changes.

Operating flow

Prepare one bounded actionUse knowledge and safe page context to propose a single next step.
The request should state its target and expected effect.
Let the visitor review itPage-changing and navigational actions visibly wait for approval.
A denial is a valid outcome, not permission to retry automatically.
Execute in the current sessionUse only the approved request and return its actual success or error result.
A timeout never means the action completed.
Audit before expandingReview stored tool-call and result metadata before widening a flow.
Deletion-pending conversations are excluded from this stored metadata path.

The browser bridge associates tool requests with the visitor session and waits only for a bounded result. A timeout never means the action completed.

Write the agent instructions so that it can answer normally without browser execution, identify a manual page path, and offer human support when the action cannot be safely completed. Do not set an instruction that treats a browser result as proof of payment, eligibility, identity, legal consent, or another high-impact decision.

Keep a rollback simple: downgrade the assistant to Standard to remove Pro browser tools, make the assistant inactive if needed, and remove inappropriate domains from the project configuration. Do not depend on silently changing a visitor's active browser state as a mitigation.

Plan and rollout gates

Only projects whose active plan includes website action agents can enable Pro mode. The project must have usable allowed domains. Public demos do not support Pro Agents, and enabling Pro mode is rejected while an active demo exists for the assistant. Workspace users should use their ordinary dashboard permissions for configuration; this documentation does not grant a separate Pro Agent role.

Before every material rollout, test with a synthetic visitor and non-sensitive data; verify approve, deny, timeout, changed-element, disallowed-navigation, and fallback paths. Review tool metadata and visitor feedback after release, and disable or downgrade the agent if behavior leaves the intended boundary.

Last updated on

Situation	Runtime outcome	Recommended assistant/operator response
Visitor denies a request	The tool result is unapproved and returns “User denied tool execution.”	Acknowledge the choice; provide explanation, a manual alternative, or handoff. Do not retry automatically.
A page or selector changed	The browser may return an error or no useful result.	Stop the action chain, refresh page context, and ask the visitor before proposing a new bounded action. Fix the tested flow before wider use.
Navigation is outside allowed domains or otherwise disallowed	The request is blocked before browser execution.	Do not try to bypass the boundary. Offer a safe alternative or correct the controlled-domain configuration if appropriate.
Tool call or the browser sequence expires	The request returns a timeout error.	Explain that it did not complete; let the visitor retry or continue manually.
Result is incomplete	The agent receives partial page context.	Treat it as partial context; do not infer omitted information.

Pro Agent operations and safety

Operating flow

Expected failure modes

On this page