Tenho construído um agente de trabalho autônomo — um sistema onde o LLM decide o que fazer, e scripts, agendadores e bancos de dados são ferramentas que ele aciona conforme necessário. O design não foi planejado de antemão. Ele emergiu ao longo de várias semanas de construção em rodadas com o Claude Code, partindo de um agente anterior que era basicamente scripts bash e uma constelação de arquivos markdown alimentando a janela de contexto. Cada rodada revelava uma nova limitação, e cada limitação apontava para a mesma causa raiz: memória.

Autoavaliação precisa de memória de avaliações passadas. Iniciativa precisa de memória do que o operador ainda não viu. Aprendizado de valores precisa de memória de decisões e seus resultados. Nada disso funciona apenas com uma janela de contexto e um system prompt.

Terminei a implementação ontem, tarde da noite. Depois fui buscar referências sobre o estado atual da pesquisa em memória de agentes. Encontrei convergências com a literatura que me deram alguma confiança, pelo menos uma decisão que acredito ter acertado, e muitos caminhos abertos que não havia considerado. Preciso de semanas de uso real antes de tirar conclusões — mas os problemas são interessantes o suficiente para compartilhar agora.

Por que a memória se torna estrutural

A maioria dos sistemas com LLM segue um padrão: uma aplicação orquestra o modelo. O script decide o que fazer, o modelo executa. A memória nesse arranjo é curada — o orquestrador escolhe que contexto alimentar.

Quando você inverte isso — o modelo decide, os scripts servem — a memória se torna estrutural. O modelo precisa raciocinar sobre suas próprias necessidades de contexto: o que sabe, o que fez antes, o que funcionou, o que mudou. A memória deixa de ser um problema de recuperação ("encontrar o trecho relevante") e se torna um problema de infraestrutura ("manter o contexto operacional de uma entidade autônoma").

O framework CoALA (Sumers et al., 2024) formaliza isso como uma arquitetura cognitiva para agentes de linguagem, distinguindo memória de trabalho, memória episódica, memória semântica e memória procedural. Cheguei a cada uma dessas categorias empiricamente — porque o sistema quebrava de formas específicas quando qualquer uma estava ausente. Encontrar a taxonomia formal depois foi reconfortante.

Logs de sessão como matéria-prima

O Claude Code grava um arquivo JSONL por sessão — um evento estruturado por linha — com mensagens, chamadas de ferramentas, resultados, erros, uso de tokens. Append-only, em tempo real. A maioria dos usuários nunca olha para eles.

Construí um daemon que monitora esses arquivos com fswatch e parseia cada evento conforme chega: decisões, chamadas de ferramentas, resultados, erros. Ele alimenta um grafo de conhecimento temporal e mantém um estado agregado do portfólio entre projetos. A janela de contexto dentro de uma sessão lida com memória de curto prazo através de compressão e sumarização. Mas entre sessões, esse contexto de conversa desaparece. O daemon preenche essa lacuna — processando tudo que aconteceu, para que a próxima sessão comece com estado operacional rico refletindo todo o trabalho anterior.

Vários projetos open-source surgiram em torno desse formato JSONL — visualizadores de sessão, ferramentas de replay, APIs de monitoramento. Para construtores de agentes, os logs de sessão são os dados primários mais ricos disponíveis, e a maioria das arquiteturas os ignora completamente.

Grafos temporais vs. RAG estático

O RAG padrão trata memória como busca: embedar chunks, encontrar vizinhos, injetar no contexto. Funciona para recuperação factual, mas falha para o raciocínio que um agente autônomo realmente precisa.

Exemplo concreto: meu agente gerencia um portfólio de projetos — software, um livro, artigos. Eles compartilham conceitos, mas as conexões são estruturais e temporais. A tese do livro evoluiu quando o design do software foi refatorado. Um insight de negócios mudou o enquadramento do livro. O RAG estático recupera cada trecho independentemente; não consegue representar que esses convergiram durante um período específico, nem por quê.

Uso o Graphiti, um grafo de conhecimento temporal sobre FalkorDB. O grafo é bi-temporal: cada fato tem um valid_at (quando se tornou verdadeiro), um invalid_at (quando foi superado) e um created_at (quando o sistema o aprendeu). Fatos nunca são deletados — são invalidados. Linhagem completa preservada.

Isso possibilita consultas impossíveis com recuperação vetorial:

O tipo de aresta CONTRADICTS é particularmente interessante. Quando um novo fato contradiz um existente, ambos são preservados com um link explícito. O agente pode raciocinar sobre por que anteriormente acreditava em X e o que mudou. Isso é diferente de ter um motor de busca com boa cobertura.

