VS Code Agents App (Insiders): o cockpit que faltava para quem quer um exército de agentes do Copilot

VS Code Agents App (Insiders): o cockpit que faltava para quem quer um exército de agentes do Copilot

22 de maio de 2026

Olá pessoALL,

Toda semana sai uma novidade de IA pra desenvolvedor. A maioria é repaginação: trocaram o nome, mexeram no menu, chamaram de "transformador". Eu já passei do ponto de me empolgar com isso. Mas semana passada abri o VS Code Insiders, vi o tal VS Code Agents Application que entrou em preview e parei o que eu tava fazendo. Instalei, brinquei por algumas horas, e quero te contar por que eu acho que esse aqui é diferente.

Spoiler: não é mais um chat panel travestido. É o que faltava pra quem realmente quer rodar um exército de agentes em paralelo na própria máquina, sem perder a cabeça.

Se você acompanhou os posts anteriores da série de Copilot (o do Coding Agent e o do CLI ACP Server), esse post fecha a trinca. Vou te contar por quê.

A trinca que estava se formando (e a peça que faltava)

Quem leu os posts anteriores tem mais ou menos esse mapa mental.

O Copilot Coding Agent é o cérebro autônomo que vive dentro do GitHub.com. Você atribui uma issue para o @copilot, ele roda em container do GitHub Actions, escreve código, abre PR. Excelente quando o trabalho começa e termina como uma issue.

O Copilot CLI ACP Server é o protocolo aberto que padroniza a conversa entre qualquer ferramenta sua e o Copilot. Excelente quando o trabalho começa em outro lugar (pipeline, CLI corporativo, bot, dashboard).

Mas ficava uma lacuna no meio. E se eu, desenvolvedor, quero disparar e monitorar várias sessões de agente em paralelo, no meu desktop, em projetos diferentes, sem virar um maluco com 8 janelas de VS Code abertas tentando lembrar qual agente tá fazendo o quê em qual repo?

Essa lacuna é o que o VS Code Agents App preenche. É o cockpit local onde você vê todas as sessões de agente vivas em um painel, troca de contexto sem trocar de janela e revisa o que cada um produziu antes de dar merge.

Code-first vs agent-first: uma mudança de mentalidade, não de UI

Vou ser honesto: minha primeira reação ao ler "novo app instalado junto com o VS Code Insiders" foi torcer o nariz. Mais um? Sério mesmo?

Aí eu li como a Microsoft posiciona o app e a ficha caiu. A documentação separa em dois modos de trabalhar com IA dentro do VS Code:

  • Code-first: você escreve código no editor e usa IA como assistente (autocomplete, refactor, sugestão inline). A interface principal é o editor. A IA é coadjuvante.
  • Agent-first: você delega tarefas de mais alto nível pro agente. Ele planeja, implementa e valida. A interface principal é o chat e a lista de sessões. O editor vira coadjuvante, usado pra revisar o que o agente fez.

O VS Code "normal" continua otimizado pra code-first. O Agents App é o complemento otimizado pra agent-first. Não é "VS Code 2". É o reconhecimento de que essas duas formas de trabalhar precisam de UIs diferentes, porque o foco do seu olho e o fluxo da sua atenção são diferentes em cada uma.

Quando entendi isso, parou de me incomodar que fosse um app separado. Aliás, faz sentido ser separado.

Como abrir (e o que esperar nos primeiros 30 segundos)

Pré-requisitos honestos: precisa do VS Code Insiders instalado e de uma assinatura ativa do GitHub Copilot. Não é download separado, o app vem junto com o Insiders.

Tem quatro formas de abrir:

  1. Pelo menu Iniciar (Windows) ou pasta Aplicativos (macOS), procurando por Visual Studio Code Agents - Insiders.
  2. Dentro do VS Code, clicando no ícone Agents na title bar.
  3. Pelo Command Palette (⇧⌘P no Mac, Ctrl+Shift+P no Windows), executando Chat: Open Agents Application.
  4. Pelo terminal, rodando code-insiders --agents.

No Linux o atalho de OS ainda não existe na versão preview, mas as outras três formas funcionam.

Na primeira abertura ele pede sign-in com sua conta GitHub. Se você já tava logado no VS Code, ele herda. Depois cai numa tela meio austera pedindo "Start by picking a workspace". E aqui já aparece o primeiro detalhe interessante: ele te pede pra escolher um workspace antes de qualquer prompt. Isso porque cada sessão de agente roda no contexto de um workspace específico, e o app deixa essa escolha explícita desde o começo.

