> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Computer Use

> Agents that operate software UIs directly — for the systems in your stack that have no API.

# 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.

<Note>
  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](/computer-use-agent).
</Note>

## When to use it

| Situation                                                                   | Reach for                                                                              |
| --------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| The system has a REST or GraphQL API                                        | A [function](/response-api-reference/functions/list) — always faster and more reliable |
| The system is in the [186 native integrations](/api-reference/integrations) | The integration                                                                        |
| Browser-only admin panel, no API                                            | **Computer Use**                                                                       |
| Legacy internal tool nobody will rebuild                                    | **Computer Use**                                                                       |
| The same form filled across three unrelated systems                         | **Computer Use**                                                                       |

<Warning>
  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.
</Warning>

## 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:

| Constraint                                       | Why                                                   |
| ------------------------------------------------ | ----------------------------------------------------- |
| No account creation                              | Prevents an agent from provisioning identities        |
| No social-media posting                          | Prevents unreviewed public statements                 |
| Keyboard shortcuts preferred over mouse movement | Substantially more reliable than coordinate targeting |
| Verification steps built into the loop           | The agent confirms an outcome rather than assuming it |
| Suited to non-time-critical work                 | A retry loop on a slow UI is not a real-time path     |

<Tip>
  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](/next-temporal/overview) instead.
</Tip>

## 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:

| Metric          | Typical      |
| --------------- | ------------ |
| Tokens per task | \~7,500      |
| Cost per task   | \~\$0.11     |
| Duration        | \~30 seconds |

Figures are order-of-magnitude for representative tasks; a long multi-system flow costs
proportionally more. Billing is [outcome-based](/stateset-billing) — you're charged for resolved
work, not for screenshots.

## Isolation

Computer Use agents run inside the [Sandbox](/stateset-sandbox/stateset-sandboxes), so an agent
driving a browser is contained rather than running on a shared host. See
[Runtime Selection](/stateset-sandbox/stateset-sandbox-runtime-selection) for the isolation
boundaries available.

## Related

* [StateSet Computer Use Agent](/computer-use-agent) — the full platform
* [Computer Use MCP](/computer-use-mcp) — driving it from an MCP client
* [Computer Use Engines MCP](/computer-use-engines-mcp)
* [Architecture](/guides/stateset-computer-use-agents-architecture)
* [Getting started guide](/guides/stateset-computer-use-agents)