Browser Agents for Pages Your Crawler Cannot Reach: Logins, Portals, Forms

The best browser agent in Halluminate's Web Bench finished 46.6% of the write-heavy tasks it was given: log in, fill the form, download the file. That is the ceiling on the exact work people buy agents for, and it is worth holding onto before the demo videos do their job on you.

Most scraping problems should never reach an agent in the first place. If the target returns HTML and the volume is meaningful, a crawling framework with a proxy pool underneath it beats anything driven by a language model on cost, speed and predictability. The choosing a web scraping tool guide covers that decision, and it applies to the large majority of collection work.

This guide is about the remainder: the pages a crawler cannot reach. A supplier portal that requires a login and a three-page form. A county records site whose markup changes without notice. A vendor dashboard with no API and no export button. Forty of those, each worth a few hundred records a month. Writing and maintaining a deterministic script for each one costs more engineering time than the data is worth, and that is the specific condition under which paying a model to drive a browser starts to make sense. The agentic automation category exists for that shape of work.

What an agent actually does differently

A scripted scraper encodes the traversal in advance. Click #login, type into input[name=user], submit, wait for .results-table, parse. The script knows the path because a developer walked it once and wrote it down. When the site changes the path, the script fails, usually loudly.

A browser agent does not encode the traversal. It observes the current page state, sends that state to a model along with the goal, gets back an action, executes it, and repeats until the goal is met or a limit is hit. The path is discovered at runtime, every run. That is the whole trade: resilience to change, purchased with an inference call per step.

Two consequences follow, and both drive the economics.

Cost scales with steps rather than with pages. A five-step login-and-download costs five model calls, plus whatever the page state costs to encode. Worse, the cost per step rises as the run goes on, because prior actions and observations stay in the context window. A twenty-step run therefore costs considerably more than four times a five-step run, which is why the practical advice on agent design keeps coming back to trimming what the model sees rather than trimming the number of steps.

Stagehand is the clearest expression of the tradeoff in SDK form. Built by Browserbase on top of Playwright, it exposes act() for a plain-English action, extract() for schema-validated data, observe() for surfacing what is actionable on the page, and agent() for autonomous multi-step runs. You can write a Playwright script and replace only the three steps that keep breaking. That is a very different bill from handing an agent the whole flow.

Browser Use sits at the other end: an open-source harness where the model drives the entire session. It raised a $17M seed round led by Felicis in March 2025, reported by TechCrunch on 23 March 2025, and went through Y Combinator's Winter 2025 batch. The open-source library is genuinely popular. Worth knowing before you plan around it: the stealth and anti-detection handling that production runs need sits in the paid Browser Use Cloud, not the free harness.

Cost per successful task

Compare cost per successful task, not cost per API call. The formula has four terms and none of them are optional:

1. Inference. Steps per task, times tokens per step, times model price. Tokens per step grow through the run.
2. Infrastructure. Browser session time, proxy egress, CAPTCHA solving where the vendor bundles it.
3. Failure. Divide by your observed success rate. A 60% success rate means every completed task carries the cost of roughly 0.67 failed ones, and failed runs often burn a full step budget before giving up.
4. Human. Review time on the output, plus the escalations an agent hands back.

Against that, a deterministic script costs engineering hours once, plus maintenance, plus near-zero per run. A script's unit cost falls as volume rises while an agent's stays roughly flat, so the two curves cross somewhere, and finding that crossing point is most of the decision.

The crossover moves in the agent's favor when the number of distinct flows is high and the volume per flow is low, because script cost is paid per flow while agent cost is paid per run. Forty portals at 200 records a month each is agent-shaped. One portal at 200,000 records a month is script-shaped. The same target volume, distributed differently, gives opposite answers.

