Memória Automática Ou Instrução Escrita? O Que O Grok Build Ensina Sobre AGENTS.md

Quase todo time que adotou um agente de código passou pela mesma cena. Alguém explica, pela terceira vez na semana, que os testes do projeto não rodam com o comando óbvio, que existe um script que sobe o banco antes, que aquele diretório não se mexe. O agente entende, a sessão termina, e na manhã seguinte a conversa recomeça do zero. Isso não é um relato meu sobre uma ferramenta específica; é uma frustração tão comum que sustenta o argumento de venda de uma categoria inteira de recursos.

Foi com essa frustração em mente que li o que a xAI anunciou para o Grok Build em 16 de setembro de 2026: memória entre sessões, aprendida pelo próprio agente, sem que ninguém precise escrever nada. Do outro lado dessa ideia está uma prática que a maioria dos times já conhece, o arquivo AGENTS.md na raiz do repositório, escrito por gente, revisado em pull request e versionado junto do código. São duas respostas diferentes para a mesma pergunta, e cada uma tem um custo que a outra não paga.

Antes de seguir, a transparência de sempre. Não usei o Grok Build. O que sei vem da cobertura da Unite.AI, que se baseia no anúncio da xAI e foi atualizada em 19 de setembro, e do que a página do produto diz. Isso significa que descrevo o que foi anunciado, não o que acontece no dia a dia, e que há perguntas importantes que a matéria não responde. Vou apontar cada uma delas ao longo do texto. Quando eu opinar, é opinião; quando eu imaginar um cenário, vou rotular como hipotético.

O caminho é este: primeiro, o que a xAI descreve que a memória faz. Depois, o exemplo do cargo test corrigido para just test, porque ele mostra tanto o ganho quanto o risco. Em seguida, o que a instrução escrita garante e a nota aprendida não garante, o lugar onde a memória automática realmente leva vantagem, e por fim uma prática híbrida que ofereço como hipótese, não como receita testada.

O Que A xAI Descreve Que A Memória Do Grok Build Faz

O mecanismo, como a Unite.AI o resume, é uma revisão em segundo plano. Depois que cada turno termina, o agente olha para o que acabou de acontecer na conversa e decide se existe algo durável o bastante para guardar. Se existe, grava uma nota em um arquivo markdown, sem interromper a sessão. Cada assunto fica em um arquivo próprio, o que dá nomes como testing.md, code-style.md ou gateway.md. É uma organização por tópico, não um diário cronológico.

Há dois escopos. O escopo de projeto guarda o que vale para aquele repositório. O escopo global guarda o que vale em qualquer lugar, como preferências pessoais, e os exemplos citados são arquivos como MEMORY.md e preferences.md. A recuperação é automática: antes de um trabalho relacionado, o agente lê os tópicos relevantes, mesmo numa sessão em que o assunto nunca foi mencionado. Ninguém precisa dizer "lembre do que combinamos sobre testes".

O que entra e o que fica de fora é o ponto mais interessante do desenho. Entram convenções, decisões acompanhadas do raciocínio que levou a elas e fatos sobre o projeto. Ficam de fora o estado de uma tarefa em andamento, conclusões provisórias, segredos e qualquer coisa que o repositório ou sua documentação já cubram. A última exclusão é inteligente: se está no README, não precisa estar numa nota. Mas ela também deixa uma pergunta no ar, porque decidir o que "já está coberto" exige que o agente compare a nota com a documentação, e a matéria não diz como isso é feito.

Existem comandos para mexer na memória. O /dream consolida as observações novas dentro dos tópicos existentes e também roda periodicamente por conta própria. O /memory, com o atalho /mem, abre um navegador dos arquivos de memória, agrupados por escopo. O /remember grava uma nota direta, e o /flush força a gravação da conversa atual no disco. Quando a conversa e a nota discordam, a regra é clara: a instrução da conversa atual prevalece sobre a nota. Isso é uma boa decisão de projeto, porque impede que uma nota antiga contradiga o que o usuário acabou de pedir.

Por fim, o que a matéria diz sobre disponibilidade: a página do produto afirma que o Grok Build roda no Grok 4.6 e que é gratuito para testar, e a memória vale apenas para novas sessões. Vi menções a um Grok 4.7 em um blog de terceiros, com janela de contexto e preços que não consegui confirmar em fonte primária, então deixo isso de lado. Se você acompanha a trajetória da xAI, escrevi antes sobre o Grok 4.20 e a posição da xAI na corrida e sobre o Grok 4.5 dentro do Microsoft 365, mas aqui o foco não é o modelo, é a decisão de produto em torno da memória.

