Computer-Use Agent Engineers: hiring for verification, not demos

A Computer-Use Agent Engineer builds agents that operate real application interfaces. The agent reads a screen, decides the next step, then clicks or types, all within firm limits on what it may do.

The role matters now because a great deal of business software still has no usable API. Supplier portals, insurance dashboards and legacy back offices were built for human operators. Computer-use agents offer a new way in, and the title is only beginning to appear. The work often sits under automation engineer, test engineer or applied AI engineer.

Getting an agent to complete a task in a demo is now easy. Getting it to complete the task reliably, and to stop when it should, is the job.

What agents already do

The basic pattern is an observe, decide, act loop. The agent captures the screen or page state, receives a structured action such as click, type, scroll or wait, checks it against policy, runs it and looks again.

In practice, that means agents can work through legacy web applications. AWS describes agents driving legacy interfaces in isolated browser sessions, aimed at multi-step workflows where data is entered across several screens and checked against business rules.

Agents are also being used for interface testing. Epsilon uses Amazon Nova Act for intent-driven UI testing alongside its existing Playwright regression suite, as an addition rather than a replacement.

On live portals, the day-to-day tasks are specific: navigation, search, filtering, pagination and downloading documents, plus coping with pop-ups and changed sites.

Where agents help and a person decides

The best working pattern is shared. The agent gathers evidence and prepares a proposed action. A person approves it. BuildrLab advises showing the reviewer the evidence and the exact proposed change, and requiring approval before consequential external actions.

The engineer sits in the middle of this. They decide which steps the agent runs alone, which it drafts and which it never touches. They also decide what the reviewer sees, so that approval is a real check and not a rubber stamp.

An agent that reports success without checking the screen is a liability that happens to type quickly.

Verification is the other shared task. The agent acts, then the engineer's checks confirm the result on screen. An agent may confidently report completion even when nothing was saved. The engineer writes the checks that catch it.

What still needs a person

Setting the boundaries. Every page the agent sees becomes model input. Intertrace walks through a hotel receipt that tells an expense agent to change a bank account. Its answer is isolation, allow lists and gated clicks, and its brief says mitigations reduce these risks rather than remove them. Someone has to design those controls and enforce them outside the model.

Deciding what not to automate. Some actions are irreversible or sensitive. A person has to classify them, and the list needs ownership.

Diagnosing failure. Layouts change, sessions expire and dialogs appear. Working out why a run failed on a site you do not control is slow, detailed work. The same goes for handing cases such as multi-factor login to a human cleanly.

Judging the test suite. A suite is only useful if it represents real work, including the awkward cases. Deciding what belongs in it is a human call.

What this means for who you hire

Hire for the checking, not the clicking. The strongest profile combines interface automation, some understanding of vision models, evaluation habits and security thinking. Few people have all four, so decide which two you need on day one and which you can grow.

The profile losing value is the engineer who writes brittle scripts tied to exact selectors and has no view on measuring outcomes. Equally, the prompt-focused builder who has only shown happy-path demos is a risk. Neither has had to prove that an action worked.

Expect the first months to deliver a working agent on a defined set of real tasks in a sandbox, clear rules on which actions need approval or are blocked, a task suite the team trusts, a failure log sorted by cause, and a repeatable way to see whether each change helped or hurt.

How to spot a strong candidate

Describe a computer-use agent you built. How did it know each action had actually worked?

A good answer names concrete checks: screen state, expected elements or side effects after each step, with retries and escalation. It shows they have measured false successes and do not trust the model's own report.

How did you decide which actions the agent could never take without human approval?

A good answer describes risk classes, allow lists and approval gates enforced outside the model. It shows a clear list of sensitive actions, not a boundary that lives only in the prompt.

Where to find them

Start with former RPA and test-automation engineers. They already know how fragile interfaces are. Computer use grows out of the history of RPA, so the lineage is direct.

Application engineers and systems integrators who moved into browser automation are a second pool. Engineers from eval and tooling teams are a third, and they often bring the best task-suite habits.

Search by skill, not title. Look for Playwright, Puppeteer or Selenium experience, an understanding of the DOM and authentication flows, and evidence of evaluation work. Typical employers are AI labs and automation startups, though some of the work happens quietly inside product teams at larger software firms.

Our own analysis, drawn from the role profile in our job families library and recent public reporting on how agents are used in this work. Titles and practice vary by company.