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

Passei a maior parte do dia de hoje escrevendo uma referência prática para o Hermes Agent. Uma das seções mais importantes é sobre o SOUL.md — o arquivo onde você fixa a identidade do seu agente. Voz, tom, preferências, guardrails comportamentais. A premissa toda da seção é que você coloca a identidade ali, o agente lê no topo de todo system prompt, e o agente se comporta conforme o esperado. 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 um signal scan hoje à noite, e lê-lo me fez segurar a premissa do SOUL.md de forma mais frouxa do que segurava mais cedo.¹

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 detalhar com as ressalvas apropriadas mais adiante.

TL;DR

Os benchmarks de memória existentes medem recall explícito — 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”, baseado em construtos padrão da ciência cognitiva (memória procedural, priming, condicionamento clássico).¹ Em um benchmark de 300 itens com pontuação de primeira tentativa, nenhum modelo testado pelos autores ultrapassou 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 da manchete não é a história toda — o abstract também relata uma assimetria “dramática”: 17,6% em inibição contra 75,0% em preferência, uma diferença de ~4×, enquadrada como um “gargalo universal” que os autores dizem exigir “inovações arquiteturais além do escalonamento de parâmetros”.¹ Estou lendo a assimetria — com a ressalva de que o abstract não publica a metodologia completa por trás desses dois números — como consistente com um modo de falha folclórico 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 estiver certa, ela reenquadra a conversa sobre identidade, segurança e evolução de skills de agentes 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?”. O reenquadramento é minha extensão do artigo, não uma afirmação do próprio artigo.

Principais pontos

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 com 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 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 vão bem. O ImplicitMemBench mede um sistema de memória inteiramente diferente, e os modelos pontuam abaixo de 66% nele.¹ A implicação prática — de que pins explícitos de identidade podem não se propagar para o comportamento automático de primeira tentativa — é minha inferência, não 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 para 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 sobre como “preferência” e “inibição” foram operacionalizadas, e não testa esse padrão em harnesses de agentes. A leitura do comportamento em produção é minha.
• Extensão: cada token que aterrissa na janela de contexto vindo de uma chamada de ferramenta, resposta de MCP, página web raspada ou tentativa de prompt-injection é influência comportamental in-context — não é treinamento no sentido de atualização de pesos, mas influência sobre a próxima resposta de primeira tentativa que a camada de prompt explícito não consegue auditar de forma clara. O artigo não faz essa afirmação diretamente; estou estendendo o enquadramento de memória implícita ao 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 exigem inovações arquiteturais além do escalonamento de parâmetros”.¹ Os autores enquadram a lacuna como arquitetural. Estou lendo isso como evidência fraca contra “mais prompt engineering vai resolver isso”, mas o artigo não testa especificamente mitigações de prompting, então trate essa leitura como minha hipótese, não deles.

O que o artigo mede

O enquadramento do artigo é que os benchmarks de memória existentes para agentes LLM “avaliam o recall explícito de fatos, mas negligenciam a memória implícita, em que 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 que falharam sem lembretes explícitos”.¹ Se a única forma de seu agente evitar um erro é você dizer 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 retirados diretamente das descrições da ciência cognitiva sobre memória não declarativa, citados do abstract:¹

1. Memória procedural — “aquisição de skill one-shot após interferência”. O modelo, depois de ter visto como fazer algo uma vez, consegue de fato executá-lo novamente mais tarde, quando outras instruções intervieram? Este é o sistema de memória que permite a um humano aprender a andar de bicicleta: você não recorda como pedalar, você pedala, mesmo após anos longe da bicicleta.
2. Priming — “viés impulsionado por tema via instâncias experimentais/controle pareadas”. Ver uma classe de coisa faz com que o modelo tenha maior probabilidade de produzir aquela 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 as primeiras decisões”. Se o modelo foi exposto a um pareamento estímulo-resposta, esse pareamento aparece como viés em uma tarefa totalmente nova em que nem o CS nem o US são o ponto da pergunta?

Os autores usam um conjunto de 300 itens sob um protocolo unificado “Learning/Priming-Interfere-Test com pontuação de primeira tentativa”.¹ A pontuação de primeira tentativa é importante. Um modelo que consegue se autocorrigir depois de ser informado de que errou está ok — mas a pergunta de pesquisa aqui é se a memória moldou a resposta automática inicial. 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 citar diretamente: o benchmark “reenquadra a avaliação de ‘o que os agentes recordam’ para ‘o que eles automaticamente executam’”.¹

