A Anthropic apagou mais de 80% do próprio system prompt. Quando você apagou uma regra?

A Anthropic removeu mais de 80% do system prompt do Claude Code e reportou nenhuma perda mensurável nas avaliações internas. O dado é autorreportado, vindo do time que mais teria a perder se o número estivesse errado, e é justamente por isso que ele incomoda. Quatro em cada cinco instruções de uma configuração de agente em produção não sustentavam nada.

Agora conte as regras da sua própria configuração de agente. Depois conte quantas você apagou neste trimestre.

A maioria dos times tem a mesma resposta: zero. Configurações só crescem. Cada comportamento indesejado vira uma linha nova, e ninguém foi designado para tirar linha nenhuma. A mesma lógica governa as sessões. Reiniciar um agente que roda há horas parece desperdício, então a sessão continua, acumulando histórico que se parece com patrimônio.

Dois ensaios de praticantes publicados em agosto de 2026 mediram o que acontece de fato com os dois. Addy Osmani olhou para os arquivos. Tomasz Tunguz olhou para o tempo de vida. Chegam à mesma operação por extremos opostos.

Os arquivos se degradam

Osmani reporta um estudo de junho sobre 100 repositórios com três achados que descrevem a mesma falha. Vazamento de lint, em 62% dos repositórios: regras de formatação e linting ocupando o contexto do agente quando o próprio linter já as aplica. Inchaço de contexto, em 42%: arquivos grandes o suficiente para que as instruções concorram com a tarefa. Vazamento de skills, em 35%: skills carregadas sem que a tarefa as exija.

Um segundo estudo sobre arquivos de contexto rodou 288 execuções em 17 tarefas reais. Um usuário reduziu a contagem de skills de 250 para 25.

Nenhum desses números descreve um problema de escrita. Cada uma daquelas linhas estava correta quando alguém a adicionou. A regra de lint era real. A skill foi útil um dia. O que mudou foi o sistema em volta absorver aquela responsabilidade, e a instrução ficar para trás como sedimento.

Essa é a parte que resiste à revisão de código comum. Um teste obsoleto falha. Uma dependência obsoleta dispara alerta de auditoria. Uma instrução obsoleta na configuração de um agente não produz sinal visível algum. Ela consome tokens, disputa atenção e não gera erro que alguém possa apontar. Já escrevemos sobre a janela de contexto como orçamento e não como balde e sobre como escrever um CLAUDE.md que se paga. Os dois textos pressupõem que alguém ainda decide o que fica. O resultado dos 80% indica que ninguém decide.

Osmani também cita um estudo no arxiv sobre skills personalizadas (arxiv.org/abs/2608.10319) com um achado que merece atenção: “Uma skill baseada no histórico de um único desenvolvedor teve desempenho parecido com o de uma skill emprestada de outra pessoa. Uma skill genérica construída a partir de muitos desenvolvedores foi mais útil no geral.” Os experimentos usaram um simulador baseado em LLM em vez de desenvolvedores reais, então trate o resultado como direcional. Direcionalmente, ele enfraquece a principal justificativa que os times dão para acumular instruções sob medida.

As sessões apodrecem

Tunguz ataca a outra metade. O resumo dele: “Sessões longas apodrecem de dentro para fora.”

O mecanismo é a compactação. Quando a sessão excede a janela, o runtime resume o histórico anterior para continuar. Uma pesquisa de Shiyang Chen, citada por Tunguz, encontrou que a compactação descarta regras permanentes em 30 a 59 por cento dos episódios. Uma instrução dada no início da sessão pode ou não continuar no contexto depois de várias compactações, e nada na interface informa qual dos dois aconteceu.

Existe uma dimensão de segurança que decorre disso. Tunguz: “Um único e-mail ou convite de calendário malicioso pode envenenar a conversa, sequestrando sua agenda silenciosamente meses depois.” Uma sessão de vida longa é uma superfície de ataque de vida longa. Tudo que entra no contexto permanece até a compactação remover, e nenhuma das fontes descreve uma compactação que trate uma mensagem envenenada de forma diferente de qualquer outra.