Antes de qualquer coisa rodar, ele também pede pra você trust a pasta. Aviso direto: o agente vai poder ler arquivos, executar comandos e modificar conteúdo nesse diretório. Não é um chatbot inofensivo. É uma sessão de agente com permissões locais reais. Esse trust é compartilhado com o VS Code, então se você já confia naquela pasta no editor, ele já confia aqui também.

Anatomia da janela: 4 áreas que você vai usar o tempo todo

A janela do Agents App tem quatro regiões. Vou mapear porque cada uma resolve um problema específico de quem trabalha com agente.

Na sidebar esquerda fica a sessions list com todas as suas sessões de agente, em todos os workspaces, agrupadas por workspace. Click direito te dá renomear, marcar como concluída, fixar e deletar. Esse painel sozinho já justifica o app pra quem trabalha em mais de um repo.

Logo abaixo dela vem o customizations panel, que dá acesso direto às customizações que moldam o comportamento dos agentes naquele workspace ou no seu user profile. Vou voltar nesse painel mais pra frente porque ele é mais importante do que parece.

No centro fica a chat area com o histórico da conversa da sessão selecionada. É onde você prompta o agente e vê as respostas chegando em streaming.

À direita aparece o changes panel, com aba Files (explorer normal do workspace) e aba Changes (o que o agente adicionou, modificou ou deletou na sessão). Click em um arquivo abre o diff view. Você pode comentar inline no diff e o agente entende como sinal pra ajustar.

Na primeira vez que vi isso pensei: "ok, é o VS Code com os painéis reorganizados". E é, em parte. Só que o foco agora é a sessão, não o arquivo. Você navega entre sessões da mesma forma que navegaria entre tabs de arquivo no editor. Isso muda como você pensa no trabalho.

Iniciando uma sessão: três decisões que importam

Click em New (ou ⌘N). O wizard te força a tomar três decisões antes de mandar o primeiro prompt. Cada uma tem consequência prática.

Decisão 1: Que workspace? Pode ser uma pasta local ou um repositório do GitHub. Essa escolha define o tipo de agente disponível:

  • Pasta local → você escolhe entre Copilot CLI e Claude agent. Em qualquer momento da sessão, dá pra clicar em Continue In e fazer handoff pro Copilot Cloud agent.
  • Repositório do GitHub → a sessão já roda direto como Copilot Cloud agent (que é o tal Coding Agent do post anterior, agora orquestrado a partir do desktop).

Decisão 2: Folder isolation ou worktree isolation? Aqui é onde o app brilha pra quem quer rodar coisa em paralelo.

  • Folder isolation: o agente trabalha direto no seu workspace. Mudanças aplicam imediatamente nos arquivos. Rápido, mas se você tiver duas sessões mexendo nos mesmos arquivos, vira festa. É o default em projetos não-Git.
  • Worktree isolation: o agente opera em uma pasta separada criada via git worktree. As mudanças ficam isoladas até você decidir mergear. É o que você quer quando vai disparar várias sessões em paralelo no mesmo repo, cada uma cuidando de uma coisa diferente, sem conflito.

Decisão 3: Branch base, custom agent e modelo. Opcional. Você pode basear a sessão em um branch específico do source control, escolher um custom agent (aqueles .agent.md do post do Coding Agent funcionam aqui também) e trocar o language model. Tudo isso pode ser alterado depois durante a sessão.

Aí sim você manda o prompt. O agente quebra a tarefa em passos, escreve código, roda comandos, se autocorrige quando algo dá errado.

Onde o paralelismo deixa de ser teoria

Esse aqui foi o momento que me convenceu de verdade. Eu já tinha lido nos posts anteriores sobre paralelismo de agentes. Mas paralelismo orquestrado a partir de uma única janela de desktop é uma experiência diferente de paralelismo gerenciado a partir de 8 abas do navegador no GitHub.com.

Cenário concreto que testei: três workspaces abertos ao mesmo tempo, três sessões disparadas em paralelo. Em uma, o Copilot CLI atualizando dependências em worktree isolado. Em outra, o Copilot Cloud abrindo PR de uma issue em um repo do GitHub. Em uma terceira, o Claude agent escrevendo testes pra um módulo legado. Tudo aparecendo na mesma sidebar, com indicador de file change stats em cada uma. Eu trocava de uma pra outra clicando, sem trocar de janela, sem perder contexto.

E tem um recurso mais sutil que eu adorei: sub-sessions. Dentro de uma sessão ativa, você pode clicar em New Sub-Session (+) e abrir uma aba paralela no mesmo workspace e mesmo worktree, mas com chat em branco. Não herda histórico do parent. Serve pra quando, no meio de uma conversa longa, você quer pedir uma coisa lateral ("dá uma olhada rápida no log de build") sem poluir o contexto principal. Sub-session ainda não funciona com Claude agent, vale lembrar.

