What Browser Agents Should and Should Not Do for Business

Browser agents fit two kinds of business work best: finding, comparing and organising verifiable information on public pages, and handling queries, draft forms and repetitive entry inside low-risk internal systems. They should not make unattended payments, change permissions, accept contracts or publish externally. The deciding question is not whether the agent can click, but what a wrong click would cost, whether it can be reversed, and who confirms before the consequential action.

A browser agent reads the page, locates controls, enters content and interprets feedback. In effect, it places the plan-and-act loop described in What Is an AI Agent? inside a browser. That lets it work with human interfaces that have no ready-made API, but it also inherits every uncertainty of the browser: redesigns, pop-ups, expired sessions, network failures and untrusted page content. The capability and the risk enter through the same door.

Sort tasks by the consequence of failure, not the quality of the demo

Start with three zones. Green actions are verifiable, reversible, low-sensitivity and low-loss. Amber actions involve authentication, sensitive data, writes or unstable pages and require limited authority, approval and human takeover. Red actions are irreversible, high-value or commit the organisation and should never be completed independently by an agent. The real consequence determines the zone, not how smoothly a vendor demonstrates it.

• Suitable: public-information assembly, page-state checks, read-only queries, draft filling and low-risk entry where the cost of an error is rework.
• Use with caution: tasks requiring login, touching sensitive data, writing across systems, depending on frequently changing pages, or remaining reviewable before submission.
• Do not delegate independently: payments, authorisation, deletion of critical data, account permission changes, contractual acceptance and final external publication.

These are not permanent labels. Filling a draft in an internal test environment may be green. Submitting an official application containing customer identity data is amber. Ticking a legally consequential acceptance box and submitting it belongs in red. Classify the full action rather than allowing one vague scenario name to hide its risk.

Suitable: public-web information work, with limits on public access

On public pages, begin with find, read, compare and record. An agent might check whether a supplier announcement page changed, collect public specifications from named product pages, verify store opening information, assemble public event dates, or prepare research notes across sources with the original links attached. These outputs are easy to sample, and a missed item can usually be corrected through review and rerun.

Make source evidence a required deliverable: preserve the page URL, title, access time and excerpt supporting each conclusion. If the page does not state something, the agent may not infer it from layout or a similar product. Time-varying figures need the collection time. A page that failed to load becomes unknown, not permission to reuse an old value as current. These rules let a reviewer verify quickly and reconstruct what was visible when a dispute arises.

Public access does not grant unlimited scraping, permission to bypass controls or freedom to ignore site terms. A company should establish that it may access and process the content, constrain request frequency, and respect explicit automation boundaries. When the site refuses access, presents a login wall or asks for verification, the agent should stop rather than keep searching for a path around it. Manage it like an employee account that must respect the other party's gates.

Suitable: low-risk internal work where the agent prepares and a person submits

Inside company systems, read-only queries and previewable drafts are the safer starting point. An agent can read specified reports from an operations console and consolidate pages into a fixed format. It can prefill a ticket category, summary and suggested treatment from confirmed information, then stop before submission. In a legacy system with no API, it can enter structured data into a test environment or a form awaiting review, removing repetitive typing without making the final decision.

The essential design is separating preparation from effect. The agent navigates, copies, transforms and prefills; a person with business authority checks the target, critical fields and impact before submitting. The confirmation view should highlight what the agent entered, where each value came from and which fields remain uncertain, rather than offer one convenient approve-all button. If the reviewer must redo everything to feel safe, the task contract or evidence design is still inadequate.

Treat identity as a governed resource. Do not share an employee's highly privileged account with an agent. Create a scenario-specific identity, expose only the necessary pages, data scope and actions, and limit concurrency and operating windows. Log the identity, task ID and approver for every session. Even when the browser merely imitates clicks, the back end should see a bounded subject that can be disabled and audited.

Use caution: logins, CAPTCHAs and page changes amplify uncertainty

Authenticated work introduces expired sessions, single sign-on redirects, multi-factor authentication and changing permissions. An agent should not store an employee's plaintext password or submit credentials repeatedly after failure. Prefer a controlled identity and short-lived session, with a person completing identity confirmation when required. If the session expires, pause, preserve the completed steps and request renewed authorisation.

A CAPTCHA expresses a need for extra confirmation or an attempt to prevent automation. The agent should not bypass it, solve it on the user's behalf or route it to an outside service for evasion. The correct behaviour is to stop and hand control to an authorised person, or use an official API or batch channel supplied by the system owner. A workflow that hits verification every day does not have a prompt problem; it lacks support for that automation path.

Page changes create quieter failures. A moved button can turn into a click on the neighbouring action. A field can keep its label while its business meaning changes, allowing old logic to run and enter the wrong value. Monitor structural changes, key copy and action feedback after launch. Unknown pop-ups, missing controls or unexpected responses should stop the run by default. Recognising uncertainty matters more than forcing the workflow to finish.

Do not delegate irreversible, high-value or commitment-making actions

Payments, refunds, bank-detail changes, payroll adjustments, permission changes and deletion of critical records carry high consequences, some hard to reverse. An agent may prepare a payment list, flag conflicting fields and open the pending page, but it should not complete final confirmation independently. The approver must see the amount, recipient, account and basis, then confirm through a reliable control separate from the agent conversation.

Keep actions that commit the organisation in human hands as well: accepting contract terms, confirming price or delivery to a customer, filing regulatory material, publishing an official notice or sending a high-impact reply in the company's name. The question is not merely whether the prose is good. It is who has authority to make the decision. An agent may draft, check and flag risk; the existence of a clickable button does not confer organisational authority.

A browser agent is also the wrong tool when the system explicitly forbids automation, or when a stable supported API exists and the team chooses imitation clicks anyway. The first lacks an authorisation basis; the second usually gives up reliability and observability. Browser control is a practical bridge to legacy interfaces, not a shortcut around system governance.

Browser control, supported APIs and fixed workflows each have a place

A supported application programming interface (API) returns structured status, uses explicit identity, constrains parameters and can handle repeated requests, making it generally more stable than visual clicking. How Function Calling Lets AI Act explains that mechanism. Browser operation belongs where no API exists, where coverage is incomplete, or where information unique to the human interface matters. If a browser flow becomes frequent and stable, consider adding an interface rather than maintaining a brittle page routine forever.

Whether the task needs an agent is a separate decision. If the path is fixed, field mapping explicit and exceptions few, deterministic automation or a fixed workflow is easier to test. Autonomous planning earns its place only when the task must interpret page meaning, choose the next action from feedback and handle bounded variation. The principle in AI Workflow or AI Agent: How to Choose applies here: wherever determinism can buy reliability, autonomy is not a requirement.

Move from read-only to controlled writes instead of handing over the browser

Roll out in four stages, judging each stage on real exceptions rather than successful demonstrations:

1. Offline replay: use page snapshots or a test environment to check targeting, extraction, refusal of excess authority and stopping on unknown states.
2. Read-only shadowing: let the agent query live pages and generate suggestions without writing, then compare with human work.
3. Controlled prefilling: permit drafts on a bounded set of objects while people verify critical fields and submit.
4. Limited writes: open only reversible, low-impact actions with quotas, alerts, sampling and a kill switch.

Acceptance should cover task success, wrong clicks, duplicate submission, timeout recovery, human takeover, sensitive-data exposure, page changes and cost per task. How to Evaluate AI Agents provides the wider framework. Rerun regression whenever pages, account permissions or business rules change. A browser agent's sensible goal is not to click everywhere like a person, but to reduce repetitive work reliably inside a small, authorised, observable and stoppable part of the interface.