Quem usa mais de um agente de código no dia a dia — Claude Code numa tarefa, Cursor em outra, às vezes Copilot CLI — já sentiu o mesmo problema: cada ferramenta começa do zero. As decisões de arquitetura discutidas ontem à tarde no Claude Code não existem pro Cursor hoje de manhã. O Engrim tenta resolver exatamente isso, e depois de ler o código-fonte e a documentação técnica do projeto (não só o README de apresentação), o que ele faz é mais específico do que “dar memória pra CLIs” — é memória compartilhada entre agentes diferentes, no mesmo projeto, sem depender de nenhum deles em particular.
O que o projeto realmente guarda, e como busca
Na versão atual (1.4.11, conferida direto no código-fonte), o Engrim mantém um arquivo SQLite único em ~/.engrim/memory.db, em modo WAL, com duas camadas de busca rodando juntas: índice textual via FTS5 (busca por palavra-chave, com stemmer) e embeddings vetoriais gerados pelo modelo model2vec:minishlab/potion-base-8M — um modelo de embedding estático, leve o suficiente pra rodar local sem GPU. A busca combina as duas (bm25 + cosseno vetorial) pra decidir o que é relevante recuperar. Isso é mais sofisticado do que “salvar mensagem, recuperar histórico” — é um sistema de recuperação híbrida rodando inteiramente na máquina do usuário.
Na prática, a proposta central do projeto é limitar o que entra no contexto do agente a cerca de 4.000 caracteres de memória “curada” por sessão, em vez de reenviar o histórico bruto inteiro a cada turno. A lógica declarada no próprio README é direta: reenviar 150 mil tokens de contexto acumulado a cada mensagem dilui a atenção do modelo e custa caro, então vale mais recuperar só o que é relevante pro momento.
Integração: não é biblioteca genérica, é hook específico por agente
O post original sobre o Engrim descrevia a integração como “abstrair operações SQL”. Olhando o código em src/engrim/hosts/, a realidade é mais granular: existe um adaptador dedicado por ambiente — Claude Code, Cursor, Codex CLI, GitHub Copilot CLI, OpenCode e Google Antigravity —, cada um com seus próprios hooks de ciclo de vida. Pro Claude Code especificamente, o comando engrim setup --claude configura os hooks SessionStart, SessionEnd, Stop e UserPromptSubmit dentro do ~/.claude/settings.json, mais uma linha de status ambiente e notas anexadas ao CLAUDE.md do projeto. Não é uma API que o desenvolvedor chama manualmente — é configuração automática de hooks que já existem na própria ferramenta host.
Isso explica por que o projeto lista compatibilidade com seis ambientes diferentes: cada um tem um mecanismo de hook próprio (Claude Code e Codex usam hooks nativos de sessão; Cursor e Windsurf dependem de MCP via engrim serve --mcp; OpenCode usa um plugin). O ponto comum entre todos é o mesmo arquivo SQLite local — trocar de agente no meio de um projeto não perde o que foi decidido antes.
O comando que mais diz sobre maturidade do projeto
Tem um comando, engrim doctor, que audita a própria instalação: verifica integridade do banco (PRAGMA integrity_check), confere se os hooks de cada ambiente configurado ainda apontam pro caminho certo do binário, e reporta quantas memórias estão ativas e quantas foram indexadas com embedding. O próprio README inclui um exemplo de saída real desse diagnóstico, mostrando 956 memórias ativas de 1.057 totais num projeto de exemplo, com breakdown por tipo (decisão, fato, feedback, referência, estado). Ferramenta que se preocupa em ter um comando de diagnóstico e self-healing de hooks quebrados (o README menciona fallback de PATH pra quando o binário muda de lugar entre máquinas) geralmente não é projeto de fim de semana — é algo que já bateu em problema real de produção e foi corrigido.
O que não dá pra confirmar sem instalar
Preciso ser direto aqui: não cheguei a instalar e rodar o pacote (pip install engrim) pra testar o fluxo completo — a política de segurança do ambiente onde escrevo bloqueia instalar pacotes de terceiros direto via pip sem revisão. O que dá pra afirmar com confiança é o que está verificável no próprio repositório público: a arquitetura de armazenamento, os hooks configurados por ambiente, a versão publicada, e os trade-offs que o autor documenta abertamente — inclusive o ponto de atenção real, que é sincronização entre máquinas diferentes. Como o banco é local por design, usar o Engrim em dois computadores significa dois arquivos memory.db separados, sem sync automático, a não ser que o usuário resolva isso por conta própria com alguma ferramenta externa.
Pra quem já roda mais de um agente de código no mesmo projeto e sente o efeito de “explicar tudo de novo” a cada troca, vale olhar o repositório com atenção antes de instalar — principalmente a seção de segurança do projeto, dado que ele grava decisões de arquitetura e possivelmente informação sensível de projeto num arquivo local.
