Skip to main content

​
Computer Use

Most of ResponseCX reaches other systems through APIs. Computer Use exists for the systems that don’t have one: the legacy admin panel, the carrier portal, the ERP screen that was never meant to be automated. A Computer Use agent perceives the screen and reasons about what it sees. That’s the difference from RPA, which encodes pixel positions and breaks the moment a button moves.
This page is orientation — where Computer Use fits inside ResponseCX and when to choose it. The full platform, tools, and deployment model are documented in StateSet Computer Use Agent.

​
When to use it

Computer Use is the last option, not the first. A UI is an unstable contract: it changes without a version bump and without notice. If an API exists, use the API — you will spend less time maintaining it.

​
What it’s good at

  • Automated onboarding and paperwork flows
  • Repetitive data entry across systems that don’t talk to each other
  • Closing or triaging tickets by a mechanical rule
  • Form filling spanning several unconnected systems
  • Reaching a legacy system without waiting for an API to be built

​
Operating constraints

These are deliberate, not incidental:
Read these as the boundary of the supported envelope. A task that needs to be inside a second, or that must not be retried, is the wrong shape for Computer Use — put it behind an API or a Temporal workflow instead.

​
Designing a task that works

The failure mode is almost never the model — it’s an underspecified task.
  1. Decompose. Break the work into steps small enough that each has one observable outcome. “Issue the refund” is three steps: find the order, open the refund form, submit and confirm the confirmation banner.
  2. State the success condition explicitly. Say what the screen should look like when the step worked. Without it the agent cannot tell success from a silently-failed submit.
  3. Prefer keyboard navigation. Tab and Enter survive a layout change; a click at (412, 380) does not.
  4. Include example screenshots for tasks you’ll run repeatedly. They anchor the agent to the actual UI instead of a guess about it.
  5. Start on non-critical work. Prove the loop on something recoverable before you point it at anything that moves money.

​
Cost and duration

Context engineering keeps a Computer Use task far cheaper than a naive screenshot-per-turn loop: Figures are order-of-magnitude for representative tasks; a long multi-system flow costs proportionally more. Billing is outcome-based — you’re charged for resolved work, not for screenshots.

​
Isolation

Computer Use agents run inside the Sandbox, so an agent driving a browser is contained rather than running on a shared host. See Runtime Selection for the isolation boundaries available.