Aprendendo com a memória, não apenas recuperando

A memória também se torna um substrato para aprender valores do operador.

Uso Thompson Sampling contextual — um algoritmo de aprendizado por reforço. Contexto: características do portfólio (prazos, momentum, tipo de projeto). Ações: o que priorizar. Recompensa: aprovação do operador (1) ou correção (0). Os pesos aprendidos codificam as preferências reais do operador, incluindo a lacuna entre preferências declaradas e reveladas.

A decisão arquitetural chave: a função de valor lê do mesmo grafo temporal que armazena todo o resto. Decisões, resultados, reações do operador — tudo entidades do grafo. Memória e aprendizado compartilham substrato, o que mantém ambos auditáveis.

Isso se conecta ao Memory-R1 (2025), que propõe gerenciamento de memória orientado a RL. Minha abordagem é adjacente mas distinta: RL aprende preferências a partir da memória, em vez de gerenciar a memória em si. Separar o substrato de memória da camada de aprendizado tornou ambos mais fáceis de raciocinar.

O que ainda está sem solução

Esquecimento seletivo

Meu grafo nunca esquece — cada fato preservado, possivelmente invalidado mas nunca deletado. Filosoficamente limpo, praticamente problemático conforme o grafo cresce. Nem todas as memórias têm o mesmo valor.

FadeMem (2025) propõe esquecimento bio-inspirado baseado nas curvas de Ebbinghaus — memórias decaem a menos que sejam reforçadas por acesso ou relevância. É convincente e bem fundamentado em ciência cognitiva. Ainda não implementei. A mitigação atual é grosseira: insights obsoletos expiram após sete dias. Adicionar dinâmicas de decaimento adequadas é o próximo passo mais claro para meu sistema.

Reconsolidação de memória

Distinto do esquecimento: atualizar memórias existentes quando novas informações chegam, em vez de adicionar novos fatos ao lado dos antigos.

A-Mem (2025) propõe memória com agência — capaz de se auto-organizar através de reconsolidação. Quando uma nova experiência chega, avalia se memórias existentes devem ser atualizadas, mescladas ou reestruturadas. Tenho uma versão rudimentar (arestas EVOLVED_INTO conectando fatos antigos a sucessores), mas a reconsolidação ainda não é automática. O desafio é custo: reconsolidação requer raciocínio do LLM sobre relações de memória, competindo com trabalho produtivo pelo orçamento de tokens. Na minha escala — operador único, assinatura fixa, sem GPU dedicada — estratégias como fine-tuning ou múltiplas chamadas de LLM para ponderação e agregação de sinais estão fora de alcance. A arquitetura tem que ser eficiente por design, não por força bruta de compute.

A tese local-first

Um padrão em comum entre minha implementação e o cenário de pesquisa: os sistemas de memória de agente mais capazes são local-first.

As razões práticas são óbvias: latência, privacidade, custo, auditabilidade. Mas a razão mais profunda é arquitetural. Um agente autônomo com memória local pode ser inspecionado em cada camada. O grafo é consultável. Os logs são legíveis. Os pesos da função de valor são um arquivo JSON. Não há caixa preta.

Quando o agente toma uma decisão surpreendente, posso rastrear a cadeia de memória que levou a ela — do evento JSONL à extração pelo daemon, da entidade do grafo ao peso da função de valor, da recomendação à decisão. Essa inspecionabilidade é pré-requisito para confiança. E confiança é o que limita quanta autonomia você pode conceder de forma responsável.

Conclusões práticas

Se você está construindo memória para agentes:

Comece pela ingestão, não pela recuperação. A memória mais rica vem dos seus próprios logs de sessão — estruturados, abrangentes, já existentes. A maioria das arquiteturas começa escolhendo um banco de dados vetorial. Comece parseando seus logs.

Metadados temporais não são opcionais. Cada fato precisa de valid_at e created_at no mínimo. Sem temporalidade, sua memória é uma fotografia se passando por história.

Separe o substrato de memória da camada de aprendizado. O grafo armazena fatos. A função de valor aprende a partir dos fatos. Manter esses distintos torna cada um independentemente auditável.

Torne a memória inspecionável. Se você não consegue explicar por que o agente tomou uma decisão rastreando sua memória, você não tem um agente — você tem um processo estocástico.

Terminei a implementação ontem. Os primeiros testes reais — memória de longo prazo, iniciativa, análise — virão de semanas de uso efetivo. Estou compartilhando agora porque os problemas são interessantes e o espaço está se movendo rápido.

Se você está trabalhando com memória temporal, aprendizado de valores ou esquecimento — gostaria de ouvir de você.