The Browser Agent That Knows When to Give Up

The name is a problem before the code is. Search for Scout and you find an electric off-roader with a Volkswagen Group backing, a tote-bag company running a fall sale, and a student information system for California charter schools. The Scout that matters here is none of those. It is a TypeScript package from Outcrawl, a company that describes itself as ‘web infrastructure for AI agents,’ and it is the newest entrant in the browser-agent race — the crowded corner of AI where you hand an agent a goal in plain language and it clicks, types, and scrolls until the job is done.

What makes Scout worth a look is not that it can drive a browser. Everything in this category can drive a browser. It is two design decisions most of the competition has avoided: Scout ships with no model at all, and it treats failure as a normal, well-formed result rather than an exception to be thrown.

A crowded room, badly labeled

The field has grown fast enough that even its own participants have trouble sorting it. A Firecrawl survey of browser agents divides the noise into three buckets: AI-assisted consumer browsers (Comet, Atlas, Opera Neon), open-source agent frameworks (Browser Use, Stagehand, Skyvern), and managed infrastructure (Browserbase, Steel, Firecrawl itself). The survey projects the AI browser market growing from $4.5 billion in 2024 to $76.8 billion by 2034, and notes that 79% of companies have already adopted some form of agent technology. On GitHub, Browser Use crossed 97,000 stars by the survey’s count — its own site now claims 118,000 — with 10,345 commits and 572 branches, the physique of a repository where the work happens in public.

Success rates in this space are, by the survey’s own accounting, probabilistic: somewhere between 30 and 89 percent depending on the tool and the benchmark. Browser Use reports 82 percent on its own 106-task internal benchmark at 17 cents per solved task. Browserbase claims 10,000-plus companies building on its managed browsers. Against this backdrop, Scout arrives with no independent adoption data at all — the sources here show a README, an npm package, and a benchmark the company ran itself. That is worth saying plainly: this is a young project, and most of what can be assessed is its design, not its traction.

Four jobs, zero models

The genuinely interesting idea in Scout is its refusal to pick a brain. Most agent frameworks either bundle a model or quietly default to one. Scout has no built-in model and no default. Instead, it decomposes the agent’s work into four jobs, each of which can be a different model on a different service, behind a different key, as long as the service speaks the standard chat completions API.

The jobs are named like a heist crew. ‘Hands’ is required: it reads the page and takes each step — click, type, scroll, read — and because it runs on every single step, a fast model pays off there. ‘Brain’ is optional and does the planning, which the README says helps on long tasks that cross many pages. ‘Eyes’ is a vision model, consulted only when a page has to actually be seen. ‘Extract’ reads a page into the final answer, or into a JSON Schema you supply so the answer comes back in exactly the shape you asked for; without it, hands does the reading.

This is cost engineering expressed as architecture. An agent loop is not one workload — it is four with wildly different economics. The step-taking model gets called hundreds of times per run; the planner a handful; the vision model only when a layout defeats text; extraction once, at the end. Letting each job be a different model at a different price means the expensive reasoning model is not burning tokens on scroll decisions. The boring part is where the value usually lives, and here the boring part is a compatibility detail: when a provider refuses Scout’s request for a structured reply, the run’s error says which job failed and what to change. That is the signature of someone who has actually pointed this thing at a variety of endpoints, not just the two the demo uses.

Under the hood, the repository is a monorepo that separates concerns cleanly: a runtime package holding the agent loop — look at the page, pick an action, act, check, repeat — a model package for prompts and provider-neutral clients, a CDP package that drives a real Chrome over the DevTools protocol, and an ‘agenthands’ package, MIT-licensed separately, that plans pointer and keyboard input for local browsers. The demo run in the README — open a bookshop, find the first poetry title, report its name and price, done in five steps — is unremarkable, which is the point. The loop is becoming a commodity. The differentiators are elsewhere.

Failure as a return value

The second design decision is the one that caught my attention. Every Scout run returns a result object, even a run that falls short. The status field is one of four values: completed, partial, capped, or failed. A partial or failed run includes an error field saying what is still missing. The steps array records every action with its timing and whether it worked. There is a cost field for model spend, and a replay link on cloud runs. You can cap a run by steps, duration, or budget — and reaching a cap is defined as a normal ending that returns everything found so far, not an abort.