Os resultados

O número da manchete: “nenhum modelo ultrapassa 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 abstract 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.¹

A manchete esconde o subresultado. Os autores escrevem que “a análise revela assimetrias dramáticas (inibição 17,6% vs. preferência 75,0%) e gargalos universais que exigem inovações arquiteturais além do escalonamento de parâmetros”.¹ Quero ser cuidadoso aqui sobre o que os números significam — o abstract não fornece uma descrição metodológica completa de como esses dois números foram computados, então minha interpretação deles é uma inferência a partir da redação do abstract, não uma leitura das definições internas do artigo. Com essa ressalva sinalizada:

• Preferência: 75,0% (número do artigo). Minha interpretação, pendente do artigo completo: esse número parece consistente com os modelos sendo relativamente bons em mostrar que foram implicitamente puxados 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 interpretação, pendente do artigo completo: esse número parece consistente com os modelos sendo dramaticamente piores em mostrar que foram implicitamente empurrados para longe de um estímulo — o sinal de “não faça isso de novo” acertando menos de uma vez em cinco. Estou inferindo o significado comportamental a partir da palavra “inibição” e do enquadramento do artigo sobre condicionamento clássico; o abstract não detalha a operacionalização.

Os autores explicitamente rotulam 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 como 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 das coisas iria além do que o abstract sustenta.

O que a assimetria realmente significa

Quero ser preciso sobre o que estou afirmando aqui, porque esta é a parte em que é tentador ler demais em um benchmark.

O que o artigo mostra. Em um benchmark de 300 itens com base cognitiva, 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 todo modelo testado. Os autores chamam isso de um gargalo universal que não pode ser corrigido por escalonamento.

O que estou afirmando — separadamente do artigo. Esse padrão de assimetria mapeia para um modo de falha que venho observando em meu próprio trabalho com agentes há meses, sem antes ter um nome para isso. Harnesses de agentes (na minha experiência) parecem surpreendentemente bons em absorver contexto que aponta para um estilo, ferramenta ou abordagem preferidos — 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 desatualizado, mesmo depois de terem falhado 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 apertado e mais controlado do que qualquer coisa que venho observando.

O que não estou afirmando. Não estou afirmando que o ImplicitMemBench mediu especificamente comportamento de harness de agente ou fluxos de produção Claude Code / Cursor / Codex. Ele 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 postos: a distinção que o benchmark está traçando — entre recall explícito 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 o recall explícito provavelmente funcionará — ele pode repetir “não faça X” de volta para você quando perguntado. O que o ImplicitMemBench está medindo é algo 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 harnesses de agentes em produção herdam o número agregado de inibição de 17,6% do benchmark no comportamento de primeira tentativa em ambientes reais — esse mapeamento não foi testado, e não estou afirmando isso. Estou afirmando algo mais fraco: a distinção entre “conseguir recordar a regra” e “automaticamente executar a regra” é mais aguda do que eu vinha tratando, e os resultados do artigo são parte do motivo.

A ilusão do SOUL.md

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

Esse argumento não está errado, mas o ImplicitMemBench está me dando uma razão para ficar menos confiante sobre o quão completamente ele se sustenta. O SOUL.md é memória declarativa explícita — o sistema de memória que os benchmarks existentes já medem e no qual os modelos já vão bem. Os modelos conseguem recordar seu conteúdo sob demanda; essa é a parte fácil. A pergunta mais difícil, e a que não acho que o SOUL.md responda: o pin explícito sobrescreve de forma significativa o priming implícito, o condicionamento e o viés de primeira tentativa que se acumulam à medida que uma sessão se enche de outputs de ferramentas, documentos recuperados, turnos anteriores do assistente, correções do usuário e todo o resto que molda o comportamento de primeira tentativa sem qualquer passo de recuperação? Não sei. O artigo não testa 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 achado. Se você fixa uma identidade no SOUL.md dizendo “seja conciso e factual”, e então a sessão se enche de uma longa thread de conversa em estilo narrativo do usuário, o enquadramento de memória implícita prevê que o comportamento de primeira tentativa no próximo turno deveria ser moldado em parte pelo priming, mesmo enquanto o pin explícito ainda se sustenta no recall. Se o priming realmente vence em média na produção — não posso provar isso 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 o recall da identidade em vez da execução automática dela, e essas duas coisas não são a mesma.