Deixou de ser "deixa eu abrir outra janela do VS Code" pra virar "deixa eu abrir outra aba aqui mesmo". Parece detalhe, mas pra quem dispara meia dúzia de sessão por dia muda o ritmo de trabalho.

Sessões remotas: SSH e dev tunnel para quando a máquina não é a sua

Esse aqui foi um item que quase passei batido na documentação e me mordi quando vi.

O Agents App suporta sessões em máquinas remotas via SSH ou dev tunnel. Isso usa um protocolo chamado AHP (Agent Host Protocol) que faz a ponte. Quando você conecta, o app automaticamente instala e inicia o Copilot CLI na máquina remota. Você não precisa preparar nada do lado de lá além de garantir SSH ou um dev tunnel ativo.

Os casos de uso ficam óbvios rápido:

  • Sua workstation não tem GPU/RAM suficiente pra rodar o build de um projeto pesado, mas você tem uma VM no Azure que tem. Conecta nela e o agente roda lá, com os recursos de lá.
  • Você precisa que o agente trabalhe em um ambiente com configuração específica (Linux com toolchain X, Windows com SDK Y) que não está no seu desktop.
  • Você sai do escritório e quer continuar acompanhando o progresso de uma sessão que ficou rodando na máquina lá.

Tem até versão browser do Agents App em insiders.vscode.dev/agents que conecta via dev tunnel. Pra quem trabalha de tablet ou de máquina emprestada eventualmente, é útil saber que existe.

Customizations carregam automaticamente — e isso era o que eu mais temia

Essa foi outra reação que eu tive antes de testar. "Ah não, agora vou ter que reconfigurar todos os meus copilot-instructions.md, MCP servers, custom agents nesse app novo."

Não. Carregam automaticamente.

O Customizations panel lista, em uma única tabela, tudo que tá ativo no workspace e no seu user profile:

Customização O que faz
Agents Custom agent personas (.agent.md) com tools e instruções específicas
Skills Pastas portáteis de instruções que o agente carrega quando relevante
Instructions Diretrizes que moldam como a IA gera código (copilot-instructions.md)
Hooks Comandos shell executados em pontos de ciclo de vida da sessão
MCP Servers Conexão da IA a ferramentas e serviços externos via padrão MCP
Plugins Bundles pré-empacotados de customizações

Você pode visualizar, editar, ativar ou desativar cada um sem remover. Pode adicionar novos pelo editor embutido ou gerar a partir de um prompt. Pode instalar plugins ou MCP servers do marketplace. E o dropdown no topo do painel deixa você escolher pra qual agente aquela customização se aplica.

Na prática, isso quer dizer que se você já investiu tempo escrevendo um copilot-instructions.md decente pro seu repo (e eu falei no post do Coding Agent por que isso paga dividendos), esse trabalho não se perde. O Agents App lê o mesmo arquivo. Os custom agents que você criou funcionam aqui também. Os MCP servers que você configurou conectam aqui também.

Isso é diferença gigante de adoção. Você não tá começando do zero. Você tá ganhando uma nova forma de consumir o que já configurou.

Validar antes de commitar: tasks, browser e terminal de sessão

Sessão rodou, agente entregou as mudanças, abriu diff. E agora? Como você sabe que aquilo de fato funciona antes de commitar?

O Agents App resolve isso com três ferramentas integradas no contexto da sessão.

Tasks. No dropdown da title bar, você adiciona tasks que executam comandos no contexto daquela sessão (e do worktree dela, se for o caso). Coisas como npm run build, pytest, dotnet test. Você pode salvar a task no workspace ou no seu user profile pra reaproveitar. Tem até opção de rodar automaticamente quando o worktree é criado.

Integrated browser. Se sua aplicação tem comportamento de browser, você clica em qualquer link localhost que apareça no chat ou no terminal e ele abre no browser embutido do app. A aba persiste quando você troca de sessão, então o estado não se perde. Pra fazer QA visual de mudança de UI durante uma sessão isso poupa um monte de alt-tab.

Terminal de sessão. Click no ícone Open Terminal e abre um terminal integrado já com o working directory apontando pra pasta ou worktree da sessão. Você não precisa lembrar onde o agente tá trabalhando.

E quando você revisou e tá satisfeito, o painel Changes te dá três botões dependendo do tipo de isolation:

  • Commit: em folder isolation, comita as mudanças direto no workspace.
  • Merge: em worktree isolation, mergeia (com opção de sincronizar upstream) e abre PR.
  • Checkout: em sessões Copilot Cloud, faz checkout local do branch do PR pra você revisar ou pedir mais mudanças.