This sounds like table stakes. It is not. In a field where success rates are probabilistic by everyone’s admission, the worst outcome is not a clean failure — it is a silent half-answer, an agent that returns something plausible-looking after stalling on a login wall. Scout’s contract assumes the run will sometimes fall short and makes that legible: what was attempted, what worked, what is missing, what it cost. For anyone wiring browser agents into production systems, that failure contract may be more valuable than another few points of benchmark success.

There is also a small sign of the times in the README: a tip suggesting that if you are not writing the code yourself, you hand the page to your coding agent and let it set Scout up. Documentation written to be read by agents, about agents, for agents. The food chain is shortening.

The cloud, the arms race, and one number to hold at arm’s length

The README is candid about the business model: Scout runs best on Outcrawl’s cloud, and the cloud is what the company actually sells. What it sells is not compute but camouflage. Traffic leaves through residential connections, so sites load the way they do for anyone at home. Captchas are solved inside the browser and the run carries on. Input is planned rather than injected — the browser itself works out every pointer move, scroll, and keystroke, so the agent sends plain actions. Runs are recorded by default, with a step-by-step replay.

This is the same arms race everyone else in the infrastructure bucket is running. Browser Use’s own infrastructure benchmark claims 90.5 percent of visits got through on 100 bot-protected sites, against 78.5 for Browserbase, and Browserbase markets itself as access to ’the 85% of the web APIs can’t reach,’ with use cases spanning KYC checks, claims processing, and price monitoring. The agent loop is a commodity; getting through the door is the product.

Which brings us to the number. Outcrawl reports that Scout runs on its cloud reached 92.5 percent of pages on Browser Use’s 80-site benchmark, scored with Browser Use’s own code, with the next best entry at 81.4 percent — three full runs, dated 7 October 2026. Hold this at arm’s length. It is self-run, on a small number of runs, on a competitor’s benchmark, and it is not directly comparable to Browser Use’s own published 90.5 percent figure, which is a different test on different sites. It is a data point, not a verdict. What it does tell you is where Outcrawl believes the fight is: not in the loop, but in the door.

A mirror, not a home

The least open thing about this open-source project is its development model. The repository is an automatic mirror. Every change lands first in the repository Outcrawl runs in production, ships with its tests, and then arrives here as a sync commit. Pull requests are welcome — bug reports, fixes, new examples — with Developer Certificate of Origin sign-off, but a merged PR comes back to you as part of the next sync. Community contributions are processed, not hosted.

This is open source as distribution, and it is a legitimate, common model: you can read the code, fork it, run it locally, drive it over CDP against a browser you already run. But it caps how much community gravity the project can accumulate. Browser Use’s five-digit commit count is what a repository looks like when the arguments happen in public. Scout’s repository is a shop window, refreshed from the warehouse.

Other rough edges are visible from the README alone. Replays exist only on the cloud — local runs return an empty replay link, so the best observability feature is partly a paid one. The model-agnostic design is a feature and a bill: the hands model runs on every step, and the cost field is populated only ‘when it is known.’ And the free tier of 1,000 credits a month, no card needed, is a funnel, not a gift.

Where it sits

Scout’s natural constituency is TypeScript developers who want Browser Use-style autonomy without Python, and who care about per-job cost accounting. That ground is already contested — Firecrawl’s survey counts Stagehand at 23,000-plus stars as the TypeScript SDK of record, and Agent Browser at 35,000-plus taking the CLI route. Scout’s differentiators against both are the four-job model split, the failure contract, and the bundled anti-bot infrastructure.

The open questions are the ones a young project cannot answer yet. Whether the 92.5 percent figure survives third-party replication. Whether a mirror repository can grow a community, or only a customer base. And whether ‘bring your own model’ reads as freedom or as offloading the most expensive part of the stack onto the user. For now the honest assessment — in Scout’s own spirit — is that the run is partial: the interesting parts are real, the design is thoughtful, and what is still missing is everything that only time and other people’s benchmarks can provide.