Computer-use agent
A computer-use agent observes a computer interface and chooses actions intended to advance a task. It may work through screenshots, interface elements, keyboard input, or other tools. Unlike a system that only suggests instructions, it can change application state. That makes the surrounding permissions, stopping rules, and success checks part of the system’s practical design.
How it works
A typical interaction loop observes the current state, chooses an action, performs it, and checks the result. A task such as reconciling a spreadsheet with a service system may require many such steps and movement across applications. Some systems combine visual interaction with APIs; the label does not require every action to be a simulated mouse click.
The OSWorld benchmark illustrates evaluation in real computer environments using tasks with initial states and execution-based checks. A successful-looking screenshot is not necessarily evidence that the requested file, record, or setting was changed correctly. Evaluation needs to inspect the relevant outcome and account for side effects.
Why it matters for licensing
Business workflow records can describe the context, sequence, and outcomes of software-mediated work. For agent research, those details may help distinguish a meaningful demonstration from an isolated screenshot. Useful documentation can identify the application version, user role, starting state, actions, errors, and final result.
Such records may also expose customer information, credentials, employee activity, and third-party interfaces or content. A licensing assessment must address those constraints. The existence of a workflow log does not mean it is automatically suitable or authorized for agent training, and this definition does not claim that Rancher supplies any specific agent dataset.
Example
Fictional example: An agent is asked to prepare a draft purchase request from an approved inventory report. It reads the report, enters item details in procurement software, checks the total, and stops before submission. A verifier confirms the draft contains the intended items and that no order was sent. A training record would need enough context to show both the authorized task and the boundary the agent respected.
Limitations and misconceptions
Interface changes, ambiguous instructions, pop-ups, missing access, and unreliable observations can interrupt a task. An action that works in one software version may fail in another. Longer workflows also create more opportunities for errors to compound.
Benchmark performance does not establish reliability on every business process. Production evaluation should test permissions, recovery, auditability, and unwanted actions alongside task completion. Human review can be required before consequential actions; the word “agent” is not a guarantee of safe autonomy.
Questions to ask
- What was the starting state, and which actions was the operator authorized to take?
- Can the intended outcome and unintended side effects be checked independently?
- Do workflow records contain sensitive information or third-party material that must be excluded?