Não é diferente do que você já faz no terminal manualmente, mas com um clique e dentro do contexto da sessão. Pra quem dispara muito agente, esse atrito a menos importa.

O hands-on de outras pessoas confirma o que eu vi

Pra não ficar só na minha experiência, achei interessante a análise do David Ramel publicada na Visual Studio Magazine em abril. Ele rodou o app contra um workspace editorial real (não código) e a observação dele que mais bateu com a minha foi essa: o app descobre a estrutura existente do workspace (instructions, custom agents, skills, prompt files) e produz um inventário legível disso, sem você precisar explicar nada.

Pra um workspace de desenvolvimento, isso significa que se o seu repo já tem instruções, roles, hooks e helpers configurados, a primeira sessão consegue te devolver um mapa de como aquilo tudo se encaixa. Ramel descreveu o app como "control surface for supervised agent work" (superfície de controle pra trabalho supervisionado de agente). É uma definição mais precisa do que eu vinha tentando formular sozinho.

Limitações honestas: estamos em preview

Pra não cair na armadilha do hype (e a documentação da própria Microsoft é honesta sobre isso), as limitações que vale você saber antes de adotar:

  • É preview. Só roda no VS Code Insiders. A própria Microsoft pede feedback via issue no GitHub. Não bota no caminho crítico de produção sem plano B.
  • Tipos de agente suportados hoje: Copilot CLI, Copilot Cloud e Claude agent. Pra usar agentes locais ou outros third-party, você continua gerenciando do VS Code principal.
  • Copilot Cloud sessions só pra repositórios do GitHub. Pra projetos não-GitHub, dá pra usar Copilot CLI normalmente.
  • Agents dropdown não tem o plan agent ainda. Workaround: usar /plan direto na sessão Copilot CLI ou Claude.
  • Sub-sessions ainda não funcionam com Claude agent.
  • Multi-root workspaces não são suportados. Workaround: pedir pro agente trabalhar entre projetos numa sessão única, mas é gambiarra.
  • Browser embutido não abre sozinho. Você precisa clicar no link localhost ou rodar o comando.

Nada disso é dealbreaker pra um piloto. Mas entrar de olhos abertos importa.

Como esse post fecha a trinca

Lá no começo eu falei que esse post fecha a trinca da série. Vou amarrar.

O Copilot Coding Agent vive dentro do GitHub.com, em container do GitHub Actions, e é onde o trabalho que começa e termina como issue se resolve sozinho (backlog, refactor, bugfix, atualização de dependência). O Copilot CLI ACP Server roda como subprocesso ou em TCP em qualquer máquina, e existe pra integrar a inteligência do Copilot dentro das suas ferramentas via um protocolo padrão aberto. O VS Code Agents App vive no seu desktop (Windows, macOS, Linux, ainda em preview no Insiders) e é o cockpit local pra disparar e monitorar várias sessões de agente em paralelo, em projetos diferentes.

As três peças não competem, se completam. O Coding Agent é o cérebro autônomo, o ACP Server é o protocolo aberto que conecta esse cérebro a qualquer ferramenta sua, e o Agents App é a UX que torna a operação disso tudo humanável quando você tem mais de duas coisas rolando ao mesmo tempo.

Lição aprendida ao longo dos três posts: a Microsoft não tá soltando agente solto. Tá montando um ecossistema onde a governança vem antes (sandbox, isolation, trust prompt, separation of duties) e a interface vem depois. É nessa ordem que dá pra adotar com responsabilidade dentro de uma empresa.

Próximos passos

Se você é desenvolvedor ou tech lead e ainda não testou: instala o VS Code Insiders, abre o Agents App, escolhe um repositório que você confia, e dispara duas sessões em paralelo em worktrees isolados. Em uma hora você entende se faz sentido pro seu fluxo. Eu apostaria que faz pra mais gente do que pensa.

Se você lidera engenharia e quer entender como adotar essa stack toda (Coding Agent + ACP + Agents App) com governança enterprise no lugar (controle de acesso, MCP allowlists, audit logs, separation of duties), entra em contato com a gente da AzureBrasil.cloud. Como Microsoft Solutions Partner, ajudamos times a sair do "vimos uma demo legal" pra "tá rodando em produção com guardrails no lugar".

Referências

Documentação oficial

Análises e hands-on da comunidade

Posts relacionados (a trinca completa)

[]s e até a próxima!

Confira mais:

Fique por dentro das novidades

Assine nossa newsletter e receba as últimas atualizações e artigos diretamente em seu email.

Assinar gratuitamente