O Exemplo Do cargo test E Do just test

A xAI ilustra o recurso com um projeto fictício chamado orbit, e vale ler o exemplo devagar. Numa sessão, o agente roda cargo test e cinco testes de integração falham com um erro de conexão com o Postgres, enquanto 143 passam. O usuário corrige: a suíte deve rodar por just test, que sobe o banco de testes antes. Com o comando certo, passam 148. O agente grava um tópico testing.md registrando a convenção.

Numa sessão posterior, o agente precisa adicionar retry com backoff em src/webhooks.rs. Ele recupera a nota, roda os testes pelo comando correto e verifica a mudança com 151 testes passando. Nada disso exigiu que alguém repetisse a explicação. É exatamente o tipo de ganho que o recurso promete, e é um bom exemplo porque é pequeno, concreto e verificável: o comando certo ou funciona ou não funciona.

Dito isso, é um exemplo de anúncio. A matéria o apresenta como demonstração, e não há indicação de que represente o resultado típico. Não sei com que frequência o agente grava a coisa certa, nem com que frequência grava algo errado ou irrelevante. A pergunta de fundo é a taxa de erro do julgamento sobre o que é "durável", e ela não foi documentada no que li. Um recurso que funciona nove vezes em dez pode ser ótimo ou irritante, dependendo do que acontece na décima.

Pense agora num cenário hipotético, só para tornar o risco concreto. Imagine que, durante uma sessão de depuração, o desenvolvedor diz algo como "rode só o módulo de pagamentos, o resto está quebrado por causa da migração". Isso é verdade naquela semana. Se o agente classificar a frase como convenção do projeto em vez de estado temporário, a nota passa a empurrar todas as sessões futuras para ignorar o resto da suíte, muito depois de a migração terminar. A exclusão de "estado de tarefa e conclusões provisórias" existe justamente para evitar isso, mas a fronteira entre estado temporário e convenção é uma questão de julgamento, e julgamento erra.

Perceba também que o exemplo do just test é o tipo de informação que, num repositório bem cuidado, já deveria estar escrita em algum lugar. Um README com a seção de testes, ou um AGENTS.md com uma linha dizendo "use just test", resolveria o mesmo problema para todos os agentes e para todas as pessoas, desde o primeiro dia. A memória automática ataca o sintoma, que é o conhecimento que ninguém escreveu. A pergunta que o exemplo deixa é se queremos que o agente aprenda aquilo ou que a gente escreva aquilo.

Essa pergunta me parece mais útil do que a pergunta "memória automática é boa ou ruim", e é por ela que passo agora para a outra filosofia.

O Que A Instrução Escrita Garante E A Nota Aprendida Não Garante

Um AGENTS.md é um arquivo comum no repositório. Já tratei do formato e da lógica por trás dele em um post sobre steering files e AGENTS.md, então não repito o tutorial. O que interessa aqui é o que esse arquivo tem por ser texto versionado, porque são propriedades que dependem da forma, não do conteúdo.

A primeira é a revisão. Uma mudança no AGENTS.md entra por pull request, alguém lê, alguém questiona, e o histórico guarda quem mudou o quê e por quê. Se a instrução "nunca altere a pasta de migrações" aparece lá, ela passou por pelo menos um par de olhos humanos. Uma nota gravada por um agente em segundo plano, num arquivo de memória fora do fluxo de revisão, não passa por esse filtro. Pelo que li, os arquivos de memória do Grok Build ficam em escopos de projeto e global, mas a matéria não diz onde estão no disco, nem se fazem parte do repositório. Se não fazem, não aparecem num diff.

A segunda é a reprodutibilidade entre pessoas. Num time de oito, o AGENTS.md do repositório é o mesmo para os oito. Se a memória é aprendida por usuário, cada pessoa pode acabar com um conjunto diferente de notas, moldado pelas conversas que teve. Hipoteticamente, a pessoa que explicou a convenção de testes ao agente terá a nota, e a colega que nunca tocou no assunto não. O mesmo prompt, o mesmo repositório e o mesmo modelo podem então produzir comportamentos diferentes em duas máquinas, e depurar essa diferença é desagradável. Não sei se o Grok Build permite compartilhar ou sincronizar memória de projeto entre membros, porque a matéria não trata disso.

