GitHub Universe 2026: Copilot Agent Host, Sessões Em Nuvem E A Disputa Pela Camada Do Agente

Existe uma frustração pequena e muito específica que quem trabalha com agentes de código conhece bem: o fio da sessão que se perde. Você pede uma tarefa longa, sai para uma reunião, fecha o notebook, abre a outra máquina ou o celular e descobre que o contexto ficou preso no lugar onde a conversa começou. Quase sempre o que se perde não é o código, que está no repositório, e sim o raciocínio em andamento, a pergunta que o agente ia fazer, o plano pela metade. Isso não é um relato sobre uma ferramenta específica; é um incômodo recorrente na conversa de times que adotam esse tipo de ferramenta.

Foi com esse incômodo na cabeça que li o changelog que o GitHub publicou em 28 de outubro de 2026, com as novidades do Copilot no VS Code anunciadas no Universe. A lista é longa, mas quase tudo nela gira em torno de uma mesma ideia: separar a sessão do agente da janela do editor e da máquina onde ela nasceu. Sessões que rodam na infraestrutura do GitHub, um processo chamado Agent Host que mantém o trabalho vivo, um protocolo aberto para clientes de terceiros e controle pelo celular. Em termos de produto, é prático. Em termos de negócio, é uma jogada sobre quem fica com a camada mais valiosa da cadeia.

Antes de seguir, a transparência de sempre. Não usei nada do que descrevo aqui. Tudo o que sei vem do changelog oficial do GitHub, que é uma fonte do fornecedor, escrita para anunciar, e não de teste independente. Não há no texto números de adoção, preços ou comparações de desempenho, e eu não vou preencher essa lacuna. A parte descritiva do post vem do changelog; a parte estratégica, a partir da seção sobre leitura de plataforma, é interpretação minha e vai rotulada como opinião.

O post cobre o que foi anunciado, a sessão que sobrevive ao notebook, o protocolo aberto e o que "aberto" não garante, a comparação de modelos com um juiz, a governança para admins e, por fim, quem ganha e quem perde quando a sessão do agente mora no host de alguém.

O Que Foi Anunciado No Changelog De 28 De Outubro

O primeiro bloco é o das sessões de agente em nuvem. Elas são iniciadas pela janela Agents do VS Code e rodam na infraestrutura do GitHub, o que significa, segundo o changelog, que fechar o notebook não interrompe o trabalho. A mesma sessão pode ser retomada no VS Code, no app do GitHub Copilot, no GitHub Mobile, em github.com ou no Copilot CLI. O texto acrescenta que sessões iniciadas por mensagens diretas no Slack ou no Teams também continuam nesses mesmos clientes.

O segundo bloco é o Agent Host, que roda as sessões do Copilot separadas das janelas do VS Code. A consequência descrita é que o trabalho continua depois que você fecha o projeto. Com Remote SSH ou dev tunnels, também é possível rodar os agentes em outra máquina, desde que ela fique ligada. O changelog ainda menciona a alternância entre a visão Editor e a janela Agents, as duas sincronizadas com a mesma sessão viva, e o controle pelo celular: do GitHub Mobile dá para acompanhar, dar direção ou iniciar tarefas na máquina de desenvolvimento, com setup feito pelo comando code agent host --github-environment na pasta do projeto.

O terceiro bloco trata do harness. O harness do Copilot, construído sobre o Microsoft Copilot SDK, passa a ser o padrão para novas sessões no editor e na janela Agents. O Copilot CLI vem pelo instalador do VS Code no Windows, por uma opção de PATH no macOS, ou rodando copilot no Linux.

O quarto bloco reúne os recursos que mexem na relação entre modelos e ferramentas. Há a comparação de modelos, em preview, que permite rodar vários modelos e harnesses em paralelo na janela Agents e revisar os resultados lado a lado; um modelo chamado "Judge" pode recomendar uma solução e o "Synthesize" combina ideias das tentativas. Há o computer use, experimental, que se habilita com chat.agentHost.computerUse.enabled no macOS ou no Windows, seguido de reinício e do comando /computer on, com aprovação por aplicativo e possibilidade de desativação por política da organização.

