Recommended shape
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
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.