Seu agente tem memória que você não escreveu

LLMs desenvolvem memória comportamental inconsciente que as avaliações existentes deixam passar inteiramente. Um artigo da ACL 2026 constatou que os principais modelos pontuam abaixo de 66% na detecção de seus próprios padrões comportamentais aprendidos, padrões que persistem entre sessões sem armazenamento explícito. A memória explícita que você escreve (SOUL.md, CLAUDE.md) é apenas metade do quadro.

Passei a maior parte de hoje escrevendo uma referência prática para o Hermes Agent. Uma das seções estruturais cobre o SOUL.md, o arquivo onde você fixa a identidade do seu agente. Voz, tom, preferências, guardrails comportamentais. Toda a premissa da seção é que você coloca a identidade ali, o agente a lê no topo de cada system prompt, e o agente se comporta de acordo. Memória explícita. Declarativa. Auditável. Versionada. O tipo certo de memória, o tipo com o qual um praticante sério deveria se importar.

Um artigo apareceu no arxiv ontem que captei em uma varredura de sinal hoje à noite, e lê-lo me fez segurar a premissa do SOUL.md com menos firmeza do que segurava mais cedo no dia.¹

O artigo se chama ImplicitMemBench: Measuring Unconscious Behavioral Adaptation in Large Language Models.¹ Os autores o descrevem como o primeiro benchmark sistemático para memória implícita em LLMs: a memória que (no enquadramento deles) molda o que um agente automaticamente executa, como algo distinto da memória explícita que molda o que ele conscientemente recorda.¹ Os melhores desempenhos pontuam abaixo de 66%.¹ Os autores também relatam uma assimetria “dramática” dentro dessa pontuação,¹ que vou desempacotar com a cautela apropriada mais adiante.

TL;DR

Os benchmarks de memória existentes medem recordação explícita: dado um fato que você contou ao modelo, ele consegue recuperá-lo. O ImplicitMemBench mede um sistema de memória diferente, aquele que (segundo os autores) molda o comportamento automático “sem recuperação consciente,” extraído de construtos padrão da ciência cognitiva (memória procedural, priming, condicionamento clássico).¹ Em um benchmark de 300 itens com pontuação na primeira tentativa, nenhum modelo testado pelos autores excedeu 66% no geral: DeepSeek-R1 pontuou 65,3%, Qwen3-32B 64,1%, GPT-5 63,0%, e os autores descrevem os melhores desempenhos como “muito abaixo das baselines humanas.”¹ O número principal conta apenas metade da história. O resumo também relata uma assimetria “dramática”: 17,6% em inibição versus 75,0% em preferência, uma diferença de ~4x, enquadrada como um “gargalo universal” que os autores dizem precisar de “inovações arquiteturais além do escalonamento de parâmetros.”¹ Leio a assimetria (com a ressalva de que o resumo não publica a metodologia completa por trás desses dois números) como consistente com um modo de falha do folclore que venho observando no trabalho com agentes: sistemas que reforçam rapidamente preferências vistas recentemente e falham em desaprender falhas vistas recentemente. Se essa leitura se sustentar, ela reformula a conversa sobre identidade do agente, segurança e evolução de skills de “o que você colocou no prompt?” para “o que a sessão pode estar silenciosamente moldando que seus pins explícitos não conseguem auditar?” A reformulação é minha extensão do artigo, não a afirmação do próprio artigo.

Pontos principais

Os bullets abaixo são minha leitura do que as descobertas do artigo implicam para praticantes, não afirmações que o próprio artigo faz. O artigo testa 17 LLMs em um benchmark de ciência cognitiva de 300 itens; ele não avalia harnesses de agentes em produção ou estratégias de prompting. Rotulo cada ponto de acordo.

