Fala dataholics, fechando a sequência de novidades do Copilot com a que eu achei mais divertida de testar. Todo mundo que trabalha com integração já esbarrou naquele sistema que não tem API, não tem conector e o fornecedor sumiu. O Windows 365 for Agents é a resposta da Microsoft pra isso: um servidor MCP que dá ao seu agente o controle de um Cloud PC inteiro.

O que veremos nesse post:

• O que esse MCP server entrega

• Como funciona a sessão

• O que o agente consegue fazer no desktop e no browser

• Os limites de segurança, que são muitos

Um Cloud PC como ferramenta do agente

O Windows 365 for Agents é um servidor MCP que você pluga no agente e que dá controle operacional completo de um Cloud PC do Windows 365. São três frentes: interação de desktop com mouse, teclado, captura de tela e execução de comando; automação de browser via Microsoft Edge; e inspeção semântica de interface usando o Windows UI Automation.

Ele ficou GA em junho e o server id é mcp_W365ComputerUse. Se você já leu a parte 3 da série de tools e conectores, o caminho de plugar é o mesmo de qualquer outro MCP.

Tem um detalhe que passa batido e que amarra com o post de harness lá do começo da semana: a documentação avisa que essa feature roda no standard harness, com o licenciamento clássico, e não no GitHub Copilot harness. Ou seja, computer use não te obriga a entrar no modelo de crédito.

A sessão é o começo de tudo

Nada acontece sem sessão. Você chama StartSession, ele conecta e aloca o recurso de Cloud PC e devolve um sessionId. No fim você chama EndSession passando esse id pra liberar a máquina, e tem GetSessionDetails pra consultar metadado de uma sessão específica.

Aqui vai um cuidado bem prático que está escrito na doc: pra manter sessão longa viva, mande alguma requisição pelo menos a cada 30 minutos, senão ela é despejada por inatividade. A sugestão deles é usar o get_screen_size como heartbeat, porque é leve. Guarda esse detalhe, é o tipo de coisa que quebra automação demorada de madrugada e você fica sem entender.

O que o agente consegue fazer

No desktop ele clica (com os cinco botões do mouse, incluindo duplo clique), arrasta com precisão de pixel, rola a tela, digita texto e combinação de teclas, tira screenshot da tela inteira ou de um recorte, dá zoom numa região pra ler texto pequeno, roda OCR na tela toda devolvendo confiança e bounding box de cada trecho, lista e ativa janela por título aproximado, mexe no clipboard, lista e mata processo e abre aplicação.

No browser ele navega, lê texto e HTML da página, clica e digita por seletor CSS, preenche formulário inteiro numa chamada, troca de aba, salva a página em PDF e ainda tira o accessibility snapshot, que devolve a árvore da página com ref ids estáveis pra você clicar por referência em vez de coordenada. Bem mais confiável que ficar mirando pixel.

Uma sequência típica de preencher formulário fica mais ou menos assim:

StartSession                    -> devolve sessionId
browser_navigate                url da pagina
browser_wait_for                seletor do formulario
browser_fill_form               lista de {selector, value}
browser_click                   #submit-btn
browser_wait_for                seletor da confirmacao
browser_get_text                le o resultado pra validar
EndSession                      libera o Cloud PC

E pra aplicação desktop, onde não existe seletor CSS, o caminho é outro:

activate_window                 titulo parcial da janela
take_screenshot                 estado atual
find_ui_element                 role: "Button", name: "Salvar"
click                           usa as coordenadas devolvidas acima
type_text                       preenche o campo
press_keys                      ["ctrl","s"]
take_screenshot                 confere o resultado

O find_ui_element é a peça que faz isso funcionar sem gambiarra, porque ele procura por texto, papel do controle ou nome acessível e devolve a coordenada clicável. Você não fica dependendo de o botão estar sempre no mesmo lugar da tela.

Os limites, e eles são bem-vindos

Essa é a parte que eu recomendo ler com calma antes de prometer automação pro time, porque o ambiente é bem cercado:

• Shell com allow list - só passam git, npm, dotnet, python, cargo, node, pip, dir, mkdir, del, copy, move, robocopy, findstr, where, type e notepad.