It also moves when the flow changes often. A script that needs a developer every three weeks has a maintenance cost that never amortizes. This is exactly the pitch CloudCruise makes, and it has picked a market where the condition genuinely holds: healthcare payer portals and EHR systems, where the flows are multi-step, the portals change, and there is no API to fall back on. The company came through Y Combinator's Winter 2024 batch, and its own blog carries a post dated 19 March 2026 announcing a $5M seed round for healthcare automation. We have not seen that round confirmed by an independent outlet, so read it as the company's own announcement.

Four target shapes worth paying for

A long tail of low-volume portals. The defining case. Each target is cheap to describe in a sentence and expensive to describe in code. Agents amortize across the tail because the same harness handles all of them.

Flows that rot faster than they pay back. If your maintenance log shows the same scraper being repaired monthly, the script never earned back its build cost. Skyvern attacks this directly by replacing CSS selectors with LLM reasoning plus computer vision, so a renamed class or a moved button does not break the run. Its team announced a $2.7M seed round on the company blog, with Tracxn dating the round to December 2025.

Authenticated multi-step forms. Logins, 2FA, wizard-style forms, document downloads behind a session. Skyvern handles TOTP-based 2FA, form filling and downloads. Notte keeps credentials out of the model's context in a secrets vault, which matters when your security review asks where the password goes. Notte is early: Zurich-based, founded 2025, and Vestbee reported a $2.5M pre-seed on 18 July 2025 alongside a place in Y Combinator's Summer 2025 batch. Its core framework is SSPL-licensed, which is source-available rather than open source, and that distinction has killed adoption at more than one company with a strict license policy.

One-off migrations. Pulling ten years of records out of a system you are decommissioning is the ideal agent job. It runs once, nobody maintains it, and the alternative is a contractor clicking for two weeks. Nothing about a job you will never repeat justifies a hardened script.

Everything else deserves skepticism. High-volume repetitive extraction against a stable page is script work. Anything where the output feeds a financial or regulatory process needs determinism you will struggle to get from a model choosing its own path. And if you are being blocked before the agent gets to reason about anything, you have a network problem, not an intelligence problem: see why scrapers get blocked and the proxy networks category, because an anti-bot system does not care how clever the driver is.

What the public benchmarks say

We run no benchmarks of our own. Several third parties do, and their results are consistent enough to plan around.

Halluminate's Web Bench, published 30 May 2025, evaluated agents on 2,454 tasks across 452 live websites. Its repository puts 1,580 of those tasks, 64.4%, in the read category, with the rest split across create, update, delete and file manipulation. The headline finding is the gap between the two. On read-heavy tasks, extracting information from pages, the write-up reports "most agents achieving >75% success rate". On write-heavy tasks, logging in, filling out forms, downloading files, it reports that "SOTA agents only reach 46.6%", a mark set by Skyvern 2.0. The write category is precisely the one this guide is about, which is a useful corrective to the demo videos.

The same write-up is blunt about why: "Infrastructure issues remain a huge blocker to browser agent performance on the real web. These include proxies, captcha, and login/authentication." Halluminate's companion BrowserBench, published 22 November 2025, isolates that variable. It runs 292 tasks across 292 websites, roughly half chosen for documented bot detection and half for traffic, and scores providers on a stealth failure rate defined as "the number of agent trajectories that failed due to proxy and captcha issues". Halluminate's stated reason for building it is that browser infrastructure was observed to affect accuracy by 25 to 50%, a swing large enough to dominate any comparison of the models themselves.

Before you go shopping for a smarter agent, sit with that number. A meaningful share of agent failure is the same blocking problem every scraper has, arriving one layer higher up and wearing a different name.

The reliability picture from academia is consistent with this. "An Illusion of Progress? Assessing the Current State of Web Agents", from the OSU NLP group and accepted to COLM 2025, introduced Online-Mind2Web, 300 tasks across 136 websites, specifically because the authors judged existing benchmarks to be flattering. Their abstract states the conclusion directly: the results "depict a very different picture of the competency of current agents, suggesting over-optimism in previously reported results", a gap they attribute to "shortcomings in existing benchmarks". Per-agent scores from that paper circulate widely in secondary write-ups; the ranking moves with every model release, so treat any specific figure you see quoted as dated unless you can trace it to the paper's own tables.

