ai-memory: memória de longo prazo para agentes

Depois de olhar alguns posts do Akita, encontrei um texto sobre um projeto novo dele chamado ai-memory. A premissa me pareceu interessante logo de início: guardar o conhecimento produzido durante as sessões de um agente para que ele possa ser utilizado mais tarde.

Quem usa agentes de programação ou de automação provavelmente já percebeu o problema. A sessão começa, o agente passa um tempo entendendo o projeto, nós explicamos as decisões já tomadas e, depois de algum trabalho, ele finalmente consegue executar a tarefa. Quando a sessão termina, porém, boa parte desse contexto fica para trás. Na próxima conversa, é necessário começar quase tudo novamente.

O ai-memory tenta resolver justamente essa perda de contexto. Ele transforma as observações e as decisões das sessões em uma memória persistente que pode ser pesquisada depois. Assim, o agente não precisa depender apenas da janela de contexto da conversa atual ou de um resumo que alguém teve de escrever manualmente.

O problema de começar do zero

Uma sessão nova não conhece automaticamente o que aconteceu na sessão anterior. Mesmo quando o código está no mesmo repositório, existem informações que não aparecem apenas lendo os arquivos:

• uma abordagem que já foi testada e não funcionou;
• o motivo de uma decisão de arquitetura;
• um comando que precisa ser executado antes do build;
• um problema que ainda está aberto;
• uma restrição que não pode ser ignorada;
• a próxima etapa de uma atividade interrompida.

É possível colocar parte disso em um README, em um arquivo de instruções ou em um AGENTS.md. Esses arquivos continuam sendo importantes, principalmente para regras permanentes do projeto. Mas nem todo conhecimento produzido durante o trabalho merece virar documentação manual. Algumas informações são decisões de uma sessão, descobertas temporárias, tentativas que falharam ou detalhes que só serão úteis quando uma tarefa parecida voltar a aparecer.

Sem uma memória separada, esse conhecimento costuma desaparecer quando a conversa termina. Na sessão seguinte, o agente pode repetir uma investigação, sugerir novamente uma solução que já foi descartada ou simplesmente gastar seus primeiros minutos descobrindo o estado atual do projeto.

O que o ai-memory guarda

O ai-memory registra observações do ciclo de vida das sessões e compila esse material em páginas de conhecimento. A ideia não é guardar uma transcrição interminável de tudo o que foi dito, mas transformar o histórico em algo que possa ser consultado de maneira prática.

Dependendo do tipo de informação, a memória pode conter uma decisão, um conceito, um procedimento, uma regra ou um handoff. O handoff ajuda a passar o estado de uma atividade para a próxima sessão. Já uma página permanente pode registrar uma decisão ou um procedimento que continuará útil mesmo depois que aquela atividade específica terminar.

O projeto também trabalha com uma wiki em Markdown. Isso é importante para mim porque o conhecimento não fica preso em um formato proprietário ou em uma interface que eu não consigo inspecionar. Posso abrir os arquivos, pesquisar com ferramentas comuns, versionar as alterações e fazer backup junto com o restante da minha estrutura.

Na parte de busca, o projeto usa o conteúdo registrado para encontrar páginas relacionadas ao que estou fazendo. Em vez de entregar todo o histórico ao modelo, a sessão pode consultar apenas o que tem relação com a tarefa atual. Isso reduz o ruído e torna o contexto mais útil.

A vantagem aparece com o uso

No início, pode parecer que guardar esse conhecimento não faz tanta diferença. Afinal, ainda é preciso explicar a tarefa, revisar o resultado e acompanhar o agente. Uma única sessão também pode parecer simples o suficiente para que eu consiga repetir manualmente as informações importantes.

A vantagem aparece conforme o uso se acumula.

Quando preciso refazer determinada atividade, investigar um problema parecido ou voltar a um projeto depois de alguns dias, o ai-memory consegue recuperar o que já foi feito e como foi feito. O modelo recebe o contexto relevante e parte de um ponto muito mais avançado. Em vez de repetir toda a etapa de descoberta, ele pode consultar a memória, entender as decisões anteriores e seguir uma abordagem que já produziu o resultado esperado.

Isso não significa que o agente vai acertar tudo automaticamente. O código atual, os testes e o comportamento real do sistema continuam sendo a fonte de verdade. Uma anotação antiga pode estar desatualizada e uma solução que funcionou antes pode não ser apropriada agora. A memória ajuda a encontrar o caminho, mas ainda é necessário conferir se aquele caminho continua válido.