• Padrões bloqueados - metacaractere de shell (pipe, ponto e vírgula, e comercial, redirecionamento), expansão de variável, flags de eval como python -c e node -e, git config --global, npm -g, rm -rf e sudo.

• Sandbox do Python - até 262.144 caracteres de código, 512 MB de memória e 30 segundos de execução.

• Timeout - 30 segundos por padrão nos comandos, teto de 120 segundos, e stdout e stderr truncam em 32 KB cada.

• Sem tool de arquivo - não existe leitura e escrita dedicada. Você lê com o comando type e escreve com Python, porque o redirecionamento de saída está bloqueado.

• Cookie redigido - dá pra listar nome, domínio, path e flags, mas o valor nunca é devolvido.

• Só Edge no DOM - o focus_browser até foca Chrome e Firefox, mas as tools de DOM funcionam apenas na instância do Edge.

E tem um detalhe que eu achei sensacional: existe um failsafe de cursor, então se o ponteiro chegar a cinco pixels de qualquer canto da tela as operações de mouse são canceladas. É o clássico "mata a automação puxando o mouse pro canto", só que embutido no produto.

Reginaldo, então dá pra automatizar qualquer sisteminha legado com isso?

Dá, e é exatamente pra isso que serve, só que eu iria com calma. Automação por interface quebra quando a tela muda, e agora quem vai clicar é um modelo interpretando screenshot e árvore de acessibilidade. Onde existir API ou conector, use a API. Guarde o computer use pro que realmente não tem outro caminho, e monte o fluxo verificando o resultado a cada passo, que é o motivo de aquele take_screenshot final estar ali no exemplo.

RESUMO

• Windows 365 for Agents é um MCP server que dá ao agente um Cloud PC inteiro, GA desde junho.

• Roda no standard harness, então não entra no modelo de Copilot Credits.

• Sessão explícita com StartSession e EndSession, e heartbeat a cada 30 minutos em processo longo.

• Desktop, browser via Edge e inspeção de UI, com find_ui_element evitando clique por coordenada fixa.

• Allow list no shell, sandbox no Python, cookie redigido e failsafe de cursor.

• Use quando não existir API, e valide cada passo do fluxo.

Com isso fecho a sequência de novidades do Copilot dessa semana. Comenta aí qual sistema da sua empresa você colocaria nesse agente primeiro, aposto que todo mundo tem um candidato na cabeça.

Referências:

Windows 365 for Agents MCP server

Windows 365 for Agents

Espero que tenha gostado.

#windows365 #mcp #copilotstudio #computeruse #microsoft #ia #agentes #datainaction

Hey dataholics, closing this run of Copilot news with the one I had the most fun testing. Anyone who works with integration has run into that system with no API, no connector and a vendor who vanished. Windows 365 for Agents is Microsoft's answer to that: an MCP server that hands your agent control of an entire Cloud PC.

What we'll see in this post:

• What this MCP server delivers

• How the session works

• What the agent can do on the desktop and in the browser

• The security limits, and there are many

A Cloud PC as an agent tool

Windows 365 for Agents is an MCP server you plug into the agent that gives full operational control of a Windows 365 Cloud PC. There are three fronts: desktop interaction with mouse, keyboard, screen capture and command execution; browser automation through Microsoft Edge; and semantic UI inspection using Windows UI Automation.

It went GA in June and the server id is mcp_W365ComputerUse. If you've read part 3 of the tools and connectors series, plugging it in is the same path as any other MCP.

There's a detail that slips by and ties back to the harness post from the start of the week: the docs warn that this feature runs on the standard harness, with classic licensing, and not on the GitHub Copilot harness. So computer use doesn't force you into the credit model.

The session is where everything starts

Nothing happens without a session. You call StartSession, it connects and allocates the Cloud PC resource and returns a sessionId. At the end you call EndSession passing that id to release the machine, and there's GetSessionDetails to look up metadata for a specific session.