• Extensão: fixar a identidade em SOUL.md, AGENTS.md, CLAUDE.md, system prompts ou arquivos de memória persistente é memória declarativa explícita, na qual os benchmarks existentes já mostram que os modelos se saem bem. O ImplicitMemBench mede um sistema de memória totalmente diferente, e os modelos pontuam abaixo de 66% nele.¹ A implicação prática (de que os pins de identidade explícitos podem não se propagar para o comportamento automático de primeira tentativa) é minha inferência, não a do artigo.
• Extensão: a assimetria de 17,6% vs 75,0%, se generalizar além do benchmark, preveria um agente que absorve rapidamente preferências vistas recentemente e é lento em parar de repetir falhas vistas recentemente. O artigo relata os dois números e os rotula como “dramáticos” e “universais,”¹ mas não publica metodologia por item de como “preferência” e “inibição” foram operacionalizadas, e não testa esse padrão em harnesses de agentes. A leitura de comportamento em produção é minha.
• Extensão: cada token que chega à janela de contexto a partir de uma chamada de ferramenta, resposta de MCP, página web raspada ou tentativa de prompt injection é influência comportamental em contexto. Não treinamento em nenhum sentido de atualização de pesos, mas influência na próxima resposta de primeira tentativa que a camada de prompt explícito não pode auditar de forma limpa. O artigo não faz essa afirmação diretamente; estou estendendo o enquadramento de memória implícita para o conteúdo da janela de contexto.
• Afirmação do artigo: a avaliação de 17 modelos revela “limitações severas,” “assimetrias dramáticas” e “gargalos universais que requerem inovações arquiteturais além do escalonamento de parâmetros.”¹ Os autores enquadram a lacuna como arquitetural. Leio isso como evidência fraca contra “mais engenharia de prompt vai consertar isso,” mas o artigo não testa especificamente mitigações de prompting, então trate essa leitura como minha hipótese, não a deles.

O que o artigo mede

O enquadramento do artigo é que os benchmarks de memória existentes para agentes LLM “avaliam a recordação explícita de fatos, mas ignoram a memória implícita onde a experiência se torna comportamento automatizado sem recuperação consciente.”¹ A lacuna que eles identificam: “assistentes eficazes devem aplicar automaticamente procedimentos aprendidos ou evitar ações falhas sem lembretes explícitos.”¹ Se a única forma de seu agente evitar um erro é você recontar a ele para não cometer o erro a cada turno, você não está construindo sobre memória implícita; você está pagando o custo da memória explícita a cada requisição.

O ImplicitMemBench testa três construtos extraídos diretamente dos relatos da ciência cognitiva sobre memória não-declarativa, citados do resumo:¹

1. Memória procedural: “aquisição de habilidade em uma tentativa após interferência.” O modelo, depois de receber uma demonstração de como fazer algo uma vez, consegue realmente executá-lo novamente mais tarde, mesmo quando outras instruções intervieram? A memória procedural permite que um humano aprenda a andar de bicicleta: você não recorda como andar, você anda, mesmo depois de anos sem pegar na bicicleta.
2. Priming: “viés orientado por tema via instâncias experimentais/controle pareadas.” Ver uma classe de coisa faz o modelo mais propenso a produzir essa classe de coisa na próxima tarefa não relacionada, sem que o modelo esteja ciente de que o priming aconteceu?
3. Condicionamento clássico: “associações Estímulo Condicionado-Estímulo Incondicionado (CS-US) moldando primeiras decisões.” Se o modelo foi exposto a um pareamento estímulo-resposta, esse pareamento aparece como um viés em uma tarefa totalmente nova onde nem o CS nem o US são o ponto da questão?

Os autores usam um conjunto de 300 itens sob um protocolo unificado “Learning/Priming-Interfere-Test com pontuação de primeira tentativa.”¹ Pontuação de primeira tentativa é importante. Um modelo que pode se autocorrigir depois de receber o aviso de que errou está bem, mas a questão de pesquisa aqui é se a memória moldou a primeira resposta automática. Se a primeira resposta está errada e a correção só acontece após feedback explícito, o sistema de memória implícita (como o artigo o define) falhou naquele item. Os autores resumem sua contribuição com uma linha que quero destacar diretamente: o benchmark “reformula a avaliação de ‘o que os agentes recordam’ para ‘o que eles automaticamente executam’.”¹