O quinto bloco é o do ecossistema. O Agent Host Protocol, o AHP, é aberto: aplicativos próprios ficam sincronizados com as mesmas sessões vivas do VS Code, inclusive reconectando depois, e existem bibliotecas cliente para TypeScript, Rust, Go, Kotlin e Swift. Há um marketplace de customizações em preview, ligado por padrão, com uma página Customizations onde se navega por skills, servidores MCP, plugins e mais. E há os Copilot connectors, também em preview, que ligam Slack, Notion, Microsoft Learn e outros a sessões de agente sem exigir um servidor MCP; segundo o changelog, estão disponíveis em todos os planos do Copilot e funcionam com o harness do Copilot.

Sessão Que Sobrevive Ao Seu Notebook

A mudança de fundo, a meu ver, é conceitual. Até aqui, a maioria das ferramentas de agente tratava a sessão como um acessório da janela: o agente vive enquanto o editor está aberto, naquela máquina, naquele processo. O que o changelog descreve inverte a relação. A sessão passa a ser o objeto principal, e o editor, o app, o celular e o terminal são clientes que se conectam a ela. Se você pensa em termos de arquitetura, é a diferença entre um programa que roda dentro do seu terminal e um serviço ao qual você se conecta.

Esse desenho resolve problemas práticos reais. Tarefas longas deixam de depender de a máquina ficar acordada. Trocar de dispositivo deixa de significar recomeçar. E o fluxo de trabalho com Slack ou Teams, que o changelog menciona, sugere que a conversa que começa em um canal de chat pode virar sessão de código sem copiar e colar contexto. Um cenário hipotético: um tech lead pede pelo celular, no meio de um incidente, que um agente investigue um erro, e horas depois encontra a mesma sessão no notebook, com o histórico intacto.

Há duas formas de hospedar essa continuidade, e o changelog mostra as duas. Na nuvem, a sessão roda na infraestrutura do GitHub. No Agent Host, ela roda na sua própria máquina ou em outra que você controle, via Remote SSH ou dev tunnels, com a ressalva explícita de que a máquina precisa ficar ligada. A diferença importa. No primeiro caso, você terceiriza a execução e ganha disponibilidade. No segundo, você mantém a execução perto do seu ambiente, o que costuma ser relevante para acesso a rede interna, dados e dependências locais, ao custo de manter a máquina de pé.

Convém ser cuidadoso com o que o changelog não diz. Ele não informa limites de tempo de uma sessão em nuvem, como o ambiente é isolado, que dados da sua máquina ou do seu repositório trafegam para a infraestrutura do GitHub, nem como funciona o controle de custo. Também não traz números de adoção ou de confiabilidade. Em um texto de anúncio isso é normal, mas decisão séria exige documentação e teste próprio; eu olharia primeiro o isolamento e o que sai da máquina.

Dar direção a um agente pelo celular amplia a superfície de risco, e o changelog não detalha os controles de aprovação nesse caminho. A questão da fronteira entre autonomia e supervisão já apareceu na discussão sobre o retorno ao terminal e a disputa entre agentes de linha de comando e IDEs, e aqui o Copilot CLI e o editor aparecem como dois clientes da mesma sessão.

Protocolo Aberto: AHP Como Aposta, E O Que "Aberto" Não Garante

O anúncio mais interessante do ponto de vista estratégico é o Agent Host Protocol. Segundo o changelog, ele permite que aplicativos próprios fiquem sincronizados com as mesmas sessões vivas do VS Code, inclusive reconectando depois, e vem com bibliotecas cliente para cinco linguagens: TypeScript, Rust, Go, Kotlin e Swift. Leitura minha: Kotlin e Swift sugerem clientes móveis, Rust e Go ferramentas de linha de comando, e a lista parece pensada para quem quer construir cliente.