A terceira é a auditabilidade, e ela vale em dois sentidos. Quando o agente faz algo estranho, quero poder perguntar de onde veio a instrução. Com um arquivo versionado, a resposta é um git blame. Com memória aprendida, a resposta depende de eu conseguir abrir a nota, entender quando ela foi criada e em qual conversa. O /memory abre um navegador dos arquivos, o que ajuda, e a matéria o descreve como somente leitura para a navegação, embora também mencione controles para gerenciar memórias. Não ficou claro para mim como apagar ou corrigir uma nota, nem como desativar a memória por completo, e esses são dois requisitos básicos de qualquer sistema que grava coisas sobre mim sem eu pedir.

A quarta é o segredo. A exclusão de segredos é declarada, e é a coisa certa a declarar. Só que a declaração é uma intenção, não uma garantia técnica, e a matéria não diz que mecanismo a sustenta. Um arquivo escrito por humanos também pode vazar uma chave, claro, mas existe revisão, existem scanners de segredo no pipeline e existe a cultura de nunca commitar credencial. Uma gravação automática, feita no meio de uma conversa em que alguém colou um token para depurar, depende inteiramente do filtro do agente. Também não encontrei nada sobre privacidade, retenção ou onde os dados ficam armazenados, e prefiro dizer isso explicitamente a supor que está tudo resolvido.

Existe, por fim, o custo de ser explícito, e ele é real. Escrever e manter um AGENTS.md dá trabalho, e muita gente simplesmente não faz. Um arquivo que ninguém atualiza também deriva, e uma instrução obsoleta e confiante pode ser pior do que nenhuma. Não estou dizendo que o texto versionado vence; estou dizendo que ele compra auditabilidade e consistência ao preço de disciplina humana.

Onde A Memória Automática Leva Vantagem

Seria injusto parar na lista de riscos, porque a memória aprendida resolve um problema que o texto escrito não resolve: o conhecimento tácito. Boa parte do que um time sabe sobre o próprio código nunca foi escrita, e não por preguiça. Ninguém lembra de documentar que aquele serviço precisa de uma variável específica para subir localmente, até o dia em que alguém novo tropeça nisso. Um agente que observa a correção no momento em que ela acontece captura a informação no instante em que ela é mais clara, e isso custa zero esforço de quem corrigiu.

O segundo ganho é o custo marginal. Manter um AGENTS.md exige que alguém pare o que está fazendo para escrever. A memória automática troca esse esforço por uma gravação em segundo plano, e para desenvolvedores solo, ou para preferências pessoais que não interessam ao time, é uma troca razoável. Dizer ao agente "gosto de commits curtos" não precisa de pull request. É nesse espaço, preferências individuais, que o escopo global do Grok Build me parece mais sensato do que qualquer arquivo no repositório.

O terceiro é a granularidade. Um AGENTS.md tende a crescer até virar uma parede de texto. Notas por tópico, recuperadas só quando relevantes, são uma forma de carregar mais conhecimento sem pagar o custo de colocar tudo em toda sessão. Sobre os princípios gerais por trás dessa recuperação seletiva, escrevi em um post sobre memória de agentes em produção, e aqui só quero destacar a consequência prática: o que não precisa estar sempre no prompt não deveria estar.

Há ainda a deriva, que corta nos dois sentidos. Instruções escritas envelhecem porque ninguém as revisita; notas aprendidas envelhecem porque o agente as grava e esquece de revisar. A diferença é que o /dream, ao consolidar observações periodicamente, é uma tentativa explícita de combater a deriva de dentro do sistema. Não sei quão bem funciona, e a matéria não informa o intervalo das execuções em segundo plano nem como conflitos entre notas antigas e novas são resolvidos. Mas a existência do mecanismo mostra que a xAI trata o problema como real, e isso já é mais do que muitos arquivos de instrução fazem.

Por último, o risco de confiar demais. Uma nota gravada pelo agente tem a aparência de fato, e quem a lê depois tende a tratá-la como tal. Se ela estiver errada, o erro é silencioso e persistente, porque é recuperado automaticamente em sessões que nem têm a ver com o assunto. A regra de que a instrução da conversa atual prevalece ajuda no caso em que o usuário percebe e corrige, mas não ajuda no caso em que ninguém percebe. É o mesmo padrão que apareceu quando examinei memória compartilhada entre agentes, com o Memmy e o Mem0: quanto mais fácil é gravar, mais importante é ter um jeito de inspecionar e podar.

Uma Prática Híbrida Como Hipótese

