MicrosoftCopilot Studio

Turning capability into trust

Agents that operate websites and desktop apps

Computer use lets agents in Microsoft Copilot Studio operate websites and desktop apps the way a person does.

I was the design lead from private preview through general availability, owning setup, credentials, testing, and the hosted browser experience.

Role
Design lead
Team
PM, engineering, research, content
Timeline
2025–2026
Status
Shipped

The Add tool dialog in Copilot Studio, with Computer use offered as a tool for the Invoice Automation agent.

Copilot Studio’s Add tool dialog over the Invoice Automation agent, with a box to search for a tool or describe one, suggestions including Report generation with computer use, and featured tools from Dataverse and Excel Online to Computer use, SharePoint and Microsoft Teams.
The Add tool dialog in Copilot Studio, with Computer use offered as a tool for the Invoice Automation agent.

Overview

The model could use a browser. Makers needed everything around it.

Computer use gives a Copilot Studio agent its own computer. A maker describes a task in plain language. The agent then clicks, types, and reads the screen to get it done. It’s built for the work traditional automation handles badly: apps with no API, and interfaces that change often.

The agent gets its own computer. Add computer use, and it works beside you.

The model could already operate a browser. The product work was everything a maker needs around it: telling the agent what to do, giving it a machine, signing it into systems safely, testing behavior that isn’t the same twice, and understanding what happened when a run went wrong. Computer use was a new kind of tool for Copilot Studio, so most of that had to be designed from scratch. My job was to get a first-time maker from an idea to a working run.

I owned authoring and configuration, testing, human-in-the-loop states, credentials, allow-lists, and the hosted browser experience. I partnered with another design team on run history and observability. Private preview shipped in under 100 days. I designed that release, the public preview, and the longer-term vision in parallel, so engineering could see where the product was heading before they built each step.

Security

Giving agents a safe way to sign in

Problem
In private preview, people were typing passwords right into the agent’s instructions, in plain text.
What I did
Spotted it in research recordings and pushed for a secure place to store credentials, plus allow-lists that limit where an agent can go.
Outcome
Both shipped in public preview, and the credentials design was featured at PPCC.

During private preview, our research team ran one-on-one walkthroughs with customers. Watching the recordings with my PM, I noticed something in a few of them: makers were typing passwords straight into the agent’s instructions. It was the easiest way to get the agent signed in, and it worked. It also put credentials in plain text, in a field that gets shared, copied, and sent to a model.

Passwords typed into a maker’s instructions, then marked in red, twice.

In sessions focused on whether the agent could finish the task, it was easy to miss. To me it was a glaring security problem. I raised it and pushed for a dedicated Credentials surface, backed by a secure key vault. Makers store a login once and point the agent at it. The password never appears in the instructions.

My concept: stored credentials and access control.

The Update shipment portal tool page in Copilot Studio, with handwritten notes proposing credential management across Copilot Studio, a Stored credentials area below the instructions and an Access control area for site tolerance, and sticky notes of open questions and feedback around it.
My concept: stored credentials and access control.

The flow I proposed, against the current one.

A flow diagram titled Create new credential, Proposed experience, from entering Copilot Studio through adding a tool, a Computer Use recommendation and its configuration, with handwritten notes comparing the current experience, a v2 proposal and Copilot Studio's capabilities.
The flow I proposed, against the current one.

I paired credentials with allow-lists, which define exactly which sites and apps the agent is allowed to touch. If a run tries to go anywhere else, it stops.

The tradeoff was real. It meant one more setup step, and one more surface to build, on a feature whose whole pitch was “just describe the task.” I argued it was worth it: makers get a safe way to sign agents in, and IT gets a reason to approve them. That argument landed with Microsoft’s broader push on customer security. Credentials and allow-lists shipped with public preview, and the credentials design was featured in several sessions at PPCC (Power Platform Community Conference).

A login is stored once, by pointing at a secret in Azure Key Vault, and listed under the tool’s instructions. The password never goes into them.

First run

Making the hosted browser the default

Problem
Setting up a machine usually took an admin, and it was the biggest thing stopping people from getting to a first run.
What I did
Made the hosted browser the default, and added starter templates and a more structured instruction box.
Outcome
At GA, people could run computer use with no machine setup.

Computer use had a hidden second user. The maker building the agent usually wasn’t the person who could set up the machine it ran on. That took an admin, with a completely different skill set. So a maker could build an agent, then get stuck on setup they didn’t know how to do.

Machine setup got easier with each release, but it was still the biggest barrier to a first run. Research also showed that most makers weren’t sure what computer use could do yet. They were trying it to find out, and they didn’t need a custom machine for that.

The hosted browser, powered by Windows 365, arrived in public preview as one option among several. For GA, I made it the default. Now a maker can add computer use and run it with no machine setup at all. Registering your own machine is still available for internal sites and desktop apps, but it’s no longer the first thing people hit.

I made the first run easier in two other ways. I added structure to the instruction box (ordered and unordered lists, and clearer placeholders) and starter templates for common tasks, so people started from a good example instead of a blank box.

Computer-using agent is one of the starting points on the create page.

Copilot Studio create page with cards for Create workflow, Create autonomous agent and Computer-using agent.
Computer-using agent is one of the starting points on the create page.

The new computer use tool dialog offers prompt templates, so a maker starts from an example instead of a blank box.

A New computer use tool dialog with a description field and three prompt templates, such as Automated data processing.
The new computer use tool dialog offers prompt templates, so a maker starts from an example instead of a blank box.

The tradeoff: the hosted browser limits what the agent can reach. I accepted that because the default should match what most people are actually doing, and early on, that’s exploring.

Testing

Building testing on a pattern makers already knew

Problem
People needed to see what the agent did and why, but engineering couldn’t build the full testing experience all at once.
What I did
Designed a first version on an existing pattern, plus the later versions that build toward the full experience.
Outcome
The first version shipped and became part of Copilot Studio’s shared tools library.

Traditional automation does the same thing every time it runs. Computer use doesn’t. Makers need to see what the agent did and why, so they can fix their instructions.

Before: Copilot Studio tests were a simulated chat.

The agent test canvas, a chat to simulate an end user beside test scenarios, covered in sticky notes of open questions about how testing works.
Before: Copilot Studio tests were a simulated chat.

After: computer use tests ran in a live browser.

A Computer Use test run, the agent's messages on the left and a live browser on the right where its cursor is about to download a weekly offers flyer.
After: computer use tests ran in a live browser.

I designed several versions of the test experience. With engineering time split across feature areas, the one that shipped extended Copilot Studio’s existing tool-testing pattern. It shows the agent’s screen and its reasoning side by side. Makers can watch it work, spot the step where it went wrong, and adjust.

A test run in the hosted browser. The agent works through a form while its reasoning updates alongside.

Building on an existing pattern kept testing shippable as priorities moved. It also meant makers didn’t have to learn a new way to test. I added the designs to Copilot Studio’s shared tools library so other teams building agent tools could use them.

Three versions of the test experience, V1 to V3, each showing the agent's screen alongside its steps.

Three test-experience layouts labeled V1, V2 and V3, growing from small side-by-side views to a large run with chat and Excel.
Three versions of the test experience, V1 to V3, each showing the agent’s screen alongside its steps.

Outcome

From private preview to GA in about a year

Looking back

Ship clarity first, then capability

Platform dependencies and shifting priorities forced scope cuts, especially in testing. What worked was the order we shipped in: clarity first (setup, credentials, a first run that works), then more capability.

If I did it again, I’d make human-in-the-loop states more visible earlier. After launch, it wasn’t always clear whether an agent was waiting on a person or just stuck.