Computer-use agents went GA. The orchestration problem just got harder.

By Nick Beaugeard · 6 minute read · ← All posts

Microsoft made computer-use agents generally available in Copilot Studio on 13 May 2026, rolling out to every commercial Power Platform geography. An agent now gets the same tools a person has - a browser, a screen, a keyboard - and uses vision and reasoning to drive a live interface, adapting when fields move or layouts shift rather than snapping the moment a selector changes. The GA build ships with OpenAI's computer-use model and Claude Sonnet 4.5 behind it, Azure Key Vault for credentials, Purview audit logging and configurable human-in-the-loop review. As of late May, Anthropic's own computer use was still in paid beta and Google's in public preview, so Microsoft genuinely got there first.

This is a real milestone, and it deserves the attention it got. It also quietly moved the hard part of the problem somewhere most teams are not looking.

Why this is a big deal

Robotic process automation has promised "the bot uses the app like a person" for fifteen years. It never delivered, because selector-based automation is brittle: a renamed button or a shifted div breaks the whole script, and someone spends Friday afternoon repairing robots. Vision-and-reasoning computer use breaks that failure mode. The agent looks at the screen, works out what to do, and carries on when the UI moves. For the long tail of systems with no API - the legacy portal, the vendor dashboard, the government website - that is the difference between automatable and not.

So the capability is genuinely new. The trap is treating a new capability as a finished solution.

What GA does not give you

A computer-use agent is, by construction, non-deterministic. The same task on the same screen can take a different path on a different day, because the model is reasoning about pixels in the moment. That is exactly what makes it robust to layout change - and exactly what makes it dangerous when the action on the other side of the click is irreversible. "Adapts when workflows branch" and "took a branch nobody intended" are the same sentence read in two moods.

The questions GA does not answer for you are the ones that matter in a regulated business:

• What was it actually trying to do? A screen recording of an agent clicking is not a specification. It is an artefact. If the only record of intent is the prompt that scrolled out of a chat box, you have automated the work and lost the why.
• How do you know it did the right thing? Vision-based action without an acceptance check is hope with a login. You need a test that says "after this run, the invoice is marked paid exactly once," not a vibe that it looked fine.
• What stops it doing the wrong thing at scale? Human-in-the-loop review is in the box, which is good. But review you have to remember to switch on is review that gets switched off the first busy week.

The implication for orchestration

Computer use is a powerful actuator. It is not a control system. The lesson we keep relearning - and the one this release sharpens - is that the value and the risk both live in the layer around the agent, not in the agent itself. An orchestrator's job is to make a non-deterministic actor produce a governable outcome.

Concretely, that means four things wrapped around every computer-use action:

An authored spec, not a recorded prompt

The instruction the agent works from should be a versioned, reviewed statement of intent and guarantees, not an ephemeral prompt. This is the whole argument behind Symphony: the spec is the source of truth, the agent's run is a build artifact. When the spec is the thing you keep, "why did it do that?" has an answer you can read.

Isolation per task

Each unit of work runs in its own contained workspace with its own credentials and its own blast radius. Spark-style and Copilot-style agents already lean on ephemeral VMs for exactly this reason; an orchestrator should make that the default, not an option.

Acceptance checks that gate the side effect

Before an irreversible action settles - payment, submission, deletion - an explicit check derived from the spec has to pass. The orchestrator owns that gate. The agent does not get to mark its own homework.

An audit trail by default

Purview logging is a strong primitive, but logging the clicks is not the same as logging the decisions. The trail you want ties the action back to the spec it came from and the review that approved it. That is what a regulator, or a nervous CFO, actually asks for.

The takeaway

The most useful way to read 13 May is not "agents can use software now." It is "the cheap part of automation just got cheaper, and the expensive part - knowing precisely what you wanted and proving you got it - is now the whole job." That expensive part is orchestration: spec, isolation, acceptance, audit. Microsoft handed everyone a far better actuator. What you build around it decides whether it is an asset or a liability.

A computer-use agent makes the click reliable. Only an orchestrator makes the outcome accountable.

We build that wrapping for clients every week inside Symphony. If you are about to point a computer-use agent at something that can move money or data, talk to a senior engineer before you point it at production - get in touch.