Copilot Memory em GA e o Dreaming reescrevendo a memória. Quem revisa o que o agente lembra?

Quando um agente de código aprende que o seu time roda os testes com um comando específico, ou que um revisor sempre rejeita determinado padrão, onde esse conhecimento fica e quem pode ler?

O GitHub respondeu parte dessa pergunta em 28 de outubro. O Copilot Memory agora está em disponibilidade geral (GA) nos planos pagos do Copilot, e um novo recurso chamado Dreaming, em preview público, revisa trabalhos anteriores para melhorar sessões futuras. Juntos, eles transformam a memória do agente em uma parte mantida do ambiente de desenvolvimento, e não em um efeito colateral de um chat longo.

O que cada peça faz

Copilot Memory guarda preferências pessoais e convenções de repositório, como comandos de teste ou como o Copilot deve verificar o próprio trabalho. O GitHub diz que o Copilot “gera e faz a curadoria de memórias de forma autônoma” a partir das interações, em dois escopos: pessoal e de repositório. Os usuários podem ver e excluir suas preferências pessoais; o acesso às memórias de repositório segue as configurações de acesso a repositórios do Copilot Memory.

Dreaming funciona de três maneiras. Faz a curadoria das memórias pessoais a partir das conversas com o agente. Gerencia as memórias de repositório e propõe atualizações em skills e arquivos de instrução customizados. E transforma feedback recorrente de code review que os desenvolvedores aceitaram em orientação para revisões futuras. É opt-in: as organizações habilitam por política, os usuários habilitam para si mesmos, e as execuções consomem créditos de IA.

O GitHub relata que, nas sessões de preview do Copilot CLI em que o agente usou a memória, 93% mostraram melhor adesão às preferências dos desenvolvedores e 42% mostraram workflows mais eficientes. São observações do próprio preview do GitHub, sem método publicado; leia como um sinal de que a memória muda o comportamento, o que é exatamente o motivo de ela precisar de atenção.

Dois tipos de memória, dois níveis de revisão

A escolha de design mais importante do lançamento passa fácil despercebida. O Dreaming propõe mudanças em skills e arquivos de instrução versionados no repositório por meio de pull requests, então o time revisa como qualquer outra mudança. Já as mudanças nas memórias em si, pessoais e de repositório, são feitas diretamente pelo Copilot.

Essa divisão é razoável e deixa uma lacuna. As memórias de repositório moldam como o agente trabalha para todo mundo que tem acesso, e são escritas pelo agente a partir do que ele observou. Se uma convenção errada for memorizada (um comando desatualizado, um workaround que alguém usou uma vez, um padrão que um único revisor preferia), ela se aplica em silêncio às sessões seguintes até alguém notar.

Defendemos que a memória de agente é armazenamento de dados corporativo, mesmo quando ninguém a chama de banco de dados, e que o problema difícil é o que os agentes deveriam esquecer. O lançamento do GitHub torna essas perguntas concretas para todo repositório com Copilot.

O que definir antes de habilitar o Dreaming

1. Leia as memórias de repositório periodicamente. Atribua ao owner do repositório a revisão do que o Copilot memorizou no escopo do repositório, do mesmo jeito que alguém revisa um arquivo CODEOWNERS. Apague o que estiver errado ou desatualizado.
2. Mantenha regras duráveis em arquivos, não na memória. Uma convenção que importa (como rodar os testes, quais bibliotecas são proibidas, o que um release exige) pertence a um arquivo de instrução ou skill versionado, onde as mudanças passam por revisão. A memória deve guardar o que é útil, mas barato de perder.
3. Verifique o que a memória pode conter. Garanta que as memórias não capturem segredos, dados de clientes ou URLs internas que não deveriam persistir; pergunte ao GitHub como as memórias são isoladas entre forks e repositórios privados na sua organização.
4. Revise os pull requests do Dreaming como mudanças de política. Uma proposta que transforma comentários de review aceitos em orientação permanente é uma regra de time sendo escrita por observação. Pergunte se os comentários dos quais ela aprendeu refletem o time ou um único revisor prolífico.

A mudança de fundo é que contexto não é mais algo que você escreve uma vez e recupera. Ele é mantido continuamente, em parte pelo agente. As partes que passam por revisão continuam confiáveis. As que não passam vão precisar de um dono que as leia.