Para um time de plataforma, a promessa é atraente. Em vez de depender do VS Code como única interface, dá para imaginar um painel interno que mostra todas as sessões de agente do time, um bot que acompanha tarefas longas, ou um app móvel próprio que dê direção a uma sessão.

Mas "aberto" é uma palavra que merece perguntas, e o changelog não responde a todas. Aberto no sentido de especificação publicada e implementável por terceiros é uma coisa. Aberto no sentido de governança compartilhada, com mudanças decididas fora de uma única empresa, é outra. Aberto no sentido de que o outro lado da conexão também pode ser qualquer coisa, ou seja, que dá para plugar a sessão de outro fornecedor, é uma terceira. O texto que li afirma que o protocolo é aberto e lista as bibliotecas cliente; não diz quem governa a especificação, como ela evolui, nem se o lado do host pode ser implementado por quem não seja o GitHub ou a Microsoft.

Essa distinção importa porque protocolos abertos costumam seguir um caminho conhecido. A pergunta de quem se beneficia depende de quem controla o lado que concentra o valor. Se o AHP abre a porta para clientes de terceiros se conectarem às sessões do Copilot, o GitHub ganha ecossistema ao redor da sua camada de execução. Se a especificação também permitisse que outros hosts falassem o mesmo protocolo, o ganho seria do mercado inteiro. O changelog descreve a primeira possibilidade. A segunda é uma pergunta em aberto, e eu a trato como tal.

Existe um paralelo útil com o que aconteceu com os padrões de extensão de agentes. Em um post sobre skills, MCP e portabilidade de plugins, a discussão era justamente até onde um padrão compartilhado entrega portabilidade real e onde cada fornecedor mantém seu pedaço proprietário. O AHP se encaixa nessa conversa. Ele padroniza como um cliente conversa com uma sessão, o que é útil, mas não padroniza o que a sessão faz, que modelo usa, que ferramentas oferece ou como o harness decide. A sessão continua sendo do Copilot, mesmo que a porta de entrada seja aberta.

Minha leitura provisória, que é opinião e não fato: o AHP é uma boa aposta para o GitHub, porque barateia a construção de clientes e puxa desenvolvedores para dentro do seu modelo de sessão. Para quem adota, vale tratá-lo como uma camada de integração útil, e não como seguro contra dependência. Um protocolo aberto reduz o custo de construir em cima de um host, mas não reduz o custo de sair dele.

Comparar Modelos Com Um Juiz Que Também É Um Modelo

A comparação de modelos, em preview, é a parte do anúncio que mais conversa com a rotina de quem escolhe ferramenta. A ideia, como o changelog descreve, é rodar vários modelos e harnesses em paralelo na janela Agents e revisar os resultados lado a lado. Em vez de apostar em um modelo para uma tarefa, você dispara a mesma tarefa em alguns e compara.

Dois mecanismos complementam a comparação. O modelo "Judge" pode recomendar uma solução entre as tentativas, e o "Synthesize" combina ideias das tentativas. O changelog descreve esses papéis em poucas linhas e não detalha os critérios que o juiz usa, o que ele recebe como entrada ou como a síntese é feita. Por isso tudo o que digo a seguir é sobre a estrutura da ideia, não sobre o desempenho dela.

O ponto central é simples: um juiz é outro modelo. Isso traz as limitações conhecidas de qualquer avaliação feita por modelo. Ele pode preferir respostas mais longas, mais bem escritas ou parecidas com o seu próprio estilo, em vez das mais corretas. Pode errar de forma correlacionada com os modelos avaliados, sobretudo se vierem da mesma família. E uma recomendação confiante pode dar a sensação de decisão tomada quando, na verdade, ela é só uma opinião adicional. O changelog não afirma nada contrário a isso; apenas não se pronuncia.