Os resultados

O número principal: “nenhum modelo excede 66% no geral.”¹

• DeepSeek-R1: 65,3%
• Qwen3-32B: 64,1%
• GPT-5: 63,0%

Os melhores desempenhos acima são descritos como “muito abaixo das baselines humanas,” embora o resumo não publique o número exato da baseline humana ou um ranking completo por modelo.¹ Dezessete modelos no total são avaliados no artigo.¹

O número principal esconde o sub-resultado. Os autores escrevem que “a análise revela assimetrias dramáticas (inibição 17,6% vs. preferência 75,0%) e gargalos universais que requerem inovações arquiteturais além do escalonamento de parâmetros.”¹ Quero ser cuidadoso aqui sobre o que os números significam. O resumo não dá uma divisão metodológica completa de como os autores calcularam esses dois números, então minha glosa deles é uma inferência a partir da redação do resumo, não uma leitura das definições internas do artigo. Com essa ressalva sinalizada:

• Preferência: 75,0% (número do artigo). Minha glosa, pendente do artigo completo: os modelos parecem relativamente bons em mostrar que a exposição implícita os puxou em direção a um estímulo. Priming e pareamentos CS-US que enviesam o comportamento em uma direção particular acertam cerca de três quartos das vezes.
• Inibição: 17,6% (número do artigo). Minha glosa, pendente do artigo completo: os modelos parecem dramaticamente piores em mostrar que a exposição implícita os afastou de um estímulo. O sinal de “não faça isso de novo” acerta menos de uma vez em cinco. Infiro o significado comportamental da palavra “inibição” e do enquadramento do artigo sobre condicionamento clássico; o resumo não detalha a operacionalização.

Os autores rotulam explicitamente a assimetria como “dramática” e a atribuem a “gargalos universais,”¹ e a palavra universal importa: os autores apresentam isso como um padrão em toda a avaliação de 17 modelos, não um artefato de um único modelo. Não vou afirmar que o gargalo é um “problema de prompting” ou “não um problema de prompting.” O artigo não testa prompting como mitigação, e dizer qualquer uma dessas coisas iria além do que o resumo sustenta.

O que a assimetria realmente significa

Quero ser preciso sobre o que estou afirmando aqui, porque esta é a parte em que é tentador fazer uma leitura exagerada de um benchmark.

O que o artigo mostra. Em um benchmark de 300 itens cognitivamente fundamentado, pontuado em respostas de primeira tentativa, LLMs são dramaticamente piores em demonstrar inibição implícita do que preferência implícita, por um fator de aproximadamente quatro, em todos os modelos testados. Os autores chamam isso de gargalo universal que não pode ser corrigido por escalonamento.

O que estou afirmando — separadamente do artigo. O padrão de assimetria mapeia em um modo de falha que venho observando no meu próprio trabalho com agentes há meses, sem ter tido um nome para ele anteriormente. Harnesses de agentes (na minha experiência) parecem surpreendentemente bons em absorver contexto que aponta para um estilo, ferramenta ou abordagem preferido. O comportamento do agente deriva rapidamente em direção ao que você alimentou mais recentemente. Eles parecem surpreendentemente ruins em não repetir uma falha que acabaram de ver acontecer. O agente tenta o mesmo comando quebrado, a mesma ferramenta errada, o mesmo caminho obsoleto, mesmo depois que esses falharam na mesma sessão. Isso é folclore, não uma medição; é minha impressão como praticante, não um estudo controlado. Os números do ImplicitMemBench são consistentes com esse folclore, e é por isso que me importo com o artigo. Eles não, por si só, validam o folclore, e não quero afirmar que o artigo dá ao meu folclore “um número” quando o artigo mediu algo mais rigoroso e controlado do que qualquer coisa que venho observando.

