Why We Don't Use Computer Use for Enterprise Automation

The promise

Computer use is compelling on paper. An AI agent that can see a screen and control a mouse can, in theory, use any software a human can use. No APIs needed, no reverse engineering, no integration work. Point it at the portal, describe the task, let it run.

Frontier labs have invested heavily in this. Claude, GPT-4o, Gemini, and others all have computer use capabilities. The demos are impressive. The production reality is different.

The problems in practice

Speed. A computer use agent navigates a UI at roughly human speed — sometimes slower, because it pauses to interpret what it sees before acting. A claims lookup that takes a human 90 seconds takes a computer use agent 60-120 seconds. At the request layer, the same operation takes 2-4 seconds. That's not a marginal improvement; it determines what's economically viable to automate.

Reliability. Computer use agents fail in ways that are hard to predict and hard to recover from. Popups that weren't expected, loading states that are misinterpreted, form fields that receive the wrong input because a label was ambiguous. Enterprise portals — which are often poorly designed by modern standards — are particularly difficult. They have non-standard UI patterns, inconsistent behavior, and error states that aren't clearly communicated.

Auth flows. SSO, MFA, CSRF, proprietary login sequences. Computer use agents can navigate these — slowly, with varying reliability — but they have no understanding of the underlying token mechanics. They can't extract a CSRF token from a form field and inject it into a subsequent request; they can only see and click what's rendered on screen. When an auth flow has a step that doesn't render visibly, or that requires timing precision, computer use agents struggle.

Scale. Running a computer use agent requires a full desktop environment — a virtual machine or a real workstation with a display. Running 100 concurrent automations means 100 concurrent desktop environments. The infrastructure cost is significant. Request-layer automation runs as lightweight HTTP calls; scaling is a matter of concurrency, not machines.

Where it works

Computer use is genuinely useful for one-off, exploratory tasks — "navigate to this portal and tell me what data is available" or "walk through this form and describe each field." As a reconnaissance tool, it's valuable.

It's also the right answer when you truly cannot access the request layer — some applications use binary protocols, local state, or truly opaque communication that can't be intercepted or replicated at the network level. In those cases, UI automation is the only option.

For repeatable, production workflows at scale — which is what enterprise automation actually requires — computer use is the wrong layer to automate at.

What we do instead

Every action a human performs in a browser sends HTTP requests to a server. The browser is a renderer on top of a network protocol. We work at the protocol layer.

We capture the exact requests a workflow generates — including auth, CSRF tokens, session cookies, the precise sequence and headers the server expects. Then we replay those requests directly, without rendering anything. The server can't distinguish our automation from a legitimate logged-in user, because we're sending exactly the same bytes.

The performance difference: 200-500ms per workflow step at the request layer vs 3-15 seconds per step for computer use. A 10-step workflow runs in under 5 seconds vs 30-150 seconds. At enterprise batch scale, this is the difference between overnight jobs and real-time automation.

The reliability difference: request-layer integrations break when the server-side API changes. UI-layer integrations break when anything on the page changes — including cosmetic redesigns that don't touch the underlying data at all. Server-side APIs change far less frequently than frontend design.

The self-healing layer

When a request-layer integration does break — because an endpoint path changed, a parameter was renamed, a new required header was added — we run AI self-healing. The integration tries the workflow, fails, analyzes the failure against the current portal state, generates a fix, validates it, and updates the integration automatically. The team calling the integration doesn't see a failure; they see a slightly longer response time while the fix runs.

This is categorically different from computer use reliability, where a failure means the agent navigated to the wrong place and there's no structured way to know what went wrong or how to fix it.