A computer use agent operates software through the screen, like a person with a mouse and keyboard.

Computer use is the widest way for an agent to act.

The agent receives a screenshot or other visual representation of a desktop, then chooses an action such as click, type, scroll, or wait. From the system’s perspective, it behaves like a person operating the machine.

This is different from an API integration, where software calls a defined endpoint, and from browser-native control, where the agent can inspect web-page structure. Computer use is most valuable when neither of those narrower paths is available.

The same flexibility creates reliability work.

A visible interface is full of incidental detail: notifications, animations, window size, zoom level, overlapping dialogs, disabled buttons, and labels that look alike. A computer use agent has to distinguish the important control from the rest and verify that its action succeeded.

That makes short supervised tasks a sensible starting point. For a longer process, break the work into checkpoints, record what “done” looks like, and make the agent stop when the screen does not match the expected state.

Browser-native control is better for web-only tasks.

A browser agent can read a page’s interactive elements and content as page structure, not merely as coloured pixels. It can locate the real input, button, link, or table entry even when layout changes slightly.

That is why Strawberry is designed around browser work. It can combine a tab you are signed into with connected apps and files, then return a prepared result. Desktop-level computer use remains a useful category for work that genuinely needs the whole operating system.

The right safety rule is proportional to the consequence.

An agent clicking “next” in a local test tool is not the same as an agent clicking “transfer,” “send,” or “delete.” Screen-based agents can reach powerful parts of a computer, so the review point should arrive before the action becomes externally meaningful.

In Strawberry, browser workflows can prepare submissions, messages, and updates but pause before consequential steps. That makes a routine useful for the repetitive preparation while leaving the final call to the person responsible for it.

Frequently asked questions