O que não estou afirmando. Não estou afirmando que o ImplicitMemBench mediu especificamente o comportamento de harness de agente ou fluxos de trabalho de Claude Code / Cursor / Codex em produção. Não mediu. Ele mediu 17 modelos contra um protocolo estruturado de ciência cognitiva. O mapeamento do benchmark para o comportamento em produção é minha extensão, rotulada como tal, e não quero que ninguém lendo isso pense que o artigo fez essa afirmação por mim.

Com esses rótulos no lugar, a distinção que o benchmark traça entre recordação explícita de uma instrução e comportamento automático de primeira tentativa sob priming/condicionamento é a distinção que quero que meu próprio trabalho com agentes comece a levar a sério. Você pode dizer ao agente “não faça X” e a recordação explícita provavelmente vai funcionar; ele pode repetir “não faça X” de volta para você quando perguntado. O que o ImplicitMemBench mede é uma coisa diferente: o agente automaticamente não faz X na próxima decisão de primeira tentativa, na ausência de qualquer lembrete explícito? Não sei se os harnesses de agentes em produção herdam o número agregado de inibição de 17,6% do benchmark em comportamento de primeira tentativa na prática. Esse mapeamento não foi testado, e não estou afirmando isso. Estou afirmando algo mais fraco: a distinção entre “pode recordar a regra” e “automaticamente executa a regra” é mais nítida do que eu vinha tratando, e os resultados do artigo são parte do porquê.

A ilusão do SOUL.md

O guia do Hermes que eu estava escrevendo hoje trata o SOUL.md como o pin de identidade primário do agente. Slot #1 em cada system prompt. Tom, voz, guardrails. O guia faz uma versão do argumento que cada sistema de memória persistente para agentes tem feito nos últimos dois anos: se você colocar a identidade no arquivo de memória declarativa correto, o comportamento do agente permanece alinhado com ele.

Esse argumento não está errado, mas o ImplicitMemBench está me dando uma razão para ser menos confiante sobre o quão completamente ele se sustenta. SOUL.md é memória declarativa explícita, o sistema de memória que os benchmarks existentes já medem e no qual os modelos já se saem bem. Os modelos podem recordar seu conteúdo sob demanda; essa é a parte fácil. A pergunta mais difícil, e a que acho que o SOUL.md não responde: o pin explícito substitui significativamente o priming implícito, o condicionamento e o viés de primeira tentativa que se acumulam à medida que uma sessão se enche com saídas de ferramentas, documentos recuperados, turnos anteriores do assistente, correções do usuário e tudo o mais que molda o comportamento de primeira tentativa sem qualquer etapa de recuperação? Não sei. O artigo não testa o SOUL.md ou qualquer arquivo equivalente de pin de identidade, e não quero afirmar que ele responde essa pergunta por mim.

Aqui está a preocupação, enquadrada como hipótese e não como descoberta. Se você fixar uma identidade no SOUL.md que diz “seja conciso e factual,” e então a sessão se encher com uma longa thread de conversa em estilo narrativo do usuário, o enquadramento de memória implícita prevê que o priming deveria parcialmente moldar o comportamento de primeira tentativa no próximo turno, mesmo enquanto o pin explícito ainda se sustenta na recordação. Se o priming realmente vence em média na produção, não posso provar a partir deste artigo, e não vou tentar. A ilusão do SOUL.md, como a estou nomeando: a possibilidade de você ter fixado a recordação da identidade em vez da execução automática dela, e essas duas coisas não serem a mesma coisa.

Não estou dizendo para não escrever SOUL.md. Ainda vou escrevê-lo, e o guia do Hermes ainda vai recomendá-lo, porque memória declarativa explícita é estrutural para as coisas que ela faz bem. O que eu estou dizendo, rotulado claramente como minha própria extrapolação: se você está construindo qualquer coisa que dependa de o agente não repetir um erro, não derivar em direção a um estilo visto recentemente, não ser puxado para fora da tarefa por um sinal de priming que você não pretendia, eu não apostaria o orçamento de confiabilidade apenas no SOUL.md, e não assumiria que tornar o SOUL.md mais longo ou mais específico resolve isso. O artigo usa a frase “inovações arquiteturais além do escalonamento de parâmetros,”¹ que leio (cautelosamente) como evidência fraca de que mitigações de engenharia de prompt não fecharão a lacuna que o benchmark mede. O próprio artigo não testa mitigações de engenharia de prompt, então não posso dizer que ele prova que elas falham; só posso dizer que ele não me dá confiança de que elas vão funcionar.

