Três Padrões de Memória que Funcionam (e Dois que Não)

Tim Kellogg constrói sistemas de agentes em produção há tempo suficiente para ser exigente sobre o que funciona. É autor do dura, o daemon de auto-commit Git com 4,4 mil estrelas no GitHub. Quando ele escreve uma taxonomia de padrões de memória de agentes, a taxonomia é empírica, não teórica. O texto Agent Memory Patterns é o catálogo mais limpo que vi do que se sustenta em produção e do que não se sustenta.

Três padrões funcionam. Dois não funcionam. E um único número — 500 caracteres — é o detalhe operacionalmente mais útil do post para qualquer time desenhando a camada de governança.

Os Três que Funcionam

Arquivos. Stores hierárquicos chave-valor para dados e conhecimento. O agente navega com as ferramentas esperadas: ls, find, cat, escrita. O substrato literal é irrelevante — arquivos planos em disco, registros de banco, blobs no S3. O que importa é que a estrutura é hierárquica e o padrão de acesso é exploração.

Arquivos são o padrão certo quando o dado é grande ou variado demais para morar inline, e quando o agente precisa descobrir o que existe antes de ler. As ferramentas de exploração não são opcionais. Se o agente vai direto a caminhos específicos sem listar ou buscar, você construiu um sistema de arquivos sendo usado como agenda hard-coded. Referenciamento aleatório de arquivos é sintoma de que as ferramentas de navegação estão subutilizadas — ou seja, o desenho não está realmente usando o padrão Arquivos.

Blocos de Memória. Um store chave-valor plano, incluído inline no prompt do sistema ou do usuário. O framework Letta popularizou a implementação: WriteBlock(), ListBlocks(), ReadBlock(). A propriedade definidora é a visibilidade: o conteúdo de um bloco de memória está garantidamente na janela de contexto do modelo no turno. Não há etapa de recuperação que possa falhar. O agente vê, ponto.

Essa garantia é o ponto inteiro. Blocos de memória servem para comportamento, preferências, identidade — o conjunto pequeno de fatos que precisa moldar todo turno. “Sempre responda em português brasileiro.” “O usuário prefere feedback de revisão de código direto e curto.” “Esta conta é somente leitura.” Se o dado precisa estar diante do modelo toda vez, ele vai num bloco.

Skills. Estruturas baseadas em diretórios que combinam arquivos com uma representação no prompt do sistema. A ferramenta Skill do Claude Code é a implementação de referência: um arquivo SKILL.md de metadados com nome e descrição mora no prompt do sistema; o resto do diretório carrega apenas quando a descrição corresponde à situação. Disclosure progressivo é o princípio arquitetural. A maior parte do dado é invisível na maior parte do tempo. O metadado é o que dispara o carregamento contextual.

Skills são o padrão certo quando há um corpo de instruções ou dados que se aplica em circunstâncias específicas e seria desperdício — ou ativamente confuso — incluir em todo turno. A descrição de gatilho é a superfície de design. Se for vaga demais, a skill carrega quando não deveria. Se for específica demais, a skill nunca carrega quando deveria.

Os Dois que Não Funcionam

Knowledge graphs. Parecem elegantes no quadro branco. Não funcionam em produção. A observação empírica de Kellogg é que LLMs não raciocinam bem em espaço de tokens sobre estruturas de grafo, e a indireção entre “o modelo diz que percorreu o grafo” e “o que o grafo de fato diz” é onde as falhas moram. O modelo alucina arestas. Interpreta mal tipos de nó. O grafo é internamente consistente e o comportamento do agente, não.

Modelos de dados em SQL com escrita. Mesma causa raiz. O agente emite uma query, o banco responde com um resultado tabular, e o raciocínio do agente sobre esse tabular é uma operação em espaço de tokens em que o modelo não é arquiteturalmente bom. Leituras às vezes são salváveis. Escritas são onde tudo desanda — o agente grava uma linha que viola uma invariante que ninguém contou, e o modelo de dados está envenenado. O veredicto de Kellogg é direto: esses padrões “tendem a não funcionar muito bem”.

Essa é a parte do post que vale citar na próxima revisão de arquitetura. Dois padrões que parecem engenharia de primeira classe — um knowledge graph, um banco com escrita — falham empiricamente quando o consumidor é um agente. Os times que entregam esse tipo de memória em produção, em geral, não fizeram a escolha de propósito. Pegaram o padrão porque era familiar de sistemas voltados a humanos. O agente é um consumidor diferente.

O Limiar dos 500 Caracteres

A frase mais útil do texto de Kellogg é o modo de falha dos blocos de memória. Acima de aproximadamente 500 caracteres, blocos “tendem a confundir o agente”. Isso não é preferência estilística. É restrição operacional.

500 caracteres também é uma fronteira de permissão, ainda que Kellogg não enquadre dessa forma. Um bloco de memória abaixo de 500 caracteres é pequeno o suficiente para um revisor humano ler de uma vez e decidir se deve existir. Um bloco de 480 caracteres dizendo “sempre escale transações financeiras acima de US$ 10 mil para revisor humano” é um artefato governável. Um bloco de 4.800 caracteres dizendo tudo que um agente possa precisar saber sobre as políticas de escalonamento da empresa não é — é um pequeno documento, e o modelo vai se confundir com ele.

A implicação arquitetural é limpa. No momento em que um bloco de memória cruza o limiar, ele deixa de ser um bloco. Deve ser um Arquivo (se o agente precisar navegar sob demanda) ou uma Skill (se precisar carregar automaticamente quando for relevante). O limiar não é um limite leve a ser empurrado. É sinal de que o padrão escolhido foi o errado.

Isso importa para governança porque o tamanho pequeno dos blocos de memória é o que os torna revisáveis. Tudo que precisa estar garantidamente visível para o agente também precisa ser pequeno o suficiente para um humano governar. O teto de 500 caracteres impõe as duas propriedades ao mesmo tempo.

Escolha pelo Que o Dado Serve

O ponto arquitetural que sai da taxonomia de Kellogg não é “use os três”. É: escolha o padrão pelo que o dado serve, e deixe os modos de falha do padrão indicarem quando a escolha foi errada.

Arquivos quando o agente precisa explorar. Viés a detectar: caminhos hard-coded em vez de chamadas a ls e find.
Blocos de Memória quando o comportamento precisa estar garantidamente visível. Viés a detectar: blocos que crescem além de 500 caracteres porque ninguém quis refatorar.
Skills quando disclosure progressivo importa. Viés a detectar: descrições de gatilho vagas que carregam a skill errada na hora errada.

E os padrões a descartar: knowledge graphs e bancos SQL com escrita. Parecem boa engenharia. Não são, quando o consumidor é um LLM.

A razão para tratar essa taxonomia como checklist é que os modos de falha agora são empíricos. Não estamos mais especulando se uma memória apoiada em grafo vai funcionar. Times em produção tentaram, e não funciona. Não estamos mais especulando qual o tamanho ideal de um bloco de memória. O número é 500. Os times que internalizarem essas restrições cedo vão passar o próximo ano construindo arquiteturas de memória que se sustentam. Os que não internalizarem vão passar o ano descobrindo, de forma cara, por que o grafo elegante deles nunca convergiu.

Fontes

Agent Memory Patterns — Tim Kellogg, abril de 2026.

A Victorino ajuda times de engenharia a escolher a arquitetura de memória de agentes que se sustenta em produção — e a descartar os padrões que falham empiricamente: contato@victorino.com.br | www.victorino.com.br