Copilot Studio Computer Use: Roadmap Item Cancelled, but Core Feature Remains Available

If you're an admin who just saw "Cancelled" next to "computer use" and started rewriting your automation plans, you can stop. The roadmap entry has been withdrawn. The product is still here.

What the roadmap entry promised​

Item 562220 described AI-driven UI automation built into workflows. Makers would build reusable, goal-oriented automations that adjust when a website or app changes. Admins would keep governance through access controls, hosted browser management and environment-level permissions. The entry's metadata:

Microsoft gave no reason beyond the boilerplate apology. That matters for how you read it.

Why "cancelled" probably doesn't mean what it sounds like​

The roadmap page itself warns that dates are estimates. It also says items are removed when a feature becomes generally available, or when it's cancelled or postponed. So removal can mean any of those things.

In this case, the dates suggest the roadmap simply fell behind. The entry targeted October 2026 for GA, but Microsoft's Copilot Studio team announced months earlier that computer use in Microsoft Copilot Studio is now generally available, and we're expanding availability to all commercial geographies in Microsoft Power Platform. Several outlets put that announcement at May 13, 2026. Microsoft's May 2026 "What's new in Copilot Studio" post said the same thing: with computer-using agents now generally available in Copilot Studio, organizations can build agents that interact directly with websites and desktop applications through the user interface (UI).

There's one caveat, and the entry's title hints at it: "Supercharge your workflows." Some GA coverage listed embedding computer use in workflows as a separate preview feature. One partner blog described it as a particularly powerful new capability lets you embed computer-using agents directly into Copilot Studio workflows. This means you can combine API-based actions, approvals, business logic, and adaptive UI interactions all within the same automation flow. Microsoft Learn's computer use page also links to a separate article on standalone computer use tools in agents and agent flows, which is still labelled preview.

So here's the honest answer. The core tool is GA. The withdrawn entry could just be stale, or it could have covered the workflow-embedding scenario in particular, whose timing or packaging may have changed. Microsoft hasn't said which. If your plans depend on computer use inside workflows specifically, don't treat 562220's October date as a commitment. It no longer is one.

Section summary: The roadmap entry was withdrawn and the feature wasn't. Core computer use has been GA since May. The workflow-embedding piece is the only part where the status is unclear.

What computer use actually does​

Microsoft Learn describes computer use as a Copilot Studio tool that lets an agent work a Windows computer, on websites and in desktop apps, the way a person would. It clicks buttons, picks menu items and types into fields using a virtual mouse and keyboard. You describe the task in plain language. Microsoft pitches it for systems with no API and gives automated data entry, invoice processing and data extraction as examples.

It runs on Computer-Using Agent (CUA) models, which combine vision with reasoning. Microsoft says they cope with interface changes, so a moved button shouldn't break the run the way a screen-scraping script would. Microsoft's May post said it helps you automate processes that previously relied on brittle scripts or manual workarounds because the underlying systems lacked APIs.

The main requirement: the tool only works in agents with generative orchestration turned on. One analysis of the GA release pointed out that agents using the classic orchestration mode cannot use the CUA tool — a requirement that limits GA adoption to makers who have already migrated to the newer orchestration pattern.

Adding computer use to an agent​

According to current Microsoft Learn documentation:

1. Open your agent's Tools page and select Add tool.
2. Select New tool, then Computer use.
3. Write instructions describing the task. Instruction templates are available as a starting point.
4. Select Add and configure, then fill in the four required fields: Name, Description (this tells the agent when to use the tool), Model and Instructions (include URLs and application names).
5. Review the optional settings if you need them, then select Save.

The optional settings are where most of the governance work happens:

• Inputs: values that change on each run, such as a different form value every time.
• Machine: the target computer. Links go to Power Automate's machine management and details pages.
• Connection and Credentials to use: either maker-provided credentials (the default, suited to autonomous agents) or end-user credentials.
• Human supervision: a reviewer who gets an Outlook email when the agent spots potentially harmful instructions. If nobody responds before the time limit, the run stops.
• Stored credentials: kept either in Power Platform's encrypted internal storage or in your own Azure Key Vault.
• Access control and Enforce HTTPS.