O que o artigo não diz (e o que estou adicionando)

O artigo é um artigo de benchmark. Ele mede uma lacuna, a quantifica, argumenta que a lacuna é arquitetural. Ele não prescreve mitigações específicas em nível de harness nem afirma qualquer coisa sobre sistemas específicos de agentes em produção. Tudo nesta seção é meu enquadramento, não o do artigo.

Implicação 1: cada token na janela de contexto é influência comportamental em contexto. Se o enquadramento de memória implícita se sustenta fora do benchmark (e estou especulando aqui, não relatando), cada token que chega à janela de contexto a partir de uma chamada de ferramenta, um documento recuperado ou uma resposta intermediária molda o comportamento de primeira tentativa do próximo turno de formas que ler o prompt explícito não pode auditar de forma limpa. Já escrevi anteriormente sobre a superfície de ataque de egresso silencioso (saídas não confiáveis de ferramentas carregando instruções injetadas) e seu agente ter um intermediário que você não avaliou (roteadores API de LLM não confiáveis entre seu cliente e o modelo). Nenhum desses posts afirmou a memória implícita como o mecanismo causal. Ambos afirmaram prompt injection e comprometimento de cadeia de suprimentos como os mecanismos. O ImplicitMemBench oferece uma possível lente adicional sobre por que esses ataques funcionam da forma como funcionam: mesmo que a saída hostil da ferramenta ou o roteador comprometido nunca “diga” explicitamente ao agente o que fazer, o conteúdo do que ele retorna poderia estar fazendo priming da próxima decisão do agente. Essa é uma hipótese com a qual o ImplicitMemBench é consistente, não uma descoberta que o artigo relata.

Implicação 2: a duração da sessão pode ser um risco de confiabilidade, não apenas um risco de custo. A observação folclórica é que os agentes ficam piores em sessões longas e a explicação folclórica é pressão na janela de contexto. O ImplicitMemBench não é absolutamente um estudo de duração de sessão. É um benchmark de 300 itens com pontuação de primeira tentativa sob um protocolo Learning/Priming-Interfere-Test,¹ que mede uma coisa diferente de “o que acontece em 30 turnos em uma sessão de produção.” Não quero fingir que ele mapeia diretamente para sessões de produção. O que estou sugerindo, como hipótese, é que o mecanismo que o artigo nomeia (priming implícito e condicionamento clássico chegando em decisões de primeira tentativa sem recuperação) é uma explicação alternativa candidata para a deriva folclórica, e merece consideração séria mesmo que o artigo não o teste nesse enquadramento. Minha regra operacional enquanto isso: rode sessões mais curtas do que sua janela de contexto permite, não tão longas quanto ela permite. Seguro barato contra qualquer que venha a ser o mecanismo real.

Implicação 3: o argumento de “skills estáticas são skills mortas” precisa de uma nota de rodapé. Escrevi Static Skills Are Dead Skills no início desta semana argumentando que as skills param de melhorar no momento em que são enviadas, a menos que você construa um loop de feedback de trajetória. Esse argumento assumia que o modo de falha era ausência: ausência de agregação, ausência de um detector de padrões, ausência de um evolutor. Lendo o ImplicitMemBench contra aquele post anterior, quero sinalizar um possível segundo modo de falha sobreposto: mesmo com atualizações de skills orientadas por trajetória, a atualização chegando no arquivo de skill (memória declarativa explícita) pode não se propagar de forma limpa para o comportamento automático de primeira tentativa se algo mais próximo da camada de memória implícita direcionar as decisões de primeira tentativa. Não sei se é o caso. O artigo não testa atualizações de skills. Mas é uma preocupação que eu não tinha quando escrevi o post anterior, e estou sinalizando como uma preocupação em vez de uma conclusão.