O que segue é uma hipótese minha, não algo que eu tenha testado nem algo que a xAI recomende. A ideia é tratar as duas filosofias como camadas com funções diferentes, em vez de escolher uma. A memória automática funciona como rascunho: captura rápido, sem atrito, o que o agente e a equipe aprendem no dia a dia. O AGENTS.md funciona como a versão revisada, o que o time decidiu que vale para todos.

Num cenário hipotético, imagine um time de seis pessoas que usa um agente com memória automática. Uma vez por sprint, alguém abre o navegador de memórias, lê as notas de projeto e separa três grupos. O primeiro são notas corretas e úteis para todos, como o just test, que viram uma linha no AGENTS.md por pull request. O segundo são notas pessoais ou temporárias, que ficam onde estão ou são apagadas. O terceiro são notas erradas, que revelam um mal-entendido do agente e merecem correção. A revisão leva talvez quinze minutos, e o que sai dela é um arquivo versionado que conserva a auditabilidade, com um fluxo de descoberta que não depende de alguém lembrar de escrever.

Essa prática pressupõe coisas que eu não sei se o Grok Build oferece. Preciso conseguir ler as notas com facilidade, e o /memory parece cumprir isso. Preciso conseguir corrigir ou apagar uma nota, e a matéria não deixa claro como. Preciso saber onde as notas ficam e se posso excluí-las de qualquer sincronização, e isso também não está documentado no que li. E preciso confiar que segredos não entram, o que continua sendo uma promessa, não uma verificação. Se algum desses pontos falhar, a hipótese enfraquece.

Há um benefício colateral que me parece subestimado. Promover uma nota a instrução obriga alguém a formular a regra em linguagem clara, e muitas vezes essa formulação revela que a regra estava mal definida. "Rode os testes pelo just test" é fácil. "Siga o estilo do módulo de pagamentos" é uma convenção que, ao ser escrita, quase sempre exige uma conversa sobre o que exatamente se quer dizer. O texto versionado funciona como filtro de qualidade sobre o que o agente aprendeu, e esse filtro tem valor mesmo quando a nota original estava certa.

Existe também a alternativa oposta, que é uma hipótese igualmente honesta: para times pequenos ou projetos de vida curta, o custo da revisão pode superar o benefício, e deixar a memória trabalhar sozinha pode ser a escolha racional. Não tenho dado para dizer onde fica a linha. Minha suspeita é que ela depende de quantas pessoas dependem do mesmo comportamento do agente e de quanto custa um erro silencioso naquele código.

Conclusão

O que me parece mais útil na novidade do Grok Build não é a tecnologia de memória em si, e sim a pergunta que ela força. Contexto de projeto é algo que o agente aprende ou algo que a equipe decide? A resposta honesta é que depende do tipo de conhecimento: preferências pessoais e fatos tácitos favorecem a gravação automática, enquanto regras que o time precisa seguir de forma consistente favorecem o texto revisado. As duas filosofias não se excluem, mas cada uma cobra um preço, e é bom saber qual deles você está pagando.

Também preciso repetir os limites do que li. Descrevo um anúncio, cobertura de imprensa e a página do produto, e não uso real. Não encontrei documentação sobre como desativar a memória, como apagar notas, onde elas ficam armazenadas, por quanto tempo, se saem da máquina, nem sobre qualquer integração com o AGENTS.md. Essas lacunas não significam que os recursos não existam; significam que, no material que li, não estão descritos. Antes de adotar num time, eu leria a documentação oficial da xAI inteira e testaria esses pontos de propósito.

No fim, minha posição é cautelosa, mas aberta. Gosto da ideia de capturar conhecimento no momento da correção, e desconfio de qualquer sistema que grava coisas sobre o meu trabalho sem uma forma óbvia de revisar e apagar. Se o Grok Build resolver bem essa parte, a prática de usar a memória como rascunho e o AGENTS.md como versão final pode ser um bom meio-termo. Se não resolver, o arquivo no repositório continua sendo a opção que eu consigo auditar, e isso, para mim, ainda pesa mais do que a conveniência.

Fontes:

Memória Automática Ou Instrução Escrita? O Que O Grok Build Ensina Sobre AGENTS.md

Memória Automática Ou Instrução Escrita? O Que O Grok Build Ensina Sobre AGENTS.md

O Que A xAI Descreve Que A Memória Do Grok Build Faz

O Exemplo Do cargo test E Do just test

O Que A Instrução Escrita Garante E A Nota Aprendida Não Garante

Onde A Memória Automática Leva Vantagem

Uma Prática Híbrida Como Hipótese

Conclusão

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

eltonjose