Mesmo com essa ressalva, a diferença é grande. Uma sessão que antes começaria com uma longa explicação pode começar com uma consulta objetiva: o que já foi decidido sobre esse componente? Qual tentativa falhou? Como o deploy desse projeto é feito? O que ficou pendente?

Contexto persistente não é a mesma coisa que contexto longo

Uma janela de contexto grande permite que o modelo veja mais conteúdo durante uma única conversa. Isso é útil, mas não resolve o problema do conhecimento entre sessões. Quando a conversa termina, o conteúdo ainda precisa ser levado para algum lugar se eu quiser reutilizá-lo depois.

O ai-memory trabalha em outra camada. Ele guarda o que vale a pena lembrar e recupera esse conhecimento quando necessário. Não é preciso manter uma conversa antiga inteira aberta para que uma decisão continue disponível.

Essa diferença se torna ainda mais importante dependendo do modelo ou do provider utilizado. Nem todos oferecem a mesma janela de contexto, e alguns modelos podem trabalhar com uma quantidade bem menor de tokens. Nesses casos, não faz sentido tentar carregar todo o histórico do projeto em cada sessão.

Posso encerrar uma conversa, abrir uma nova com a janela de contexto limpa e consultar o ai-memory para recuperar as decisões e os procedimentos relevantes. Em poucos segundos, o agente recebe uma base de conhecimento muito mais adequada para continuar o trabalho. O contexto deixa de depender do tamanho da conversa anterior.

Um fluxo que faz sentido para o dia a dia

O fluxo que imagino para o uso diário é simples:

1. Começo uma sessão e peço ao agente que entenda a tarefa.
2. Durante o trabalho, decisões, descobertas e problemas importantes são registrados.
3. Encerro a sessão sem precisar transformar tudo em documentação manual.
4. Mais tarde, começo uma nova sessão no mesmo projeto.
5. O agente consulta a memória antes de propor uma solução.
6. A atividade continua a partir do conhecimento já adquirido.

Isso também facilita trocar de agente, modelo ou provider. A memória fica associada ao projeto, não apenas à conversa com uma ferramenta específica. Se eu iniciar uma atividade em um agente e precisar continuá-la em outro, o histórico relevante pode acompanhar a mudança.

Para mim, esse é um dos pontos mais interessantes do projeto. O agente deixa de ser uma ferramenta isolada que só funciona bem enquanto a mesma conversa está aberta. Ele passa a participar de um fluxo de trabalho contínuo, no qual diferentes sessões podem consultar o mesmo conhecimento.

O que não deve ser salvo

Uma memória persistente precisa ser tratada com cuidado. Não devo registrar senhas, tokens, chaves privadas ou qualquer outro segredo. Também não é uma boa ideia transformar toda hipótese em uma regra permanente ou guardar uma informação sem conferir se ela realmente foi confirmada.

Outro cuidado é separar o conhecimento do projeto do que é uma preferência geral. Uma decisão específica de um repositório não deve aparecer como regra para todos os outros projetos. Da mesma forma, uma observação temporária não precisa ficar misturada com procedimentos que ainda são válidos meses depois.

Essa organização é importante porque uma memória ruim pode ser pior do que nenhuma memória. Se o agente encontrar informações antigas, duplicadas ou contraditórias e tratá-las como verdade absoluta, o contexto adicional pode aumentar os erros em vez de reduzi-los. A memória deve ser consultada como histórico útil, sempre conferida contra o estado atual do projeto.

Minha conclusão

Depois de conhecer o ai-memory, passei a ver de outra forma o problema da contextualização dos agentes. Antes eu pensava principalmente em fornecer instruções melhores no começo da conversa. Isso ainda é necessário, mas não resolve sozinho o que acontece depois que várias sessões acumulam decisões, tentativas e aprendizados.

A proposta do ai-memory é transformar esse conhecimento em uma memória operacional reutilizável. No início, a diferença pode parecer pequena. Conforme o agente é usado para repetir atividades, alternar entre projetos ou continuar trabalhos interrompidos, a vantagem fica mais clara: ele consegue entender o que já foi feito, descobrir como foi feito e reproduzir o resultado esperado com menos tempo gasto em contextualização.

Para quem utiliza modelos com uma janela de contexto menor, o ganho pode ser ainda maior. Posso abrir uma sessão nova, com o contexto limpo, recuperar o conhecimento relevante e ficar efetivo para o trabalho em poucos segundos.

O ai-memory não substitui revisão, testes ou julgamento técnico. Ele também não transforma um modelo ruim em um modelo excelente. Mas reduz uma das maiores perdas do trabalho com agentes: ter de ensinar novamente, a cada sessão, aquilo que o próprio projeto já aprendeu.