Quando um agente começa a trabalhar de verdade, a conversa deixa de ser suficiente. O chat registra pedidos, respostas, logs e correções, mas o estado do trabalho fica espalhado pelo histórico. Depois de algumas etapas, alguém precisa reconstruir o que foi feito, o que deu errado e qual decisão ainda depende de uma pessoa.
É esse problema que o GitHub tenta atacar com os canvases do Copilot. A proposta é colocar o fluxo em uma superfície persistente, onde pessoas e agentes acompanham o mesmo trabalho, em vez de tratar cada mensagem como um recomeço. O recurso aparece em artigo publicado no GitHub Blog em 17 de agosto de 2026, assinado por Ayan Gupta, Developer Advocate da empresa.
O limite do chat aparece quando o trabalho se alonga
O chat continua sendo uma boa interface para dizer o que você quer. É rápido para explorar uma ideia, esclarecer uma dúvida e mudar de direção enquanto o problema ainda está mal definido. O problema começa quando o agente passa a executar uma sequência de tarefas.
Nesse ponto, o histórico vira uma fila comprida de instruções, saídas, decisões e tentativas. A informação não desaparece, mas fica difícil de consultar. Um integrante que entra no meio do processo pode precisar ler tudo para descobrir em que etapa o fluxo está. Mesmo quem iniciou o trabalho pode perder tempo procurando a validação mais recente ou a razão de uma mudança.
Um canvas muda a unidade de trabalho. Em vez de guardar apenas a conversa, ele mantém uma visão do processo: fases, dados preenchidos, pendências, decisões e pontos de aprovação. O agente atualiza essa superfície enquanto trabalha, e a pessoa consegue orientar o próximo passo sem reconstruir todo o contexto.
Dois exemplos: modernização de Java e conteúdo de site
Gupta descreve dois canvases criados com objetivos diferentes. O primeiro, Java Modernization Studio, organiza um fluxo de modernização de aplicações Java. O trabalho passa por avaliação, planejamento, migração, validação e preparação para o lançamento. Em um chat, essas fases podem se misturar. No canvas, cada uma fica visível e pode receber uma decisão própria.
Uma equipe pode enxergar que o código já foi analisado, mas ainda tem um bloqueio de compilação. Também pode separar uma tarefa que o agente executa sozinho de outra que precisa de aprovação humana. O ganho não está em produzir uma resposta mais bonita. Está em diminuir a dúvida sobre o estado atual do trabalho.
O segundo exemplo, Site Studio, cuida da criação e manutenção de conteúdo para um site. As seções ficam listadas, os rascunhos permanecem salvos e os momentos de revisão aparecem de forma explícita. Isso evita que uma alteração em uma seção apague a noção do que já foi revisado nas outras.
Para uma operação editorial, esse detalhe faz diferença. Um agente pode preencher uma seção, revisar outra e deixar uma terceira aguardando aprovação. O responsável olha o estado e decide onde intervir.
O padrão que se repete
Os dois exemplos apontam para a mesma estrutura. O fluxo precisa ter estados claros. As decisões que realmente mudam o resultado precisam ficar expostas. O sistema também deve salvar progresso e rascunhos enquanto o trabalho avança, além de marcar os pontos em que uma pessoa precisa aprovar, corrigir ou redirecionar o agente.
Isso é diferente de apenas criar uma tela com cartões. Um canvas útil precisa responder perguntas que aparecem durante a operação: em que fase estamos, qual informação falta, qual teste falhou, quem precisa decidir e o que acontece depois da aprovação.
Essa visibilidade também ajuda na revisão. Agentes conseguem produzir alterações mais rápido do que uma pessoa consegue ler tudo. Quando o processo deixa claro o que mudou e quais validações passaram, a revisão humana pode se concentrar nos pontos de maior risco.
Há um custo, e o GitHub admite isso
Canvases não aparecem de graça só porque a interface parece organizada. No relato, o Site Studio consumiu cerca de 2.000 créditos de IA e o canvas de modernização consumiu cerca de 3.000. Também existe o tempo de desenhar os estados, escolher os campos e testar o fluxo com trabalho real.
A conta pode fazer sentido quando o processo se repete. Se cada execução começa com a mesma explicação, perde contexto e exige retrabalho, uma superfície persistente pode economizar chamadas e tempo. Mas um fluxo que acontece uma vez por ano talvez não precise de uma arquitetura desse tamanho.
Minha leitura é que a ideia fica mais interessante quando aplicada a um processo que já dói. Triagem de pull requests, migração de código, revisão de conteúdo e preparação de lançamentos são exemplos em que o estado muda muitas vezes e várias pessoas precisam acompanhar. Para uma pergunta rápida, o chat continua sendo mais simples.
Como começar sem transformar tudo em projeto
O próprio GitHub sugere começar pequeno com o comando /create-canvas. A melhor escolha é um fluxo repetitivo o bastante para revelar os problemas. Liste as etapas atuais, marque onde uma pessoa precisa aprovar e defina o que o agente pode alterar sem esperar.
Depois, use o canvas em uma execução real. A equipe precisa observar se os estados ajudam ou apenas repetem informações do chat. Também precisa conferir se os bloqueios aparecem cedo, se os rascunhos continuam disponíveis e se a aprovação deixa um registro compreensível para quem chega depois.
Os canvases Java Modernization Studio e Site Studio estão disponíveis no repositório awesome-copilot, segundo o GitHub. Eles podem ser usados como referência ou adaptados para outros processos. O ponto mais útil do anúncio é a lembrança de que automação sem estado visível vira uma sequência de decisões difíceis de auditar.
Fonte
GitHub Blog: How canvases make agentic workflows visible, steerable, and cost-efficient