WebArena, the older simulated benchmark, reported a GPT-4 baseline in the mid-teens against roughly 78% for humans on the same tasks when it was published. Public leaderboards have since reported considerably higher scores, so the progress is real, but nothing on those boards is near what the human baseline was.

Vendor-published scores need reading differently. rtrvr.ai claims 81.4% overall on Web Bench and more than 30,000 users, both published on the company's own blog and not independently audited. Self-reported benchmark results are common in this category and are not worthless, but treat them as a claim about the vendor's own configuration until someone else reproduces them.

The hybrid pattern: discover once, run deterministically

Once a team has watched its inference bill for a month, it tends to arrive at the same architecture: use the agent to solve the flow once, capture what it did, then replay the capture on every subsequent run and fall back to the agent only when the replay fails.

CloudCruise builds the product around this sequence: a coding agent generates the automation, managed infrastructure runs it, and a maintenance agent detects when a portal has changed and repairs the script, escalating the hard cases to a human. The rationale is arithmetic rather than ideology. Model cost gets paid once at generation time and amortized over every subsequent run, the script executes at browser speed instead of waiting on inference between clicks, and what you keep is a versionable artifact rather than a transcript. That argument holds regardless of vendor.

You can assemble the same thing yourself. Stagehand's observe() returns the actionable elements it resolved, which you can cache and replay as ordinary Playwright calls, spending model tokens only on the steps that failed. Skyvern stores workflows as objects you can build from a browser recording rather than a prompt. Notte's repository describes workflows as a way to "combine scripting and agents to reduce costs and improve reliability", which is the same idea expressed as an SDK feature rather than a product. In each case the agent's job ends once the flow has been captured.

Three rules keep the pattern safe. Review the generated script like any other code, because it was written by a model that had one successful run to learn from. Version it, so a repair that breaks things can be rolled back. And keep a canary: a known-good task with a known-good answer that runs before the batch, so a silently degraded flow is caught by the canary rather than by whoever consumes the data.

Comparing the tools

Two entries deserve expanding because they are frequently misfiled.

Gumloop is a workflow builder that happens to include website scraping, multi-page crawling and AI extraction nodes. It fits an operations team assembling a process across Slack, a CRM and a few web sources without writing code. It is the wrong answer for a data engineering team that needs to collect from a defended target at volume, because its nodes are general-purpose building blocks rather than a specialized extraction engine.

Bytebot is not a browser agent at all. It is an Apache-2.0 desktop agent from Tantl Labs that operates a containerized Linux environment: browser, file system, terminal and editor, driven by vision rather than selectors. It matters here because some portal flows leave the browser. A download that opens in a PDF viewer, a file that must be renamed and re-uploaded, a legacy client that only runs as a desktop application. Bytebot can also use a password manager such as Bitwarden or 1Password for logins. The price is operational: you run the containers, you secure them, and you pay your model provider directly. Funding figures circulating for Tantl Labs come from secondary aggregators rather than a primary announcement, so treat them as unconfirmed.

Credentials, portals and the scope line

Everything in this guide assumes accounts your organization already holds and is entitled to automate: your supplier portal, your payer portal, your own dashboard in a vendor's SaaS. Creating accounts to gain access, or automating a platform whose terms prohibit it, is out of scope. That is a policy line, not a technical one, and no tool on this page resolves it for you.

Within that line, credential handling is the part security review will actually ask about. Three questions cover most of it. Does the credential enter the model's context, or is it injected into the browser out of band? Notte's secrets vault is designed for the second answer. Where does the session live after the run, and who can replay it? A hosted agent that keeps a warm authenticated session is convenient and is also a stored credential by another name. And what happens on the second factor? Skyvern supports TOTP flows; anything relying on an SMS code needs a documented human handoff rather than a workaround.