Implicação 4: o problema de medição para qualidade de agentes pode estar ficando mais difícil. A maioria das avaliações de agentes existentes mede ou a conclusão funcional da tarefa (o agente resolveu o problema) ou a recordação explícita de fatos (o agente se lembrou do que você disse). O ImplicitMemBench introduz, em seu próprio protocolo, uma terceira dimensão: comportamento automático de primeira tentativa sob priming implícito. Se essa dimensão acabar importando na produção (o que não sei, e o artigo não testa), qualquer loop de qualidade sério para trabalho com agentes precisa de um gancho de medição para isso, e a maioria dos loops hoje não tem. Estou tratando isso como um TODO para meu próprio sistema de qualidade, em vez de uma prescrição para o seu.

Implicação 5: alinhamento é um portão de recuperação, não um mecanismo de apagamento. Um artigo separado de Liu et al. fortalece o enquadramento de memória implícita por um ângulo diferente.² Eles mostram que o fine-tuning em texto semanticamente relacionado (mesmo romances de domínio público) reativa a recordação literal de livros protegidos por direitos autorais que o modelo havia memorizado durante o pré-treinamento, mas que o alinhamento havia suprimido: até 85-90% de reprodução literal, trechos únicos excedendo 460 palavras, generalizando entre mais de 30 autores não relacionados quando fine-tunado em apenas um, com correlação entre modelos r >= 0,90 entre GPT-4o, Gemini-2.5-Pro e DeepSeek-V3.1.² O mecanismo importa para o argumento de memória implícita: a memorização já estava codificada nos pesos de pré-treinamento. O fine-tuning não injetou novo conhecimento — ele contornou o portão de alinhamento que bloqueava a recuperação. Se o alinhamento funciona como um portão em vez de um apagador, a pegada real de memória do modelo é maior e menos controlável do que o que os mecanismos explícitos (alinhamento, system prompts, pins de identidade) expõem. O ImplicitMemBench faz a mesma afirmação estrutural pelo lado comportamental: o modelo tem memória, tanto comportamental quanto de conteúdo, que seus pins explícitos não governam. O artigo de finetuning e o ImplicitMemBench estão medindo diferentes manifestações da mesma realidade subjacente. (Como antes, a conexão entre esses dois artigos é meu enquadramento, não uma afirmação que qualquer um dos artigos faça.)

O que realmente fazer

Nenhum dos artigos prescreve ou testa qualquer coisa nesta seção. O que segue é minha leitura, trabalhando a partir dos meus próprios argumentos anteriores e usando o ImplicitMemBench e a descoberta do portão de alinhamento como peças adicionais de evidência, do que as descobertas implicam para praticantes construindo contra harnesses atuais. Rotule de acordo.

Pare de assumir que pins explícitos são suficientes. Continue escrevendo SOUL.md, AGENTS.md, CLAUDE.md e arquivos de memória, mas trate-os como necessários-mas-não-suficientes. O post AGENTS.md patterns documenta como estruturar esses arquivos de forma eficaz; este post adiciona uma condição de contorno sobre o que eles podem garantir. A coisa que estou atualizando é minha própria suposição padrão de que “se está no system prompt, ele se sustenta.” O artigo não testa essa suposição; ele testa questões adjacentes e relata pontuações que me fazem querer segurar minha própria suposição com menos firmeza do que fazia ontem.

Encurte sessões deliberadamente. A observação folclórica é que os agentes ficam piores em sessões longas. A explicação folclórica que venho usando é “pressão de contexto.” O ImplicitMemBench não é um estudo de duração de sessão. Ele usa um protocolo controlado Learning/Priming-Interfere-Test, não sessões de produção de longa duração.¹ Mas o mecanismo que ele nomeia (priming implícito e condicionamento clássico chegando sem recuperação) é uma explicação alternativa candidata para esse folclore. A regra operacional que estou adotando: quando uma sessão deriva, não lute contra ela com mais correção explícita. Dê /new na sessão e comece do zero. Seja a deriva pressão da janela de contexto, priming implícito ou outra coisa, uma sessão limpa reseta o que quer que seja realmente a causa.

