Every business has a layer of software nobody can integrate with: the government portal with no API, the supplier back-end from 2011, the ERP whose "integration" is a CSV export, the SaaS plan that gates API access behind an enterprise tier. For a decade, the answer was RPA — brittle scripts replaying recorded clicks, breaking on every layout change.
In 2026 that layer is being re-automated by computer-use and browser agents: models that look at an interface, understand it, and operate it toward a goal. Same access as a human, no API required — and unlike RPA scripts, they adapt when the page shifts. This guide covers what they're actually good for, where they still fail, and the deployment rules that make them safe.
The 2026 landscape, briefly
Three routes to the same capability:
- Frontier-model computer use. Anthropic's computer use and OpenAI's computer-using agent models take screenshots, reason about them, and emit clicks and keystrokes — general-purpose, improving fast, priced per token.
- Open-source browser frameworks. Tools like browser-use and Playwright-driven agent stacks work with the browser's DOM and accessibility tree rather than raw pixels — faster and cheaper for web-only workflows and the workhorse of most custom deployments.
- Agentic browsers and product features. Consumer-facing agent modes in browsers and assistants (ChatGPT's agent mode, Gemini's browsing agents, and a wave of dedicated agentic browsers). Useful personally; rarely the right substrate for business automation, where you need logging, permissions, and repeatability.
For business automation, the practical distinction isn't which vendor — it's pixel-based vs. DOM-based (pixels generalize to desktop apps; DOM is faster and more precise on the web) and interactive vs. headless (a human watching vs. scheduled unattended runs — which changes the safety requirements completely).
What businesses actually automate with them
The pattern across real deployments: the workflow was always valuable; the interface made it unautomatable.
- Portal work: filing and retrieving documents on government, customs, insurance, and healthcare portals; pulling statements from supplier and carrier back-ends without APIs.
- Legacy system bridging: moving data between an old ERP and modern tools; checking order or inventory status in systems where the export button is the API.
- Cross-system reconciliation: comparing records across two systems that will never be integrated, flagging mismatches for a human.
- Repetitive research: compiling structured data from many websites — checking availability, statuses, listings — where scraping infrastructure isn't warranted.
- QA and verification: walking through your own product's flows and reporting what broke, in plain language rather than brittle test scripts.
The wrong use: anything with a good API. Browser automation is slower (a workflow that's one API call takes an agent 30 seconds of navigating), more expensive per run, and inherently less reliable. The right architecture is hybrid — APIs where they exist, browser agents for the long tail, one orchestrator over both. That's how I scope automation projects: integration inventory first, browser automation only where it's the honest answer.
Reliability: engineering around the failure modes
Raw success rates on long, open-ended web tasks are still not "fire and forget." What makes deployments reliable is constraining the problem:
- Constrain the path. "Log into portal X, navigate to section Y, download the monthly statement" succeeds far more often than "find my statements online." Production browser agents run known workflows on known sites — the model's adaptability handles layout drift, not open-ended exploration.
- Verify after every step. Don't trust that the click worked; check the resulting state (the confirmation text, the downloaded file, the row count) before proceeding. This single discipline converts flaky demos into dependable jobs.
- Checkpoint before irreversible actions. Submissions, payments, deletions: pause for human confirmation, or at minimum log-and-gate behind explicit policy. Everything before the checkpoint can safely retry; everything after must never double-execute.
- Plan for partial failure. Portals go down and CAPTCHAs appear (which agents should not bypass — that's a policy boundary, not just a technical one). Every workflow needs a defined "stuck" behavior: save state, notify a human, resume cleanly.
- Evaluate on recordings of reality. Keep traces of every run; when a failure appears, it becomes a regression case in the evaluation suite before the fix ships.
Security: the web is hostile input
A browser agent combines three dangerous properties: it reads untrusted content, it holds credentials to business systems, and it can act. That combination is exactly what prompt-injection attacks target — a page (or an email rendered in webmail, or a PDF on a portal) containing text designed to redirect the agent. This is the top-ranked risk in the OWASP GenAI taxonomy, and 2026 security guidance from government agencies treats it as a core agent threat.
Non-negotiable controls for production:
- Dedicated browser profiles with only the credentials each workflow needs — never the operator's own logged-in browser for unattended runs;
- Domain allowlists per workflow;
- Instructions come only from the operator — everything the agent reads on a page is data, and content that tries to give the agent orders is a signal to stop and escalate;
- Human confirmation on consequential actions, always;
- Full action logs — every page, click, and download — because "what did the agent do on the portal?" must have an exact answer.
Where this fits
Computer-use agents don't replace API integrations, and they don't replace judgment. What they replace is the human hours spent being the glue between systems that never learned to talk to each other — the most quietly expensive layer in operations. If part of your team's week disappears into portals and legacy screens, that layer is now automatable, and mapping which parts are ready takes one conversation.