When is this the right approach?

When there is no connection available and the work is otherwise manual. That is a genuinely common situation, particularly with older internal systems and smaller suppliers. Where a documented connection exists, it is more stable in every respect and the browser route has no advantage worth the fragility.

Why does it break so often?

Because it depends on how pages are laid out, and nobody has undertaken to keep that stable. Any redesign can change what it finds, and the failure is usually quiet: the steps run, something different happens, and nothing reports an error. That is harder to catch than an outright failure.

Can it run unattended?

It depends where it lives. Something running in a browser on a person's machine stops when the machine does, and one tool here says plainly that anything needing to fire overnight belongs elsewhere. Cloud-hosted shapes run continuously, and then sessions and sign-in become the standing question.

Is using one permitted?

That depends on the site's own terms rather than on anything technical, and it is worth establishing before building. Some services address automated access explicitly, and the answer differs between them. This is the constraint most likely to be discovered after the work is done.

Glossary

Browser agent

A browser agent works a website the way a person would, clicking and typing through the interface, which is how tasks get done on systems that offer no other way in.

In plain terms

Software using a website the way you would: opening pages, clicking, filling boxes, reading what comes back. It exists because a great many systems have no other door. If a supplier offers a proper connection, that is almost always the better route, and a large number of them do not.

Why it matters

Because it decides whether a job can be automated at all. Work stuck behind a website with no connection available is work that otherwise stays manual indefinitely, and this is the only route to it. It is also the most fragile automation anybody runs, so knowing which of those two facts applies to your case is the whole decision.

How it works

It works the interface rather than a connection underneath, which is both the point and the problem. Everything it does goes through the same pages a person sees, so it can reach anything a person can reach, and it breaks when those pages change. A redesign nobody told you about is a failure with no error in it.

Where it runs decides what it can do unattended. Something living in the browser on somebody's machine inherits that machine's sessions and logins, which is convenient and means nothing happens while the laptop is closed. One tool in this guide is explicit that anything needing to fire overnight is outside its shape and belongs to a cloud platform.

Sessions and sign-in are the recurring operational cost. Working as a person means being signed in as one, which raises questions about whose account is used, what happens at a re-authentication prompt, and whether the arrangement is permitted by the site's own terms. Those are not technical obstacles and they are the ones that stop deployments.

The capability is converging with general agents rather than staying a separate category. Products that began as browser automation now describe traversing sites, finding and summarising specific information and passing it on, which is the same shape as a general-purpose tool that happens to have a browser. The distinction is becoming one of emphasis.

It is usually a bridge, and worth recognising as one. Where a supplier later publishes a proper connection, moving to it removes the fragility entirely. Where a supplier never will, this is the permanent arrangement and deserves to be resourced like one rather than treated as a temporary measure that has quietly lasted three years.

Two ways in, and when each is available

The comparison is worth making carefully because the two columns are usually argued about as though a preference were at stake, when the real situation is that one of them is frequently not on offer. Where a supplier publishes a documented connection, there is no serious case for driving its website instead, and teams that do so are usually working around an access request rather than a technical limitation. Where no connection exists, the argument evaporates: the alternative is not a better integration, it is a person doing the task by hand forever. What that means practically is that the fragility is a cost of entry rather than a design flaw to be engineered away, and the right response is to plan for breakage rather than to be surprised by it, while keeping an eye on whether the supplier ever publishes the thing that would make the whole arrangement unnecessary.

Seen in the wild

A tool living as a browser extension, scraping structured data off pages and moving information between web apps, where the extension is both the superpower and the boundary.
Bardeen
A general-purpose tool that operates a browser as one of the things it does while carrying research through to a finished deliverable.
Manus
A self-hosted automation platform used where a proper connection exists, which is the route to prefer whenever a supplier offers one.
n8n

Common misconceptions

People assume

It is a worse version of a proper connection.

In fact

It is a different thing, used where no connection exists. Comparing them on reliability misses that one of them is unavailable: for a great many systems the choice is this or leaving the work manual. Where a supplier does offer a connection, using this instead is the mistake.

People assume

Once it works it will keep working.

In fact

It depends on a page layout nobody has promised to keep. Sites are redesigned without notice and without any obligation to you, so this is the automation most likely to break for reasons entirely outside your control, and to break silently rather than with an error worth reading.

Telling them apart

Browser agent vs API

Browser agent

Drives the interface a person uses. Works anywhere, breaks on redesign.

API

A documented connection meant for software. Stable, and only where offered.

Prefer the connection whenever one exists. This is what you use when the answer is that one does not.

Questions

When is this the right approach?: When there is no connection available and the work is otherwise manual. That is a genuinely common situation, particularly with older internal systems and smaller suppliers. Where a documented connection exists, it is more stable in every respect and the browser route has no advantage worth the fragility.
Why does it break so often?: Because it depends on how pages are laid out, and nobody has undertaken to keep that stable. Any redesign can change what it finds, and the failure is usually quiet: the steps run, something different happens, and nothing reports an error. That is harder to catch than an outright failure.
Can it run unattended?: It depends where it lives. Something running in a browser on a person's machine stops when the machine does, and one tool here says plainly that anything needing to fire overnight belongs elsewhere. Cloud-hosted shapes run continuously, and then sessions and sign-in become the standing question.
Is using one permitted?: That depends on the site's own terms rather than on anything technical, and it is worth establishing before building. Some services address automated access explicitly, and the answer differs between them. This is the constraint most likely to be discovered after the work is done.

Key takeaways

It works the interface, so it reaches anything a person can and breaks when pages change.
Where it runs decides whether it can work unattended.
Sessions, sign-in and the site's own terms are what stop deployments, not the technology.
It is converging with general-purpose tools rather than remaining a separate category.
Prefer a documented connection wherever one exists; this is for where none does.