Agent classes / Browser agent / Self-host browser automation
Self-host browser automation for a browser agent
Updated 2026-10-27 (newest stored date on this page) · score asOf 2026-09-14 (stale)
The class: Completes a task by reading and operating a website in a browser, then stops before a consequential submit unless confirmation exists.
- Confirmation before submit, pay, or send
Depot Pick: Steel.dev
When not to use it: No ops — Browserbase.
Runner-up: Browserless.
Cheapest matching sourced SKU (usd_per_browser_hour): Steel.dev Scale browser hours $0.08 — source, asOf 2026-10-03. All sourced prices
Failure modes this class and job share (11)
- Non-determinism: Run the task more than once and compare the end state, not a single transcript. Record the trial count next to any success rate you cite.
- Benchmark protocol mismatch: Store assisted-or-not, subset, and harness version beside every cited score. Refuse a ranking that mixes those fields.
- Collateral side effects: Snapshot the workspace or app state, then diff it against an allowlist. A passing check plus an unexpected diff is a failure.
- Confirmation skip: Gate those tool names on an approval id recorded before the call. A missing approval is a failure even if the downstream tool returns success.
- GUI grounding miss: After each GUI action, compare the resulting screen or accessibility tree to the control the plan named. Stop when they differ.
- Hallucinated tool arguments: Reject a call that fails the current schema or names an unknown id, and do that before the tool runs a side effect.
- Instruction drift: Restate the stop condition in the trace. End the run when it is met. Review long traces for steps that do not serve the original task.
- Over-refusal: Log refusals separately from successes. Review a sample against the written policy. Do not treat a refusal as a pass, and do not weaken a safety check to raise the pass rate.
- Partial tool success: Require a per-item status and a failure count. Success for the task requires the failed count to be zero or explicitly handed to a retry queue.
- Prompt injection: Compare each tool call to the original user task. If the call only makes sense given text that arrived from a fetched page, file, or message, stop and ask. Record which source the instruction came from. This catalog does not store payloads or attack steps.
- Tool loop: Hash the last several tool names and arguments. Stop when the same call repeats and the observation did not change. Cap tool calls per task.