> By Kris Newlin · Written with [Viktor](https://viktor.com), the AI employee.

## Key Takeaways

- **Integrations first, browser second.** An API call is faster and it fails loudly. A browser session fails quietly, in the middle of a form, on a page that moved a button.
- **The browser earns its place on the last mile.** Old portals, insurer sites, government filings, county tax lookups, supplier back offices: systems that will never publish an API.
- **Vendors are pushing hard on this.** Anthropic made computer use generally available on August 20, 2026 and added a browser use tool that reads page structure instead of guessing at pixels ([claude.com](https://claude.com/blog/computer-use-skills-api-files-api)).
- **Screenshots are the audit trail.** If a browser run cannot show you what it saw and what it clicked, you cannot approve it and you should not let it run unattended.
- **Write the rule down once.** Which systems the browser may touch, which ones it may only read, and which actions always come back as a draft.

Every quarter our ops lead had the same Thursday. Twelve certificates of insurance, each one pulled from a broker portal that has no API, no export, and a session that times out after fifteen minutes. She copied policy numbers into a spreadsheet, screenshotted the coverage page, renamed the files, and uploaded them to the shared drive. Four hours. Then a vendor asked for one of them in October and nobody could remember which folder it landed in.

That work is not hard. It is just locked behind a web page. This is exactly the seam where an AI employee either saves the afternoon or quietly invents a policy number, and the difference comes down to one decision: does he use a real integration, or does he open a browser and click?

## What is the difference between a browser session and an integration?

An integration is a direct line into another system. Your AI employee authenticates once, then asks for exactly what he needs: this invoice, that contact record, the ad spend for last week. The system answers in structured data. If the request is wrong, it comes back as an error, not as a guess.

A browser session is the other path. The AI employee gets a real browser, loads the page, looks at it, and acts on it the way a person would: click the field, type the value, hit submit. Under the hood Viktor drives that browser with screenshots plus page structure, so he can work in tools that were never built for automation at all.

| Job | Integration path | Browser path |
| --- | --- | --- |
| Pull last week's Stripe revenue | Direct query, structured numbers back | Slow, and the dashboard renders differently on every screen size |
| Update a HubSpot deal stage | One write, confirmed by the record | Works, but you are trusting a click on a dropdown |
| Download a COI from a broker portal | No API exists | The only way it happens without a person |
| File a form on a county tax site | No API exists | The only way it happens without a person |
| Adjust a Google Ads budget | Direct write, logged in the account | Fragile, and the UI changes monthly |
| Read a supplier's order status page behind a login | Rarely available | Reliable enough to run daily |

The pattern is not subtle. When a real connection exists, use it. The browser is for the systems that will never give you one.

## The rule: does this system have a supported connection?

Here is the whole decision, and it takes about ten seconds.

1. **Is there a real integration?** If yes, use it. Viktor connects to 3,200+ tools with read and write access, so the answer is usually yes and this conversation ends here.
2. **If not, is the job read-only?** Log in, read the page, bring back the numbers or the file. Low risk, easy to verify, good candidate to run on a schedule.
3. **If it writes something, who owns the consequence?** Submitting a filing, changing a shipping address, cancelling an order. Those come back as a draft or a confirmation request first.
4. **Would you hand this login to a new hire in week one?** If the answer is no, do not hand it to a browser session either. That is a permissions decision, not a technology one.

```prompt
@Viktor log into the broker portal every Monday, pull the current certificates of
insurance for all active vendors, save them to the Vendor COIs drive folder named
vendor-policy-expiry, and post a summary in #ops with anything expiring in 30 days.
Screenshot each page you pull from.
```

That request is read-only, it repeats, and it produces evidence. It is the best possible use of a browser: the boring last mile of a workflow that is otherwise fully connected.

![Integration path versus browser path decision card](/images/blog/when-should-your-ai-employee-use-a-browser/decision.webp)

## Why the industry suddenly cares about browser agents

The capability itself is not new. What changed in 2026 is that it got good enough to sell to regulated buyers.

On August 20, 2026 Anthropic moved computer use to general availability on its platform and shipped a new browser use tool alongside it. Two details from that announcement matter for anyone running this in an operations team. First, the browser tool reads the structure of the page and acts on a named field or button rather than a coordinate on a screenshot, which is the difference between "click the third box" and "click the policy number field". Second, computer use became eligible for HIPAA-regulated workloads under Anthropic's business associate agreement, which tells you where the demand is coming from: healthcare and insurance back offices full of systems with no API at all ([claude.com](https://claude.com/blog/computer-use-skills-api-files-api), August 20, 2026).

Anthropic also quotes a customer running claims work on the new tool who says a long workflow dropped from 32 minutes to 13 with no prompt changes. Treat that as their number, not ours. The useful signal is the direction: the vendors are optimizing browser work for exactly the repetitive portal jobs that eat operations teams alive.

This is also where the old automation debate resurfaces. A recorded script that clicks the same five coordinates every time is [RPA, and it breaks the moment the page moves](https://viktor.com/blog/rpa-vs-ai-agents). An AI employee looking at the page decides what to click at runtime, which survives a redesign. It is a better failure mode, not a guarantee.

## Where browser work goes wrong

Three failures show up over and over, and all three are manageable if you name them up front.

**Silent partial success.** The session logs in, fills six of eight fields, hits a validation error it cannot read, and stops. An API call would have returned a clear error. A browser run can end with a page that looks almost right. The fix is that every browser job reports what it saw, not just what it did.

**Stale sessions and two-factor prompts.** Portals log you out, rotate passwords, and throw a code at you at the worst moment. If a job depends on a login that expires, expect it to fail on a schedule. Decide in advance whether a failed login pings a person or just waits for the next run.

**Doing something a human would have questioned.** A person filing a form notices when the amount looks wrong by an order of magnitude. Set the review boundary so anything that submits, pays, cancels, or emails an outside party comes back as a draft. We wrote the general version of that boundary in [when to let your AI employee act without review](https://viktor.com/blog/when-to-let-your-ai-employee-act-without-review).

![Three failure modes of browser sessions and the guardrail for each](/images/blog/when-should-your-ai-employee-use-a-browser/guardrails.webp)

Notice that none of these are exotic. They are the same three risks you would manage with a temp worker who has portal access and a to-do list.

## How to set this up without opening a hole

The permissions question is the real one. A browser session with a saved login is, functionally, an account that acts on your behalf. So treat it like an account.

- **Give it its own credentials.** Not the CFO's login. A named account you can see in the portal's user list and switch off in one click.
- **Scope what it can reach.** Read-only roles where the portal offers them. Most do, and almost nobody uses them. Our guide on [controlling what your AI employee can access](https://viktor.com/blog/how-to-control-what-your-ai-employee-can-access) covers how to scope this across connected tools too.
- **Require evidence.** Screenshots of every page a value came from. This is what makes the output checkable in ten seconds instead of ten minutes, and it is the same habit behind [verifying your AI employee's work](https://viktor.com/blog/how-to-verify-your-ai-employees-work).
- **Keep the browser off anything with a real connection.** If a tool is on the connected list and the browser is still being used, someone skipped a step. Start from [which integrations your AI employee actually needs](https://viktor.com/blog/which-integrations-your-ai-employee-actually-needs) and close the gaps there first.

```prompt
@Viktor the carrier portal added a new coverage tab. Update the Monday COI run:
pull the new tab too, flag any vendor whose limits dropped since last month, and
show me the before and after screenshots in the thread before you file anything.
```

One more thing worth saying plainly. Browser work is slower than an integration and it always will be. Loading a page, waiting for it to render, and reading it takes seconds where an API call takes milliseconds. That cost is fine on a Monday morning job that used to take a person four hours. It is not fine as your default path for a tool that already offers a clean connection, which is the mistake most teams make when they get excited about computer use.

## A quick way to decide this week

Take your team's five most annoying recurring tasks. For each one, write down the systems it touches and mark each system: connected, no connection, or connected but nobody set it up. That third bucket is usually the biggest, and it does not need a browser at all. It needs twenty minutes and an OAuth screen, which is the distinction we drew in [MCP vs OAuth](https://viktor.com/blog/mcp-vs-oauth).

What is left after that, the genuinely unconnectable portals, is your browser list. Usually it is two or three systems, and they are the ones your team complains about by name. Start there, run read-only for two weeks, and only then decide whether anything on the list should be allowed to submit.

## Frequently Asked Questions

### When should an AI employee use a browser instead of an integration?

Only when no supported connection exists for that system. Integrations are faster, return structured data, and fail with a clear error. A browser session is the fallback for portals, legacy back offices, and government or insurer sites that will never publish an API.

### Is browser automation reliable enough for daily work?

For read-only jobs, yes, especially now that tools act on page structure rather than screen coordinates. For jobs that submit or pay, keep a human approval step. The failure mode to plan for is a partial run that looks finished.

### What did Anthropic ship on August 20, 2026?

Anthropic made computer use generally available on its platform and added a browser use tool that reads page structure so agents target a specific field or button. Computer use also became eligible for HIPAA-regulated workloads under Anthropic's BAA, per the announcement on claude.com.

### Does Viktor drive a real browser?

Yes. When a tool has no connection, Viktor opens a real browser session and works the page, then reports back in Slack with what he saw. He also connects to 3,200+ tools directly, so the browser is the exception rather than the route he takes first.

### How do I stop a browser session from doing something risky?

Give it its own scoped account, prefer read-only roles, and set a review boundary so anything that submits, pays, cancels, or contacts an outside party comes back as a draft. Switching the account off in the portal is the kill switch.

### What if the portal changes its layout?

A recorded script breaks. An AI employee reading the page at runtime usually adapts, but not always, so a layout change should surface as a flagged run rather than a silent skip. Ask for screenshots on every run and you will see the change the week it happens.

### Is this the same thing as RPA?

No. RPA replays fixed steps and needs maintenance every time a page moves. An AI employee decides what to click based on what is actually on the screen. The comparison is covered in full in our RPA and AI agents post.

---

**Viktor is an AI employee that lives in Slack, connects to 3,200+ integrations, and does real work for your team.** [Add Viktor to your workspace -- free to start →](https://viktor.com/?utm_source=blog&utm_medium=cta&utm_campaign=when-should-your-ai-employee-use-a-browser)