Here's a very practical warning written in the docs: to keep a long session alive, send some request at least every 30 minutes, otherwise it gets evicted for being idle. Their suggestion is to use get_screen_size as a heartbeat, because it's lightweight. Keep that one in mind, it's the kind of thing that breaks a long overnight automation and leaves you scratching your head.

What the agent can do

On the desktop it clicks (with all five mouse buttons, double click included), drags with pixel precision, scrolls, types text and key combos, takes a screenshot of the full screen or a crop, zooms into a region to read small text, runs OCR across the whole screen returning confidence and bounding boxes per chunk, lists and activates windows by fuzzy title, works the clipboard, lists and kills processes and launches applications.

In the browser it navigates, reads page text and HTML, clicks and types by CSS selector, fills a whole form in one call, switches tabs, saves the page as PDF and also takes an accessibility snapshot, which returns the page tree with stable ref ids so you can click by reference instead of coordinates. Far more reliable than aiming at pixels.

A typical form-filling sequence looks roughly like this:

StartSession                    -> returns sessionId
browser_navigate                page url
browser_wait_for                form selector
browser_fill_form               list of {selector, value}
browser_click                   #submit-btn
browser_wait_for                confirmation selector
browser_get_text                read the result to validate
EndSession                      release the Cloud PC

And for a desktop application, where there is no CSS selector, the path is different:

activate_window                 partial window title
take_screenshot                 current state
find_ui_element                 role: "Button", name: "Save"
click                           uses the coordinates returned above
type_text                       fills the field
press_keys                      ["ctrl","s"]
take_screenshot                 check the result

find_ui_element is the piece that makes this work without hacks, because it searches by text, control role or accessible name and returns the clickable coordinate. You don't end up depending on the button always sitting in the same spot on screen.

The limits, and they're welcome

This is the part I'd read carefully before promising automation to your team, because the environment is well fenced:

• Shell with an allow list - only git, npm, dotnet, python, cargo, node, pip, dir, mkdir, del, copy, move, robocopy, findstr, where, type and notepad get through.

• Blocked patterns - shell metacharacters (pipe, semicolon, ampersand, redirection), variable expansion, eval flags like python -c and node -e, git config --global, npm -g, rm -rf and sudo.

• Python sandbox - up to 262,144 characters of code, 512 MB of memory and 30 seconds of execution.

• Timeout - 30 seconds by default on commands, a 120 second ceiling, and stdout and stderr truncate at 32 KB each.

• No file tool - there's no dedicated read and write. You read with the type command and write with Python, because output redirection is blocked.

• Redacted cookies - you can list name, domain, path and flags, but the value is never returned.

• Edge only for DOM - focus_browser can focus Chrome and Firefox, but the DOM tools work on the Edge instance only.

And there's one detail I found brilliant: there's a cursor failsafe, so if the pointer gets within five pixels of any screen corner the mouse operations are cancelled. It's the classic "kill the automation by yanking the mouse to the corner", except baked into the product.

Reginaldo, so can I automate any little legacy system with this?

You can, and that's exactly what it's for, but I'd go easy. UI automation breaks when the screen changes, and now the thing doing the clicking is a model interpreting a screenshot and an accessibility tree. Wherever an API or a connector exists, use the API. Save computer use for what genuinely has no other path, and build the flow checking the result at each step, which is why that final take_screenshot is sitting there in the example.

RECAP

• Windows 365 for Agents is an MCP server that gives the agent a whole Cloud PC, GA since June.

• It runs on the standard harness, so it doesn't fall into the Copilot Credits model.

• Explicit session with StartSession and EndSession, plus a heartbeat every 30 minutes on long processes.

• Desktop, browser through Edge and UI inspection, with find_ui_element avoiding fixed coordinate clicking.

• Allow list on the shell, Python sandbox, redacted cookies and a cursor failsafe.

• Use it when no API exists, and validate every step of the flow.

That wraps up this week's run of Copilot news. Comment below which system in your company you'd hand to this agent first, I bet everyone has a candidate in mind.

References:

Windows 365 for Agents MCP server

Windows 365 for Agents

Hope you liked it.

#windows365 #mcp #copilotstudio #computeruse #microsoft #ai #agents #datainaction