Não estou dizendo para não escrever SOUL.md. Ainda vou escrevê-lo — e o guia do Hermes ainda vai recomendá-lo — porque a memória declarativa explícita é fundamental para as coisas em que ela é boa. O que estou dizendo, rotulado claramente como minha própria extrapolação: se você está construindo algo que depende 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 pretendeu, 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 resolva. O artigo usa a frase “inovações arquiteturais além do escalonamento de parâmetros”,¹ o que leio — cautelosamente — como evidência fraca de que mitigações de prompt engineering não vão fechar a lacuna que o benchmark mede. O artigo em si não testa mitigações de prompt engineering, 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 funcionarão.

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

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

Implicação 1: cada token na janela de contexto é influência comportamental in-context. Se o enquadramento de memória implícita se sustentar fora do benchmark — e estou especulando aqui, não reportando — cada token que aterrissa na janela de contexto vindo de uma chamada de ferramenta, de um documento recuperado ou de uma resposta intermediária está moldando o comportamento de primeira tentativa do próximo turno de formas que ler o prompt explícito não consegue auditar de maneira clara. Já escrevi anteriormente sobre a superfície de ataque de egresso silencioso (outputs de ferramentas não confiáveis carregando instruções injetadas) e sobre seu agente ter um intermediário que você não revisou (roteadores API de LLM não confiáveis entre seu cliente e o modelo). Nenhum desses posts afirmou a memória implícita como mecanismo causal — eles afirmaram prompt injection e comprometimento de supply-chain como os mecanismos. O ImplicitMemBench oferece uma lente adicional possível sobre por que esses ataques funcionam do jeito que funcionam: mesmo que o output de ferramenta hostil ou o roteador comprometido nunca “diga” explicitamente ao agente o que fazer, o conteúdo do que eles retornam poderia estar fazendo priming na próxima decisão do agente. Isso é uma hipótese com a qual o ImplicitMemBench é consistente, não um achado que o artigo reporta.

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 pioram ao longo de sessões longas e a explicação folclórica é a pressão da 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 algo diferente de “o que acontece ao longo de 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 aterrissando em decisões de primeira tentativa sem recuperação) é uma explicação alternativa candidata para a deriva folclórica, e vale levar a sério mesmo que o artigo não teste isso nesse enquadramento. Minha regra operacional enquanto isso: execute sessões mais curtas do que sua janela de contexto permite, não tão longas quanto ela permite. É um 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 skills param de melhorar no momento em que são publicadas, 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 evoluidor. Lendo o ImplicitMemBench contra aquele post anterior, quero sinalizar um possível segundo modo de falha sobreposto: mesmo com atualizações de skill orientadas por trajetória, a atualização aterrissando 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 o comportamento de primeira tentativa estiver sendo impulsionado por algo que opera mais perto da camada de memória implícita. 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 a 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 tanto a conclusão funcional de tarefas (o agente resolveu o problema) quanto o recall explícito de fatos (o agente lembrou o que você disse a ele). 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 quality loop sério para trabalho com agentes precisa de um hook de medição para isso, e a maioria dos loops hoje não tem um. Estou tratando isso como um TODO para meu próprio sistema de qualidade, em vez de uma prescrição para o seu.

O que realmente fazer

Nada nesta seção é prescrito ou testado pelo artigo. Esta é minha leitura — trabalhando para frente a partir de meus próprios argumentos anteriores, usando o ImplicitMemBench como mais uma peça de evidência — do que as descobertas implicam para praticantes construindo contra os 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-não-suficientes. O que estou atualizando é minha própria suposição padrão de que “se está no system prompt, sustenta-se”. O artigo não testa essa suposição; ele testa questões adjacentes e reporta pontuações que me fazem querer segurar minha própria suposição de forma mais frouxa do que ontem.

Encurte sessões deliberadamente. A observação folclórica é que os agentes pioram ao longo de 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 aterrissando sem recuperação) é uma explicação alternativa candidata para esse folclore. A regra operacional que estou adotando: quando uma sessão está derivando, não lute contra ela com mais correção explícita — /new a 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 esteja sendo a causa real.