O uso sensato, na minha leitura, é tratar o Judge como triagem e a revisão lado a lado como a decisão. Imagine um time que roda a mesma tarefa de migração em três modelos e usa o juiz para ordenar as propostas. Se a pessoa que revisa lê as três diffs antes de aceitar a recomendação, o juiz economizou tempo. Se aceita a recomendação sem ler, o time terceirizou o critério de qualidade para um componente cujo comportamento não conhece. A diferença entre as duas situações não está na ferramenta, está no processo.

Rodar vários modelos na mesma janela também coloca o GitHub como o lugar onde a competição entre modelos acontece. É uma dinâmica parecida com a que discuti ao comparar os agentes gerenciados da OpenAI, da Anthropic e do Google: quem controla a orquestração influencia quais modelos são escolhidos.

Marketplace E Governança Para Admins

O marketplace de customizações, em preview e ligado por padrão, aparece como uma página Customizations com navegação por skills, servidores MCP, plugins e mais. Para o desenvolvedor, é descoberta fácil. Para o administrador, a frase "ligado por padrão" acende uma luz amarela, e o changelog trata disso: admins dos planos Business e Enterprise precisam liberar as preview features do editor, o que funciona como um portão de entrada para a organização.

Os controles descritos para administradores são mais detalhados do que o resto. Dá para exigir ou bloquear plugins, adicionar marketplaces e restringir a instalação a fontes aprovadas. As configurações no repositório, em .github/copilot/settings.json, definem padrões mas não os impõem. Essa última frase é a mais importante para quem governa: um arquivo no repositório é uma recomendação para quem clona, não uma política. Quem precisa de imposição tem de usar os controles da organização, e não confiar no arquivo versionado.

A distinção é fácil de confundir, e confusão aqui custa caro. Um time que coloca no settings.json a lista de plugins aprovados pode ter a impressão de que a regra está valendo, quando um desenvolvedor pode simplesmente configurar outra coisa na própria máquina. O desenho do GitHub separa as duas camadas, o que é correto, mas exige que quem escreve a política saiba em qual delas está escrevendo. Se você já avaliou quando vale expor um servidor MCP e quando não vale, a discussão em um texto sobre quando não usar MCP por padrão ganha um peso a mais num marketplace que facilita a instalação.

Os Copilot connectors seguem a mesma lógica de conveniência. Conectar Slack, Notion ou Microsoft Learn a uma sessão sem passar por um servidor MCP reduz a fricção de configuração, e o changelog diz que estão disponíveis em todos os planos do Copilot. O que o texto não diz é como se controla o escopo de acesso de cada conector, que dados entram no contexto da sessão ou como isso é auditado. Facilitar a conexão é um benefício de produto e uma preocupação de governança ao mesmo tempo, e as duas coisas crescem juntas.

Para um tech lead, a lição prática é não deixar o padrão do produto decidir pela organização. Preview ligada por padrão significa que alguém precisa decidir, conscientemente, se aquilo entra ou não no ambiente de trabalho. O changelog dá as alavancas: liberar ou não as preview features, aprovar fontes de plugin, bloquear o que não é aprovado. Usá-las é trabalho que ninguém fará se ficar para depois.

Leitura Estratégica: Quem Controla A Sessão, Controla O Desenvolvedor

A partir daqui, é opinião minha, construída sobre o que o changelog descreve e não sobre dados de mercado, que eu não tenho. A tese é esta: a camada que mantém a sessão do agente viva é um ponto de controle comparável ao que o editor foi por anos. Quem hospeda a sessão guarda o histórico, o estado, o plano em andamento, e se torna o lugar para onde o desenvolvedor volta. Esse lugar vale mais do que o modelo, porque modelos são trocáveis, e o fluxo de trabalho ao redor deles, não.

O pacote do Universe, lido assim, é coerente. Sessões em nuvem e Agent Host puxam a continuidade para o GitHub. O protocolo aberto faz com que terceiros construam em cima dessa continuidade. A comparação de modelos coloca o GitHub como árbitro entre fornecedores. O marketplace e os connectors fazem da sessão o ponto onde skills, MCP e integrações se encontram. Cada peça, isolada, é um recurso; juntas, formam uma plataforma em torno de um objeto, a sessão, que o GitHub quer ser o dono natural.

