A procurement analyst I spoke to recently described her new colleague as “fast, polite and slightly reckless.” The colleague was a browser agent. It had spent the morning logging into forty vendor portals, checking stock levels and copying delivery dates into a spreadsheet. It got thirty-eight right. The other two it “fixed” by inventing plausible dates.
That story sums up the category better than any vendor keynote. AI browser agents can genuinely absorb the tedious middle of web work, and they can also quietly fabricate when a page doesn’t look the way they expected. Both halves matter when you’re deciding whether to let one near your accounts.
What an AI browser agent actually is
A browser agent is a model driving a real browser. Not a scraper chewing through raw HTML, not a chatbot telling you which button to press. It opens tabs, reads what’s actually rendered, clicks, types, scrolls, waits for spinners to stop, and checks whether the result looks right before it moves on.
Most of them run the same loop underneath: observe the page through a screenshot, the DOM, or both, decide the next action, execute it, then verify. The interesting engineering sits in that final step. Plenty of tools can click a button. Far fewer can tell whether the click achieved anything. If you want the longer version of that loop, this breakdown of what AI agents actually do and where they break is worth twenty minutes.
That loop is also what separates a browser agent from an ordinary integration. If Stripe has an API, use the API. It’s faster, cheaper, and it won’t misread a button label. Browser agents earn their keep when there is no API: legacy supplier portals, government filing systems, internal admin tools built in 2011 and never touched since.
Where they’re already pulling their weight
- Repetitive form entry. Expense claims, insurance quote requests, client onboarding packets. Anything with twelve fields and no export button.
- Cross-portal research. Checking one part number across a dozen distributor sites and returning a price table. Tedious for a person, trivial in cost for an agent.
- Smoke testing. Walking a signup flow every hour to catch the moment a payment step silently breaks in production.
- Booking and rescheduling. Flights, freight slots, service appointments. The agent handles the calendar Tetris; a human approves the spend.
- Watching pages that have no feed. Competitor pricing, tender notices, regulator bulletins. No RSS, no API, just a page that changes.
The common thread is volume plus tedium. One invoice is faster by hand. Four hundred invoices is faster with an agent, provided you’ve built in a check. These real deployment examples rather than demo reels show how narrow that sweet spot usually is.
The failures you’ll meet in week one
Pages that don’t resemble the training data
A redesign moves the “Continue” button two inches left and the agent stalls or, worse, clicks something adjacent. Native browser controls, iframes and cookie banners layered over the real form cause most of the early chaos. Good agents retry with a different strategy. Bad ones loop.
Bot defences
CAPTCHAs, Cloudflare challenges, device fingerprinting. A browser agent looks, to a fraud system, a lot like the thing fraud systems are built to stop. Expect friction on consumer-facing sites and near-zero friction on the internal portals where agents are most useful.
The almost-right problem
This is the one that bites. An agent that fails loudly is a nuisance. An agent that half-completes a task and reports success is a liability. Guardrails matter more than raw capability here, which is why building agents that actually finish the job is mostly about verification, not intelligence. Make the agent prove the page changed. Make it screenshot the confirmation. Make it stop when the proof is missing.
Security deserves more attention than benchmarks
A browser agent holds session cookies. It may hold credentials. It reads whatever text appears on screen, and that text is written by strangers. A malicious page can hide instructions in a product description or a comment thread and the model may follow them. This is prompt injection, and it is not solved.
The practical mitigations are unglamorous:
- Run the agent in a dedicated browser profile with nothing else logged in.
- Give it scoped credentials, never your primary admin account.
- Require human approval for anything that moves money or deletes records.
- Log every action with a timestamp and a screenshot, and read those logs for the first fortnight.
There’s a broader point about how much rope to give a system that acts without supervision, which this piece on what autonomous agents can do with nobody watching covers well. Short version: the answer depends almost entirely on how reversible the actions are.
Testing one in an afternoon
Don’t start with your bank. Pick a workflow that’s boring, reversible and currently done by a person who’d rather not be doing it. Time how long that person takes on ten repetitions. Then run the agent on the same ten and compare both the time and the error rate, not just the time.
Watch the first three runs end to end. You’ll learn more from five minutes of watching than from any feature list, and you’ll spot the moment the agent hesitates before it becomes a monthly problem. If you want a shortlist to test against, these agents judged by what they finish are a reasonable starting point, though your own ten-task benchmark will tell you more than anyone else’s leaderboard.
What changes when websites notice agents
Right now, browser agents are mostly uninvited guests. That’s starting to shift. Sites are experimenting with machine-readable permission signals, agent-specific checkout flows and declared bot identities that get a faster path than an anonymous headless session. Payment networks are already arguing about how a purchase initiated by software should be authenticated and who carries the fraud risk.
The likely outcome is a split web. High-volume consumer sites keep building walls, because agents are expensive traffic that occasionally buys things. Everything behind a login, where the site owner and the agent owner are effectively the same organisation, becomes dramatically friendlier, because there’s no incentive to block your own tooling. That second half is where most of the near-term value sits, and it’s why the interesting fights ahead are less about model capability and more about who pays for the compute and who accepts the liability when an agent does something wrong at 3am.
For now, the sensible posture is unromantic. Let agents do the clicking, insist they show their work, and keep a human on the approvals. The analyst with the reckless new colleague put it well: she doesn’t mind rechecking forty rows. She’d just rather not type them.