Trate inibição como difícil de impor no prompt. Se você precisa que seu agente não faça algo, não confie em ter dito a ele para não fazer. Construa um guarda estrutural (um linter, um hook pré-ferramenta, uma política de sandbox, uma ferramenta que recusa a chamada) que imponha a proibição na camada de código. Meu argumento do loop de qualidade Jiro tem sido que portões rígidos precisam estar fora do modelo por um motivo; eu já sustentava essa posição antes deste artigo. O ImplicitMemBench adiciona um padrão específico (o número agregado de inibição de 17,6%¹) que é consistente com o argumento que venho fazendo, embora o artigo em si não teste prompting ou harnesses de agentes, e eu não queira exagerar afirmando que ele prova a posição.

Audite o contexto pelo que ele faz priming, não apenas por quantos tokens ele tem. Contagem de tokens é a medição que todo mundo tem. Se o enquadramento de priming implícito é uma lente útil (e estou tratando isso como uma hipótese que quero testar, não um resultado estabelecido), um contexto de 20k tokens cheio de conteúdo narrativo de persona de usuário pode moldar o comportamento de primeira tentativa em direção a saídas narrativas mais do que um contexto de 60k tokens cheio de código estruturado. Ainda não tenho ferramentas para esse tipo de auditoria de eixo de conteúdo, e não tenho certeza se alguém tem. A versão mínima viável é: olhe para suas sessões recentes e pergunte “para o que um humano lendo esse contexto estaria sendo enviesado?” Se essa pergunta é realmente preditiva do comportamento do agente é empírico e não vou fingir que o artigo decide isso.

Registre a disposição de primeira tentativa, não apenas a disposição final. Se você está rodando qualquer tipo de captura de trajetória contra suas skills, separe “o que o agente tentou primeiro” de “onde o agente pousou após correção.” O protocolo de pontuação de primeira tentativa do ImplicitMemBench¹ é o argumento metodológico para por que essa separação importa: a disposição final mede o agente mais o loop de correção, enquanto a de primeira tentativa mede o que o agente realmente produziu antes do feedback externo. Para qualquer loop de qualidade onde a experiência do usuário depende da primeira resposta pousar certa, você precisa do número de primeira tentativa, e quase nada o registra separadamente hoje.

FAQ

O ImplicitMemBench testa algum harness de agente especificamente?

Não. Ele testa 17 LLMs diretamente em um benchmark de 300 itens sob um protocolo Learning/Priming-Interfere-Test com pontuação de primeira tentativa.¹ Não é um benchmark de harness. Ele não avalia Claude Code, Cursor, Codex, Hermes ou qualquer loop de agente em produção. O mapeamento que faço neste post dos resultados do benchmark para o comportamento de harness de agente em produção é minha extensão, rotulada como tal por todo o texto, e não é uma descoberta do artigo.

A assimetria de 17,6% vs. 75,0% é um resultado por modelo ou agregado?

O resumo descreve a assimetria como parte da análise dos autores sobre os resultados gerais do benchmark entre os modelos, e a rotula como evidência de “gargalos universais.”¹ Leio isso como a assimetria aparecendo consistentemente nos 17 modelos testados, com os números específicos refletindo o padrão agregado. O resumo não publica uma divisão por modelo, e não vou inventar uma. Para a divisão completa por modelo, o artigo é a fonte.

Por que isso pode importar mais para agentes em produção do que para benchmarks existentes?