One more constraint that catches teams late: many portals rate-limit or lock accounts on unusual access patterns, and an agent that retries a failed login four times can trigger exactly that. Cap login attempts below the lockout threshold, and treat a lockout as a stop condition for the whole flow rather than for one task.

When the agent loops

Agents fail in a characteristic way. Rather than erroring, they keep going: re-reading the same page, retrying a click that does nothing, exploring an irrelevant menu. Left alone, a looping agent burns the token budget and then reports something plausible. Four controls contain it.

A step budget. Hard cap the number of actions per task. Set it from an observed successful run plus headroom, not from optimism. Exceeding it is a failure, not a reason to extend.

A cost ceiling. Independently of steps, cap the spend per task. This is the control that survives a model change that alters token usage without altering step counts.

A wall-clock timeout. Sessions hang. Pages never settle. A browser session that has been open for twenty minutes on a five-minute flow is not going to recover.

A validator between action and next step. Skyvern's architecture makes this explicit with a planner, an actor and a validator that checks the screen after each action to confirm the action actually took effect, feeding the answer back if it did not. Whether you get it from the tool or build it, the check that distinguishes "clicked" from "clicked and something changed" is what stops most loops.

Write actions need one more thing: idempotency. If a form submission times out, you do not know whether it went through. Either check for the resulting record before retrying, or make the retry safe. This is ordinary distributed systems hygiene and it is skipped constantly because the agent framework makes retrying feel free.

The audit trail a data team needs

Data from an agent arrives without the provenance a scripted pipeline gives you for free. With a script, the traversal is in version control and the same input produces the same path. With an agent, the path was chosen at runtime and is gone unless you captured it. Five artifacts make agent output defensible.

The trajectory. Every action, the page state that prompted it, and the model's stated reason. Without this, a wrong record is unexplainable.

Screenshots at each step. Bytebot logs before-and-after screenshots for every action, which is the right default. When a field is wrong, the screenshot usually shows why in seconds.

Retention with a stated window. Hosted platforms keep session video, screenshots and logs for a fixed period, and the period is usually measured in days or weeks rather than quarters. Find the number in your vendor's contract rather than assuming, because a data question raised in a quarterly review will arrive after a short window has expired. If you cannot get a long enough window, export the trajectory to your own storage on completion.

Schema validation on output. Stagehand's extract() returns schema-validated data, and Notte's structured output takes a Pydantic model as its response format. Validation catches the characteristic agent failure, which is returning a plausible answer rather than reporting that it could not find one. A null that fails validation is a good outcome. A confident wrong number is not. The validating AI-extracted data guide covers the sampling side.

A human review sample. Pick a fixed percentage of completed tasks, review them against the screenshots, and track the rate over time. This is how you get a real success rate for the cost formula above, and it is the only number in this guide that has to come from your own runs.

Deciding

Answer in order and stop at the first yes.

1. Is the page reachable without a session, and stable? Write a script. Use a crawling framework or a scraping API.
2. Are you blocked before rendering? Fix the network layer first, with proxies and browser infrastructure. An agent behind a blocked IP fails identically to a script behind a blocked IP.
3. Is it one target at high volume? Script it, and use LLM assistance only for the parsing step, as covered in LLM extraction versus selectors.
4. Is it many targets at low volume, or a flow that changes monthly? This is agent territory. Start with Stagehand if you have Playwright engineers, Skyvern if you want a platform with a workflow builder and 2FA handling, CloudCruise if you are in healthcare and want the maintenance agent.
5. Does the flow leave the browser? Bytebot, accepting the container operations.
6. Is the builder a non-engineer? Gumloop, accepting the extraction ceiling.
7. Will you run it more than a few dozen times? Whatever you picked, make it emit a script and run the script. The agent becomes the repair mechanism, not the runtime.

The AI extraction category covers the adjacent case where the navigation is easy and only the parsing is hard. If the answer turned out to be step 1 or 2, the 2026 web scraping stack post is a better starting point than anything here.