Quem ganha? Pelo desenho, quem já vive dentro do GitHub e do VS Code ganha continuidade com pouco esforço, e times que querem construir clientes próprios ganham uma porta documentada. Quem pode perder são as ferramentas que dependem de ser a única interface do agente, porque o AHP e a sessão compartilhada reduzem a necessidade de trocar de ferramenta para trocar de dispositivo. Como isso se compara a Claude Code, Codex ou Cursor eu não sei dizer; o changelog não os menciona, e comparar sem testar seria especulação com cara de análise.

O risco para quem adota é de dependência, e ele tem uma forma específica. Se a sessão vive no host de outra empresa, o histórico, o contexto acumulado e os hábitos do time ficam acoplados àquele host. Um protocolo aberto ajuda a construir clientes, mas, como vimos, não garante que o conteúdo da sessão seja exportável ou que outro host consiga assumi-la. Não sei se o GitHub oferece exportação do estado de uma sessão, e o changelog não informa. É a primeira pergunta que eu faria antes de colocar trabalho longo e importante nesse modelo.

Um cenário hipotético para ilustrar: imagine uma empresa que, ao longo de um ano, passa a conduzir boa parte das tarefas de manutenção por sessões em nuvem de um fornecedor. Os planos, as decisões e as conversas ficam lá. Se um dia o time quiser migrar para outra ferramenta, a migração do código é trivial, porque o código está no repositório, mas a do contexto acumulado depende de o fornecedor permitir a saída. A lição não é evitar a nuvem; é decidir de antemão quais artefatos da sessão precisam existir também fora dela, como planos e decisões registrados no próprio repositório.

Conclusão

O que o GitHub anunciou em 28 de outubro é, ao mesmo tempo, um conjunto de melhorias reais e uma jogada de posicionamento. Sessões que sobrevivem ao notebook, controle pelo celular e a possibilidade de alternar entre editor e janela de agentes resolvem atritos genuínos. Ao mesmo tempo, mover a sessão para a infraestrutura do GitHub e padronizar o acesso a ela por um protocolo próprio é uma forma de ocupar a camada onde o desenvolvedor passa a morar. As duas leituras são verdadeiras, e nenhuma anula a outra.

Também preciso repetir os limites do que li. Esta é uma leitura de um changelog do próprio fornecedor, sem teste, sem números independentes e sem informação sobre preços, adoção, isolamento das sessões em nuvem, governança do protocolo ou exportação de estado. As partes estratégicas são interpretação minha. Se você é tech lead ou arquiteto e está escolhendo ferramenta, eu leria a documentação oficial de cada recurso, testaria o isolamento e o que sai da máquina, e trataria o AHP como uma integração útil, não como garantia de portabilidade.

No fim, minha posição é de interesse cauteloso. Gosto de uma sessão que não morre com a janela, e desconfio de qualquer arquitetura em que o histórico do meu trabalho fica refém de um único host sem uma saída clara. A pergunta que eu levaria para a próxima conversa do time não é qual agente escrever o melhor código hoje, e sim onde queremos que a memória do trabalho dos agentes more daqui a dois anos, e o que fazemos para que ela possa mudar de endereço.

Fontes:

GitHub Universe 2026: Copilot Agent Host, Sessões Em Nuvem E A Disputa Pela Camada Do Agente

GitHub Universe 2026: Copilot Agent Host, Sessões Em Nuvem E A Disputa Pela Camada Do Agente

O Que Foi Anunciado No Changelog De 28 De Outubro

Sessão Que Sobrevive Ao Seu Notebook

Protocolo Aberto: AHP Como Aposta, E O Que "Aberto" Não Garante

Comparar Modelos Com Um Juiz Que Também É Um Modelo

Marketplace E Governança Para Admins

Leitura Estratégica: Quem Controla A Sessão, Controla O Desenvolvedor

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose