Seu próximo agente de código não deveria começar do zero

A coisa mais cara na hora de trocar de agente de código não é a assinatura. É a hora que você passa explicando o projeto de novo.

Quais arquivos importam, qual abordagem já falhou, por que os testes estão estruturados daquele jeito, o que o branch pela metade está fazendo. O Claude Code não sabe nada disso. Nem o Codex, o Cursor ou o Gemini CLI. Cada um começa com uma janela de contexto vazia e boa vontade educada de ajudar.

ai-memory é um binário em Rust que tenta resolver isso, e as escolhas de design dele são mais interessantes que a lista de recursos.

Uma memória, muitos harnesses

A proposta é que uns vinte harnesses de agente — Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok, Devin, Kimi, Kiro e o resto — leiam de um único armazenamento de memória compartilhado. Você trabalha em um, para no meio da tarefa, abre outro no mesmo diretório, e ele continua de onde o primeiro parou.

O mecanismo é um handoff tipado. Não um resumo que o agente gera e torce para estar certo, mas um registro explícito com um dono que só pode ser reivindicado uma vez. Essa restrição é a parte útil: dois agentes não podem achar que estão os dois continuando o trabalho, e um handoff abandonado fica visível em vez de se perder em silêncio.

Também existe uma camada que atravessa projetos. Suas preferências de trabalho — gerenciador de pacotes, como os testes estão organizados, como você gosta de estruturar os módulos — acompanham você em repositórios novos, então um checkout recém-clonado não começa do zero naquilo que vale em qualquer lugar.

Markdown como fonte da verdade

Aqui está a decisão de design que vale a pena discutir.

Sistemas de memória para agentes normalmente querem dizer embeddings. Você fatia o histórico, gera os embeddings, guarda num banco vetorial, recupera por similaridade. Funciona, e tem três problemas: você não consegue ler, não consegue fazer diff, e a recuperação é opaca o bastante para que, quando volta a coisa errada, você não faça ideia do porquê.

O ai-memory inverte isso. A fonte da verdade é um wiki em Markdown puro, versionado com git. O índice SQLite — busca em texto completo, entidades, embeddings — é derivado e reconstruível. Apague o banco e você não perde nada.

Essa única escolha rende muito. Você pode dar grep no wiki. Pode abrir no Obsidian. Pode corrigir à mão uma entrada errada. Pode sincronizar com rsync. Pode ler um diff e ver que o entendimento do agente sobre a sua arquitetura mudou na terça. E não existe vector store nenhum para te prender.

Também significa que a memória é auditável de um jeito que importa para times. «Por que o agente acha que a gente usa pnpm» é uma pergunta cuja resposta é um arquivo.

Envelhecer sem apagar

O projeto descreve um sistema de envelhecimento de memória: decaimento por níveis, retenção ponderada por acesso, deduplicação e sinalização de contradições. Notas que não são usadas caem de prioridade sem desaparecer, e entradas conflitantes são marcadas em vez de sobrescritas sem aviso.

O detalhe importante é que nada é apagado de verdade. As páginas antigas continuam no git, e um comando de restore traz elas de volta. Considerando quantas vezes a nota «desatualizada» de um agente acaba sendo o único registro de por que uma decisão foi tomada, esse é o padrão certo.

Existe um recurso opcional chamado dreaming, que usa um LLM para reescrever grupos de notas frias durante o tempo ocioso. Vem desligado, e o README diz explicitamente que nunca apaga o material de origem. Vir desligado por padrão é a decisão correta para qualquer coisa que reescreva suas notas com um modelo.

A instalação é realmente curta

Dois comandos no Linux ou macOS: um instalador de curl para shell que verifica um checksum SHA-256, e depois ai-memory setup, que cria o diretório de dados, sobe um serviço no nível de usuário e conecta os agentes que encontrar. Existe um equivalente em PowerShell para Windows, além de AUR, RPM, Nix, Docker e entradas no marketplace de plugins para Claude Code e Codex.

O uso diário gira em torno de um wrapper: ai-memory run claude em vez de claude. Ele instala os hooks e o servidor MCP certos na primeira execução e limita a sessão ao projeto atual. A partir daí, ai-memory continue retoma o último checkout gerenciado, e resume --search auth escolhe pelo nome entre os seus workflows.

Há um comando bootstrap que importa o histórico existente do projeto de uma vez só, que é a diferença entre uma ferramenta que você adota e uma que você vive pensando em adotar.

As partes desconfortáveis

Captura silenciosa via hooks de ciclo de vida significa que o sistema registra prompts, chamadas de ferramentas e limites de sessão enquanto você trabalha. É o único jeito de isso funcionar — você não vai escrever um diário à mão —, mas vale ser franco sobre isso. Um registro de cada prompt que você digitou em cima do código de um cliente é material sensível, e agora ele está num diretório versionado com git.

As mitigações são razoáveis: por padrão ele escuta só em loopback, e o setup gera um bearer token escrito num arquivo que só o dono lê, não na configuração do seu agente. Mas o quickstart do Docker roda sem autenticação, e o README sinaliza que é só para uso local. Se você expuser essa porta sem um proxy reverso com TLS, publicou o seu histórico de trabalho.

A parte de times está mais madura do que eu esperava para um projeto tão novo: servidor compartilhado, compartilhamento por projeto, handoffs privados, autenticação multiusuário, atribuição e log de auditoria, tudo fora do plano pago. É esse conjunto de recursos que decide se isso sobrevive ao contato com uma organização de engenharia de verdade.

Se você não quer rodar um servidor

Objeção justa: «meu próprio servidor» é uma frase que perde metade da audiência na hora.

Não precisa ser um servidor. O comando de setup sobe um serviço no nível de usuário na mesma máquina, preso ao loopback, e esse é o caminho padrão — sem homelab, sem VPS, sem DNS. Os recursos entre máquinas e para times só importam quando você quiser, e dá para separar eles do loop principal.

Também tem um app de barra de menu para macOS construído a partir do repo, e uma visão web somente leitura caso você prefira navegar pelo wiki no navegador em vez do editor. O caminho via Docker existe principalmente para quem já pensa em contêineres.

Então a escada de adoção honesta é: instale no seu notebook, deixe capturar um projeto e veja se o wiki que sai dali é algo que você realmente leria. Se for, o resto vem. Se o wiki for ruído, nenhum recurso de time vai salvar.

Por que isso importa mais do que parece

O mercado de agentes hoje está organizado em torno dos fornecedores, e fornecedor nenhum tem incentivo para facilitar a sua saída. O seu contexto é o lock-in. É por isso que o custo de trocar parece maior do que o preço da assinatura sugere.

Uma ferramenta que fica embaixo de todas elas e guarda a memória num formato que é seu é um pequeno ato de padronização do lado do usuário. Se o ai-memory vai ser o vencedor é quase irrelevante: o formato da solução — texto puro portátil com um índice reconstruível — é obviamente o certo, e é com esse formato que todo recurso proprietário de memória vai ter que competir mais cedo ou mais tarde.

Além disso, é um binário único e não exige API key para o loop principal. Isso é raro numa categoria em que «memória» costuma significar «mais uma assinatura».