Trate inibição como difícil de impor no prompt. Se você precisa que seu agente não faça algo, não dependa de ter dito a ele para não fazer. Construa uma guarda estrutural — um linter, um pre-tool hook, uma política de sandbox, uma ferramenta que recuse a chamada — que imponha a proibição na camada de código. Meu argumento do quality loop do Jiro tem sido que gates rígidos precisam ficar fora do modelo por uma razão; eu já mantinha essa posição antes deste artigo. O ImplicitMemBench acrescenta 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 quero afirmar exageradamente que ele prova a posição.

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

Registre disposição de primeira tentativa, não apenas disposição final. Se você está executando qualquer tipo de captura de trajetória contra suas skills, separe “o que o agente tentou primeiro” de “o que o agente chegou depois da 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 primeira tentativa mede o que o agente realmente produziu antes do feedback externo. Para qualquer quality loop em que a experiência do usuário depende da primeira resposta estar correta, 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 entre os resultados do benchmark e o comportamento de produção em harness de agente é minha extensão, rotulada como tal ao longo do texto, e não é um achado do artigo.

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

O abstract descreve a assimetria como parte da análise dos autores sobre os resultados gerais do benchmark entre modelos, e a rotula como evidência de “gargalos universais”.¹ Leio isso como a assimetria aparecendo consistentemente entre os 17 modelos testados, com os números específicos refletindo o padrão agregado. O abstract 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 os benchmarks existentes?

Uma ressalva parcial aqui. O ImplicitMemBench em si usa um protocolo de múltiplas etapas (Learning/Priming-Interfere-Test),¹ então não é o caso de que este benchmark seja “single-shot” — não quero repetir a linha descuidada habitual sobre benchmarks. O que me parece — como especulação prática, não um achado do artigo — valer a pena sinalizar é que a maioria das outras avaliações de agentes que as pessoas olham mede tanto conclusão funcional de tarefas quanto recall explícito de fatos, e ambas favorecem 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 SOUL.md como o pin principal de identidade porque a memória declarativa explícita ainda é fundamental para o que ela faz bem: recall consistente de identidade, controle de versão auditável, comportamento previsível sob questionamento direto. O que o guia do Hermes não cobriu — porque nada existia para medir isso até este artigo aparecer — é 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.

Prompt engineering pode consertar algo disso?

A resposta honesta é que o artigo não testa prompting como estratégia de mitigação, então não posso te dizer com autoridade do artigo. O que posso dizer: os autores enquadram a lacuna como “exigindo inovações arquiteturais além do escalonamento de parâmetros”,¹ o que é uma afirmação mais forte que “prompts melhores vão ajudar” mas não é exatamente “nenhum prompt pode ajudar”. Especificamente para o lado da inibição (17,6% agregado), minha intuição como praticante — que você deve desvalorizar 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.

Isso é um daqueles artigos de “benchmark de memória” que venho vendo muito recentemente?

Não, e o artigo se distingue explicitamente deles. O enquadramento do abstract é que os benchmarks de memória existentes avaliam recall explícito de fatos — dá um fato ao modelo, pede ao modelo para recuperá-lo. O ImplicitMemBench está medindo algo inteiramente diferente: adaptação de comportamento automática sem qualquer passo de recuperação.¹ Essa é a contribuição do artigo e a razão pela qual foi aceito na ACL 2026 Main Conference.¹

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

Este post é um companheiro direto para Static Skills Are Dead Skills. Aquele post anterior argumentava que skills precisam de agregação de trajetória para permanecerem vivas, e eu assumia que o modo de falha era pura ausência — se você apenas conseguisse os dados de trajetória e rodasse um detector de padrões, estaria bem. O ImplicitMemBench está me dizendo que há um segundo modo de falha sobreposto: mesmo com atualizações de skill perfeitamente orientadas por trajetória, o comportamento de primeira tentativa pode não refletir a atualização porque a atualização aterrissou na memória explícita e as decisões estão sendo impulsionadas pela memória implícita. O post anterior ainda está correto sobre o que afirmava; este post é uma atualização sobre o que ele não sabia que precisava afirmar.

Isso poderia ser um artefato de medição?

Possivelmente. O artigo é novo — submetido em 9 de abril de 2026, aceito na ACL 2026 Main Conference — e benchmarks individuais 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 é só um artefato é que o modo de falha que ele descreve — agentes reforçando rapidamente preferências enquanto falham em desaprender falhas — é folclore que venho observando sem um nome para isso há mais de um ano. O benchmark não precisa estar perfeitamente calibrado para que a direção do resultado seja a coisa sobre a qual os praticantes deveriam agir.

Referências