A proposta dele é tornar o tempo de vida um parâmetro explícito de design. Um agente coordenador vive 24 horas: carrega as preferências no início da janela, delega enquanto vive, escreve em disco o que aprendeu e termina. Agentes especialistas vivem cerca de 30 segundos.

O estado durável vai para o disco. O estado durável vai para o disco: as preferências duradouras são escritas em um arquivo preferences.md e a conversa que as produziu é descartada. Tunguz enuncia a regra sem rodeios: “jogue a conversa fora; mantenha as regras em um arquivo para manter seu agente e seu jardim saudáveis.”

A mesma operação com dois nomes

Osmani apaga linhas de um arquivo. Tunguz apaga um processo em execução. Os dois estão removendo, e nenhuma das duas remoções está no calendário de alguém.

Adicionar tem gatilho óbvio. O agente erra, você adiciona uma regra, o erro para. O ciclo de feedback fecha em minutos. Remover não tem gatilho nenhum. Nenhum incidente avisa que uma regra expirou. O custo de manter a regra é difuso, distribuído por todas as sessões futuras como uma alocação de atenção ligeiramente pior, que é exatamente o tipo de custo que nenhuma organização atribui a alguém.

Descrevemos uma versão disso ao tratar da governança deficitária dos agentes que aprendem sozinhos: sistemas que aprendem continuamente sem mecanismo para desaprender. O acúmulo de configuração é a versão de baixa tecnologia da mesma falha, e acontece em repositórios que não têm sistema de aprendizado algum. Contexto passivo tem a mesma exposição. Contexto que carrega automaticamente é contexto que ninguém relê.

O teste de remoção

O que o ensaio de Osmani tem de mais útil é entregar um teste em vez de uma opinião. Desative todas as skills locais, refaça a tarefa com o modelo puro e veja o que quebra. Se a saída for a mesma, aquela instrução não estava justificando o espaço que ocupa.

Esse teste é falsificável de um jeito que “esta regra ainda é relevante?” jamais será. Ler uma regra e julgar a relevância dela produz um sim quase sempre, porque a regra parece sensata isolada. Rodar a tarefa sem ela produz evidência.

A ferramenta cobre parte disso. A lista de auditoria de Osmani para o /doctor é: skills não usadas, servidores MCP, superespecificação e hooks lentos. A memória automática é revisada à parte, com /memory. Cadência recomendada: a cada duas a quatro semanas, mensal no mínimo.

Duas a quatro semanas é uma cadência recomendada. Nenhuma das duas fontes mediu em que semana uma configuração fica obsoleta. O que as duas fontes estabelecem é que a degradação é real e invisível, o que torna uma cadência arbitrária melhor do que esperar por um sinal que nunca chega.

Faça isto agora

Três coisas, em ordem de quanto custam a você.

Coloque a auditoria no calendário. A cada duas a quatro semanas, mensal no piso. Marque como evento recorrente com dono. Item de backlog sobre custo invisível nunca é puxado.

Rode o teste de remoção nos seus cinco maiores blocos de instrução. Desative, refaça com o modelo puro, compare. Apague o que sair da comparação inalterado. Espere errar sobre quais blocos serão esses.

Defina um tempo de vida para os agentes de longa duração e deixe que eles morram. Escreva a parte durável em arquivo antes. Se o seu coordenador roda desde o mês passado, as regras permanentes dele já passaram por compactação repetidas vezes, e você não tem registro do que saiu.

A premissa padrão é que o estado do agente se valoriza. As medições apontam para o outro lado. Configuração e sessão têm meia-vida, e a única operação de manutenção que trata disso é a que ninguém agenda.

---

Fontes

• Addy Osmani. “Audit your agent files.” Agosto de 2026.
• Tomasz Tunguz. “How long should an AI agent live?.” Agosto de 2026.

A Victorino constrói a disciplina de auditoria e remoção que impede configurações e sessões de agentes de apodrecerem silenciosamente em produção: contato@victorino.com.br | www.victorino.com.br