Skip to main content
Treat an agentic web workflow as an inspectable job. A production workflow should create or reuse a managed browser, run the agent inside a clear policy boundary, store the result and evidence, then decide whether the browser should close or continue.
1

Create a job

Store the user request, target URLs, policy boundary, timeout, and output shape in your application.
2

Run browser work

Use web.agent() for the agent-driven browser work. Use SDK resources around it for setup, validation, downloads, recordings, retries, and recovery.
3

Capture evidence

Store the final result, browser ID, status, artifacts, downloads, recordings, events, and redacted errors that matter for review.
4

Handle retries

Retry transient infrastructure or timeout failures with a fresh browser when needed. Do not blindly retry policy denials, approval denials, or blocker states.
5

Clean up

Close browsers your application creates unless the workflow intentionally needs continuity.

Browser-agent job

Browser-agent job with deterministic resources

For existing-browser runs, configure browser policy on web.browser.create(...), not on the agent. Agent-level browser policy applies when the agent creates the browser.

Deterministic browser job

Use exact browser-code execution when a specific step must be deterministic or an existing browser framework owns the task.
saveJobResult represents your application’s persistence layer.

What your app should own

Webcompute runs browser sessions and returns evidence. Your application should own queueing, job IDs, user authorization, result persistence, retries, notifications, and any human review workflow.

User-visible job states

Map browser evidence into a small set of product states your users and operators can understand. Do not turn blocked, needs_confirmation, policy denial, or CAPTCHA state into completed. Store the evidence and return the next safe action.

What to show after a blocker

When a browser job stops on a blocker, show:
  • The target site or final URL.
  • The blocker category when available.
  • The last safe status.
  • Whether a recording, screenshot, artifact, or download is available for review.
  • A retry or human-review option only when it is safe.
Do not expose signed Debug UI URLs, signed CDP URLs, cookies, provider keys, or raw page observations to end users by default. Reference: policy and proxy, observability, errors and retries, and limits.