To test, save the tool and select Test. The left panel shows a step-by-step log of the agent's reasoning and actions, and the right panel shows a live preview of the machine. Stop testing halts everything immediately. When the run finishes you'll see a "Test completed" message. If the result is wrong, tighten your instructions and run it again.

Where it commonly goes wrong​

The maker-credentials warning. Microsoft says plainly that if you share an agent set to maker-provided credentials, anyone using it can act with the author's access on the configured machine. That's privilege delegation, and it's on by default. Check it before you publish.

The allow list blocks actions, not navigation. By default, computer use can act on any website or app. Turning on access control restricts it to the URLs and applications you list. But Microsoft's own example shows the limit: with only microsoft.com and Microsoft Edge allowed, the agent can still open Bing from Edge's search bar. It just can't interact with Bing once it gets there. For a real block, you need controls on the machine itself.

Unsupported app types. Password fields work on websites and most Windows frameworks: WinForms, WPF, UWP, WinUI and Win32. Microsoft warns that Electron, Java, Unity, games, command-line tools, Citrix and other virtualized environments may not work. If your legacy line-of-business app is delivered over Citrix, test it before you promise anything.

Key Vault prerequisites. The Azure subscription holding the vault needs the PowerPlatform resource provider registered. The person creating the environment variable also needs the right permissions on the vault.

Vague instructions. Microsoft recommends giving full URLs and exact app names, saying explicitly when the agent should do something consequential (submitting a form, for example), and breaking tricky UI steps into numbered lists.

Conversational mode. Microsoft says computer use works best in autonomous agents that run in the background. In a conversational agent, such as one in Teams, each user needs valid credentials for the machine if user authentication is on. The chat also shows reasoning messages and screenshots of the machine. Think about what's on that screen before you put the agent in a busy channel.

Hardening the machine​

Microsoft's recommendations line up with standard Windows practice:

• Use dedicated, isolated machines for computer use.
• Run the agent's account with least privilege.
• Restrict web access to a list of vetted domains, for example through Microsoft Edge policies deployed with Intune.
• Use application control so only the apps the workflow needs can run.

This is where the allow-list gap gets closed: endpoint management on the machine, not configuration in Copilot Studio.

What it costs​

Computer use is billed through the Agent action feature. Each step uses 5 Copilot Credits, or 15 with a premium model. A step can include several clicks or keystrokes. The following models are available for computer use:

Anthropic models only appear if an admin has enabled external models for the environment. Microsoft's own example is a four-step timesheet submission: 20 credits on a standard model, 60 on premium. Multiply that by a few thousand invoices a month and model choice becomes a budget decision.

Is it reliable enough?​

Microsoft's GA messaging stresses governance, including allowing lists for websites or desktop applications and native Power Platform governance capabilities such as DLP policies, environment isolation, and audit trails, plus run history that is also propagated to Purview and Dataverse for audits and admin review. Independent coverage is more cautious. The review site ChatForest reported roughly 80% success on web apps and said desktop success rates are still ~35%. Those are third-party figures, not Microsoft benchmarks, and your results will depend on your apps. Still, it's a good reason to pilot on browser-based work first.

There's also the usual RPA question: should you be automating the UI at all? If a supported connector or API exists, it will be cheaper and more predictable than paying per step for an AI to click through the same screens.

What to do now​

• Don't schedule around roadmap item 562220. Its dates and promises no longer apply.
• Core computer use is GA. Plan from the Microsoft Learn documentation, not the roadmap.
• Check prerequisites: generative orchestration, machine registration, model access, and the external-models setting if you want Anthropic models.
• Fix the defaults: review maker-credential sharing, and back up the allow list with Intune Edge policies and application control.
• Treat workflow embedding as preview until Microsoft says otherwise.

The roadmap is meant to be a forecast. This time it drifted behind the product, and Microsoft corrected it with a single line that sounds far worse than what actually happened.