Quem já passou horas a fio com ferramentas como Claude Code, Codex CLI ou opencode certamente se deparou com a fatídica mensagem “context approaching limit” ou, pior, viu o agente "esquecer" decisões importantes tomadas poucas horas antes. Essa experiência, que beira o frustrante, levanta uma questão central: por que assistentes de IA tão poderosos em suas tarefas específicas parecem ter a memória de um peixinho dourado?
Este mergulho profundo explora como a memória desses agentes funciona, onde ela falha e as abordagens da comunidade de desenvolvedores para criar algo mais robusto — algo que se aproxime de uma memória de longo prazo de verdade. Para isso, examinei o código de ferramentas como o Codex (em Rust) e o opencode (em TypeScript), além de analisar o recente vazamento do Claude Code. Para fechar, testei o agentmemory, um servidor MCP de código aberto que promete atacar o problema de forma sistemática.
O Calcanhar de Aquiles das LLMs
Um modelo de linguagem (LLM) não possui memória persistente. O que ele "lembra" durante uma interação é, na verdade, apenas o conjunto de tokens que cabem em sua janela de contexto. Imagine essa janela como uma lousa mágica: tudo que é escrito nela (cada mensagem, arquivo, saída de comando, chamada de ferramenta) preenche esse espaço limitado. Ao interagir com Claude Code, Codex ou opencode, o agente monta incessantemente uma sequência de mensagens (que inclui o system prompt, o histórico da conversa, as ferramentas e suas saídas) e a envia integralmente para a API a cada turno.
Esse mecanismo gera dois efeitos imediatos. Primeiro, o desempenho do agente é proporcional à proximidade da informação relevante na janela de contexto. Ele performa melhor quando os dados importantes estão “frescos”, mas começa a patinar quando essa informação crucial fica soterrada sob um emaranhado de outputs de comandos como ls ou grep. O segundo efeito é financeiro: cada token enviado tem um custo associado, seja em dinheiro ou debitado da cota. Janelas de contexto maiores também implicam em maior latência. Modelos como o Opus 4.7 e o GPT 5.5 ostentam janelas de 1 milhão ou 5.5 milhões de tokens, respectivamente, mas "caber" não significa que seja ideal preenchê-la completamente. Uma janela mais cheia diminui a velocidade da inferência e aumenta o custo da requisição.
Por isso, praticamente todos os agentes implementam algum tipo de mecanismo de compactação. Quando a janela de contexto se aproxima do limite, o agente aciona uma chamada LLM adicional. Essa chamada resume a conversa até aquele ponto em um texto mais conciso. Concluído o resumo, o histórico bruto é descartado, e a sessão prossegue a partir dessa versão condensada. O benefício é inegável — mais espaço para o agente trabalhar —, mas o custo também é claro: a parte resumida, por sua própria natureza, perde detalhes importantes.
Vejamos como cada um dos principais agentes lida com essa dança entre o esquecimento e a necessidade de contexto.
O Codex CLI, um projeto de código aberto, permite-nos espiar “por debaixo do capô” em seu repositório no GitHub. A lógica de auto-compactação reside em codex-rs/core/src/session/turn.rs. Ela é ativada quando o uso de tokens atinge um limite pré-definido pelo modelo em questão.
let auto_compact_limit = model_info.auto_compact_token_limit().unwrap_or(i64::MAX); // ... a cada turno ... let total_usage_tokens = sess.get_total_token_usage().await; let token_limit_reached = total_usage_tokens >= auto_compact_limit; if token_limit_reached && ... (truncado se necessário)
O trecho de código acima, ainda que parcial, já nos dá uma ideia clara: o sistema verifica o total de tokens usados e, se ele ultrapassar o limite para a compactação, a mágica acontece. No caso do Codex, ele não apenas compacta, mas também se prepara para um “handoff” explícito, o que significa que o resumo é parte fundamental da continuidade da conversa. É uma abordagem direta, mas que ainda assim impõe perdas significativas.
O opencode e o Claude Code, apesar de terem diferentes origens e implementações, seguem um padrão similar na gestão de contexto. O opencode, escrito em TypeScript, utiliza uma estratégia de compactação que atua quando o contexto se aproxima perigosamente do limite. Segundo o código-fonte, ele tenta manter um “buffer” de tokens livres para novas interações. Uma função específica orquestra a sumarização do histórico, priorizando as informações mais recentes ou marcadas como relevantes.
Já o Claude Code, cuja estrutura pôde ser analisada a partir de vazamentos recentes, também em TypeScript, adota uma abordagem um pouco mais agressiva na compactação. Ele pode acionar a sumarização com maior frequência ou com limites de tokens mais rigorosos, dependendo da configuração do modelo ou do custo-benefício. A ideia é sacrificar um pouco da riqueza do detalhe em favor da agilidade e da viabilidade financeira das interações mais longas. Um dos trechos que exemplificam essa estratégia busca por uma “eficiência máxima” no uso dos tokens.
todos esses agentes enfrentam um dilema inerente à arquitetura dos LLMs: como manter a coerência e a relevância da conversa sem esbarrar nos limites de contexto e nos custos operacionais? A compactação é a resposta mais comum, mas é, por definição, uma solução paliativa.
O impacto da memória efêmera das LLMs vai muito além de uma simples inconveniência. Em cenários de programação e desenvolvimento, a capacidade de um agente de manter o contexto completo de um projeto, incluindo decisões de design, configurações complexas e requisitos detalhados, é fundamental. Quando o agente “esquece” partes importantes, o resultado pode ser um código incoerente, a repetição de erros já corrigidos ou a necessidade de intervenção humana constante para “lembrá-lo” de informações prévias.
Isso não apenas reduz a produtividade, mas também mina a confiança na ferramenta. De que adianta um assistente inteligente se ele precisa ser constantemente reorientado, como se estivesse em sua primeira interação, mesmo em um projeto que já dura horas ou dias? É como ter um co-programador que, a cada poucas horas, sofre de amnésia parcial — uma situação insustentável em qualquer equipe de desenvolvimento séria.
agentmemory: Uma Solução Para a Amnésia Digital?
Diante dos desafios impostos pela limitação de contexto, a comunidade de código aberto tem buscado soluções mais robustas. Uma delas é o agentmemory, um servidor MCP (Multi-Modal Context Proxy) que se propõe a ser uma camada de abstração para a memória de agentes de IA.
A ideia central por trás do agentmemory é criar um sistema de memória de longo prazo que não dependa exclusivamente da janela de contexto do LLM. Ele atua como um repositório externo, onde informações cruciais podem ser armazenadas, recuperadas e até processadas de forma mais persistente. Em vez de simplesmente compactar o contexto, o agentmemory organiza as informações de maneira semântica, permitindo que o agente recupere dados relevantes com base no que ele está fazendo ou discutindo no momento.
Durante meus testes, a promessa do agentmemory mostrou-se interessante. Ele permite que o agente “grave” e “recupere” fatos, decisões e até trechos de código de forma mais inteligente. O agente não precisa mais carregar todo o histórico em sua janela de contexto a cada turno. Em vez disso, ele consulta o servidor agentmemory, que retorna apenas as informações mais pertinentes. Isso tem o potencial de reduzir o volume de tokens enviados para a API e, consequentemente, diminuir custos e latência, além de melhorar a coerência das respostas do LLM ao longo do tempo. É um passo em direção a um assistente de IA que realmente “aprende” com a experiência, em vez de apenas processar informações instantâneas.
A busca por uma memória de longo prazo eficiente para agentes de IA é uma das fronteiras mais importantes da pesquisa em inteligência artificial hoje. Soluções como o agentmemory apontam para um caminho promissor, mas ainda há desafios significativos a serem superados. A complexidade de indexar e recuperar informações de forma eficiente em grandes volumes de dados, a garantia de que as informações recuperadas são de fato as mais relevantes e a integração transparente com diferentes arquiteturas de LLMs são apenas alguns deles.
A médio e longo prazo, é provável que vejamos uma combinação de abordagens: LLMs com janelas de contexto cada vez maiores, sim, mas também sistemas de memória externa mais sofisticados e que utilizem técnicas avançadas de recuperação de informação. A arquitetura para IAs exigirá uma compreensão profunda de como humanos e máquinas processam e armazenam informações. É uma jornada que promete transformar assistentes efêmeros em verdadeiros colaboradores digitais que não se esquecem de nada do que lhes foi dito. Mas enquanto isso não chega, a batalha contra o esquecimento dos agentes continua com soluções criativas da comunidade.