What computer use exposes in business software

Anthropic released its computer-use capability in public beta this month, and the company itself describes it as experimental and at times cumbersome and error-prone. I'd take that seriously. A model driving a screen gets all the uncertainty people quietly work around every day, without the context a regular user has built up, so before giving one a login I'd go and look hard at the screens it'll be using and at what the account is allowed to do.

People learn that "Process" on one screen means preview and on another means commit, and they remember which grey button is actually disabled. A model has to work that out from the current screen and its instructions. Labels that name the effect help a lot here: "Create draft invoice", "Send message", "Delete import". If an action has a scope, show it, so "Archive 126 records" instead of "Continue". Icon-only buttons and similar-looking controls sitting next to each other make things brittle, and that's an accessibility problem for people as well, which is a good enough reason to fix it whether or not an agent ever touches the screen.

State is the other big one. Business software carries a lot of it in selected filters, the active account, unsaved edits, background jobs and permissions, and an agent can miss that and do a perfectly valid thing in the wrong place. Before a bulk update I'd want the account, filter, number of affected records and the proposed change shown together on the confirmation screen. Saves need a clear result, controls should be disabled while a request is running, and an expired session shouldn't silently drop the agent onto a login page where it might type task data into the email field.

Then restrict the account before trying to fix everything with prompting. Give it only the applications, records and actions the named task needs, let it prepare drafts or batches, and have a person approve anything that sends, deletes, pays or publishes, with the approval showing the actual effect. Credential changes, permission grants and sensitive exports probably shouldn't go through this route at all. Screen content also needs to be treated as data, because a page or document the agent is reading can contain text that looks like an instruction to it. I'd restrict navigation to approved domains and have the agent stop if the interface goes somewhere unexpected.

For records, a chat transcript doesn't tell you what happened on screen. I'd want the application, account, time, each action and its result, approvals, and every retry along with the attempt that finally worked, with screenshots or structured observations at the important steps. Passwords and session tokens stay out of it.

Testing one successful path and recording a video of it won't tell you much. I'd interrupt the path on purpose with a slow page, a validation error, an expired session, an unexpected modal, a duplicate click, a filter changed halfway through and an untrusted instruction in the displayed content, and check whether the agent stops, recovers or makes things worse. That's what computer use exposes in business software: the vague labels, hidden state and irreversible buttons people have been quietly working around, which an agent has to deal with from the screen alone. So I'd start with read-only work, then drafts, fix the screens and account permissions those interrupted runs show up, and keep a manual stop control outside the interface being operated so it's still there if navigation goes wrong.