Ressalva parcial nessa. O próprio ImplicitMemBench usa um protocolo de múltiplas etapas (Learning/Priming-Interfere-Test),¹ então não é o caso de o benchmark ser “single-shot.” Não quero repetir a linha descuidada habitual sobre benchmarks. O que parece valer a pena sinalizar (como especulação de praticante, não uma descoberta do artigo) é que a maioria das outras avaliações de agente que as pessoas olham mede ou conclusão funcional de tarefa ou recordação explícita de fatos, ambas favorecendo os modelos. Se a lacuna de memória implícita relatada por este artigo for real além de seu próprio protocolo (e não sei se é), essas outras avaliações estão perdendo uma dimensão do comportamento em produção que os usuários realmente experimentam em sessões de longa duração. Estou tratando isso como uma hipótese testável, não uma conclusão.

Isso contradiz seu conselho sobre SOUL.md no guia do Hermes?

Não. Adiciona uma condição de contorno. O guia do Hermes recomenda o SOUL.md como o pin de identidade primário porque a memória declarativa explícita ainda é estrutural para o que ela faz bem: recordação consistente de identidade, controle de versão auditável, comportamento previsível sob questionamento direto. O guia do Hermes não cobriu (porque nada existia para medir isso até este artigo aparecer) o fato de que o pin de identidade explícito não se propaga automaticamente para o comportamento automático de primeira tentativa sob priming e condicionamento clássico. Você ainda quer o SOUL.md. Você também quer guardas estruturais fora dele.

Engenharia de prompt pode resolver alguma coisa disso?

A resposta honesta é que o artigo não testa prompting como estratégia de mitigação, então não posso dizer com autoridade do artigo. O que posso dizer: os autores enquadram a lacuna como “requerendo inovações arquiteturais além do escalonamento de parâmetros,”¹ que é uma afirmação mais forte do que “prompts melhores vão ajudar” mas não é exatamente “nenhum prompt pode ajudar.” Para o lado da inibição especificamente (17,6% agregado), minha intuição como praticante (que você deve descontar em relação ao próprio artigo) é que guardas estruturais fora do modelo são uma aposta mais segura do que instruções de prompt. Mas isso sou eu, não o artigo.

Este é um dos artigos de “benchmark de memória” que tenho visto muito recentemente?

Não, e o artigo explicitamente se distingue deles. O enquadramento do resumo é que os benchmarks de memória existentes avaliam recordação explícita de fatos: dê ao modelo um fato, peça ao modelo para recuperá-lo. O ImplicitMemBench mede uma coisa totalmente diferente, adaptação automática de comportamento sem qualquer etapa de recuperação.¹ Essa distinção é a contribuição do artigo e a razão pela qual ele conquistou aceitação na Conferência Principal da ACL 2026.¹

Onde isso se posiciona em relação aos seus posts anteriores sobre memória de agente?

O post fica dentro do hub de engenharia de IA e é um companheiro direto de Static Skills Are Dead Skills. Context is architecture faz o argumento estrutural para por que o que entra na janela de contexto importa; compound context descreve a infraestrutura que se acumula ao longo das sessões. Aquele post anterior argumentava que as skills precisam de agregação de trajetória para se manterem vivas, e eu assumia que o modo de falha era pura ausência: se você pudesse apenas obter os dados de trajetória e rodar um detector de padrões, você estaria bem. O ImplicitMemBench aponta para um segundo modo de falha sobreposto: mesmo com atualizações de skills perfeitas orientadas por trajetória, o comportamento de primeira tentativa pode não refletir a atualização porque a atualização chegou na memória explícita e a memória implícita direciona as decisões reais. O post anterior ainda está correto sobre o que afirmou; o presente post atualiza o que ele não sabia afirmar.

Isso poderia ser um artefato de medição?

Possivelmente. O artigo é novo (submetido em 9 de abril de 2026, aceito na Conferência Principal da ACL 2026), e benchmarks únicos podem medir artefatos de seus protocolos específicos tão facilmente quanto medem fenômenos reais.¹ Não vou fingir o contrário. A razão pela qual acho que não é apenas um artefato é que o modo de falha que ele descreve (agentes reforçando preferências rapidamente enquanto falham em desaprender falhas) é folclore que venho observando sem um nome para ele há mais de um ano. O benchmark não precisa estar perfeitamente calibrado para a direção do resultado ser a coisa sobre a qual os praticantes devem agir.

Referências