ai-memory: O Sistema de Memória Open-Source do Akita que Resolve o Problema que Todo Agente de IA Tem

Memória é o calcanhar de Aquiles de todo agente de IA. Você passa 40 minutos explicando o contexto do projeto, o agente resolve o problema, a sessão acaba — e na próxima conversa ele não lembra de nada. Eu senti isso na pele por meses. Até que o Fabio Akita publicou o ai-memory: um sistema de memória open-source construído do zero para substituir o agentmemory — o projeto anterior que ele mesmo usava e que quebrou em produção. Testei por dias, integrei no meu agente Allos e já está rodando em produção. O que aprendi nesse processo muda como penso sobre agentes de IA de longa duração.

O que é o ai-memory e por que o Akita reconstruiu tudo do zero

O ai-memory é um processo sidecar que roda junto com seu coding agent e se comunica via MCP (Model Context Protocol). Ele captura toda interação do agente — tool calls, outputs, observações — e consolida esse conteúdo em notas estruturadas que persistem entre sessões. Pensa nele como um "caderno de anotações automático" que o agente consulta antes de começar a trabalhar.

O Akita não construiu isso por esporte. Ele usava o agentmemory — o projeto anterior com a mesma fundação conceitual (Karpathy's LLM Wiki, consolidação em tiers, hooks MCP) — e encontrou bugs graves em produção: 47% dos hooks de tool call falhavam porque liam o campo errado (tool_output vs tool_response), havia uma janela de 5 segundos onde dados podiam ser perdidos, e após ~10K observações o rebuild do índice BM25 levava 5 minutos no restart.

A reconstrução trocou três decisões fundamentais: (1) PocketBase (Go/SQLite) como camada de persistência em vez de KV stores customizadas — eliminando o problema do rebuild de índice; (2) hooks corrigidos que leem os campos certos do protocolo MCP; (3) Docker Compose como deploy padrão, resolvendo o inferno de dependências entre plataformas. O projeto está no GitHub em github.com/akitaonrails/ai-memory e o Akita detalhou toda a arquitetura no artigo Criei um Sistema de Memória para Agentes de Código AI.

Os 3 tiers de consolidação: como a memória evolui com o tempo

O coração do ai-memory é o pipeline de consolidação em três tiers. Não é só um log de tool calls — é um sistema que destila conhecimento progressivamente:

Tier 1 — Observações brutas: o agente registra cada descoberta conforme trabalha — "a função de auth está em src/middleware/auth.ts", "o bug era uma comparação com < em vez de <=", "o deploy usa Vercel com ISR de 60s". São notas atômicas, sem estrutura rígida.

Tier 2 — Consolidação: um LLM de consolidação (o Akita recomenda Claude Haiku ou GLM 4.7 Flash local via Ollama — barato e rápido) varre as observações brutas periodicamente e mergeia notas relacionadas. "Middleware de auth em src/middleware/auth.ts" + "JWT expira em 7 dias" + "Refresh token no cookie httpOnly" viram uma entrada consolidada sobre o sistema de autenticação.

Tier 3 — Cross-session merge: quando você inicia uma nova sessão, o agente consulta as entradas consolidadas e o LLM de consolidação pode mergear conhecimento de sessões anteriores em entradas ainda mais maduras. É aqui que a mágica acontece: o agente não só lembra o que foi feito na última sessão, mas entende o contexto acumulado de semanas de trabalho.

Esse modelo de três tiers espelha como um dev humano manteria documentação de projeto: notas rápidas → resumo estruturado → wiki consolidada. A diferença é que o ai-memory faz isso automaticamente, em background, enquanto o agente trabalha.

Stack e deploy: PocketBase, Docker e 3 comandos

A stack é minimalista e pragmática. O ai-memory roda sobre PocketBase (um backend Go com SQLite embutido — zero dependência externa de banco) e um servidor Node.js que implementa o protocolo MCP. Tudo sobe com Docker Compose:

ai-memory init — inicializa o projeto com a configuração base. ai-memory start — sobe o PocketBase + servidor MCP. ai-memory stop — desliga tudo. São três comandos e o sistema está rodando.

O LLM de consolidação é configurável — use o que fizer sentido para seu bolso. O Akita recomenda Claude Haiku (barato, rápido, qualidade consistente) ou GLM 4.7 Flash rodando local via Ollama (custo zero). Para o agente principal, qualquer modelo funciona — ele só lê e escreve texto via ferramentas MCP, então não precisa de um Opus 4.7 só para anotar descobertas.

O Akita é transparente sobre o estado do projeto: "beta, falta usuário". Ele está usando nos próprios projetos e quer feedback da comunidade. Para um sistema que resolve um problema tão fundamental, o fato de ser beta com código aberto é um convite, não um alerta.

Allos + ai-memory: memória permanente no meu agente de IA

Eu testo ferramentas de coding agent em produção. Meu agente Allos — um agente de IA que roda tarefas complexas de desenvolvimento — já está usando o ai-memory como camada de persistência. E o ganho é real: o Allos agora acorda sabendo o que fez na sessão anterior. Não preciso re-explicar a arquitetura do projeto, as decisões de design, os bugs que já foram investigados.

O fluxo é simples: o Allos começa uma sessão → consulta o ai-memory via MCP → recebe o contexto consolidado das sessões anteriores (decisões de arquitetura, bugs conhecidos, padrões do projeto) → trabalha com contexto completo → registra novas observações → o ciclo de consolidação roda em background. Na próxima sessão, o conhecimento acumulado está lá.

Nas próximas atualizações do Allos, o ai-memory será integrado como módulo nativo — não como experimento, mas como fundação. A ideia é que todo usuário do Allos tenha uma memória permanente super potente desde o primeiro comando, sem configurar nada. O ai-memory resolve o "cold start" de contexto que atormenta agentes de IA desde o dia 1.

Como o ai-memory se compara com outras abordagens de memória para agentes

O mercado de "memória para agentes" tem três abordagens principais e o ai-memory ocupa um nicho específico:

Bancos vetoriais (Chroma, Pinecone, pgvector): embebem tudo em vetores e fazem busca por similaridade. Funciona para "encontre algo parecido com X", mas perde a estrutura hierárquica do conhecimento. Um agente não precisa de similaridade de cosseno — precisa saber que "o middleware de auth está em src/middleware/auth.ts e usa JWT com expiração de 7 dias".

Memória como sistema de arquivos (Claude Code Managed Agents): a abordagem mais simples e que funciona surpreendentemente bem — agentes escrevem notas em arquivos Markdown. Mas não tem consolidação automática, não tem deduplicação, não tem merge cross-session. O ai-memory pega essa mesma intuição (notas estruturadas) e automatiza o pipeline de manutenção.

Memória via fine-tuning: alguns projetos treinam o modelo nos dados do projeto. Isso é caro, lento e o conhecimento fica congelado no peso do modelo — não atualiza conforme o código evolui. O ai-memory mantém o conhecimento como dados vivos, não como pesos neurais.

O ai-memory acerta ao não tentar ser "inteligente demais". É um sistema de notas com consolidação progressiva — e isso é exatamente o que agentes de código precisam. Se você já usou o CodeGraph para pré-indexar sua codebase, o ai-memory é o complemento natural: o CodeGraph mapeia a estrutura do código, o ai-memory mantém o conhecimento sobre o código.

Por que isso importa para devs que usam agentes de IA

Na minha visão, o ai-memory ataca três dores que todo dev que usa coding agent sente:

(1) Custo de recontexto. Toda sessão nova, você gasta de 10 a 30 minutos re-explicando o projeto para o agente. Isso queima créditos e paciência. Com memória persistente, o agente já chega sabendo. O ROI é imediato.

(2) Handoff entre agentes. Você usa Claude Code para arquitetura e outro agente para testes? Com o ai-memory, ambos leem o mesmo conhecimento consolidado. O agente de teste sabe o que o agente de arquitetura decidiu — sem você fazer a ponte manualmente.

(3) Acumulação de conhecimento institucional. Depois de 30 sessões com o mesmo projeto, o ai-memory tem um wiki que vale ouro: bugs conhecidos e suas soluções, padrões de código do projeto, decisões de arquitetura com seu contexto original, edge cases documentados. Isso é conhecimento que normalmente morre no transcript de cada sessão.

Se você já usou o Agent Pi como alternativa open-source ao Claude Code, o ai-memory é o próximo passo lógico — transforma um agente customizado em um agente com memória de longo prazo.

Conclusão

O ai-memory resolve o problema mais negligenciado dos agentes de IA: memória que funciona na prática, não só no paper. O Akita aprendeu com os bugs do agentmemory, reconstruiu com escolhas pragmáticas (PocketBase, Docker, MCP) e entregou um sistema que eu já estou usando em produção no Allos. Nas próximas atualizações do Allos, o ai-memory será integrado nativamente — dando a cada usuário uma memória permanente super potente sem configuração adicional.

Se você usa coding agents diariamente, pare de dormir com transcripts e comece a construir memória. O código está no GitHub em github.com/akitaonrails/ai-memory e o artigo completo do Akita com a arquitetura detalhada está em akitaonrails.com. Se testar, me conta nos comentários — quero saber se mais alguém está cansado de explicar o mesmo projeto para agente todo santo dia.