Por qué cambié de claude-mem a Engram en Claude Code

TL;DR: Hace dos días recomendé claude-mem como mejor opción de memoria persistente para Claude Code. Sigue siendo verdad para mucha gente. Pero en mi setup acabé migrando a Engram porque salto entre Claude Code, Codex y Gemini CLI varias veces a la semana, y necesitaba una capa de memoria que no estuviera atada a un solo agente. Aquí qué cambió, cómo decidí, y cuándo cada opción gana.

El contexto del cambio

Hace dos días publiqué una guía sobre memoria persistente en Claude Code donde recomendaba claude-mem como la opción más madura para uso individual. El argumento era sólido: hooks bien integrados, compresión progresiva en 3 capas, cero fricción si tu workflow vive dentro de Claude Code.

Lo importante no es qué dije entonces. Es qué cambió.

He estado trasteando con claude-mem y con Engram en paralelo, en el mismo proyecto, sobre los mismos archivos, para comparar honestamente. Y aunque claude-mem sigue siendo la opción más amigable para empezar, en mi día a día acabó perdiendo. La razón no es técnica en abstracto: es de workflow.

Lo que cambió en mi día a día

En las últimas semanas he ido moviendo cada vez más tareas fuera de Claude Code. Codex para revisiones cruzadas con GPT-5.5, Gemini CLI para tareas con contexto muy grande (1M tokens), Cursor para edits rápidos con autocomplete. Esto no es porque Claude Code me funcione peor: es porque cada agente tiene un sweet spot distinto y al final del día acabo saltando entre tres o cuatro durante la misma tarea.

El problema con claude-mem es que es un plugin de Claude Code. Sus hooks se enganchan al ciclo de vida del agente: SessionStart, PostToolUse, Stop. Si paso a Codex a mitad de tarea, esos hooks no se disparan ahí. Si pido a Gemini que mire un repo gigante, ese trabajo no entra en mi memoria. Tengo varias memorias paralelas, una por agente, con duplicación y huecos.

Engram resuelve esto desde otro ángulo: no es un plugin de un agente, es un binario Go que expone un servidor MCP. Cualquier cliente que hable MCP (Claude Code, Codex, Gemini CLI, Cursor, VS Code, Windsurf) lee y escribe contra la misma base SQLite local. La memoria deja de estar atada a un proceso concreto y empieza a comportarse como un servicio compartido.

Comparativa práctica: claude-mem vs Engram

Eje	claude-mem	Engram
Captura	Automática vía hooks	Explícita vía mem_save
Almacenamiento	SQLite + índice vectorial	SQLite + FTS5 (full-text)
Coste por observación	Tokens de tu cuenta (compresión SDK)	Cero después del setup
Portabilidad	Claude Code only	Cualquier agente MCP
Fricción inicial	Cero (plugin + reinicio)	Baja (brew install + setup por agente)
Privacidad	~/.claude-mem/, local	~/.engram/, local
Compresión	Sí, progresiva 3 capas	No, full-text indexing
Búsqueda	Vector similarity	FTS5 + BM25

Cada fila es una decisión real. Te explico las cuatro que más pesaron en mi caso.

1. Captura automática vs explícita

claude-mem captura todo automáticamente. Cada tool call, cada edit, cada read. Cómodo si no quieres pensar, ruidoso porque acaba guardando observaciones que no merecen el espacio y consumiendo tokens incluso cuando lo que hiciste no merece guardarse.

Engram te obliga a llamar mem_save explícitamente. Eso suena a trabajo extra, pero en la práctica trae un protocolo de memoria que se inyecta en cada conversación: "guarda decisiones, bugfixes, descubrimientos, convenciones". El propio agente aprende cuándo es relevante. El ruido baja, la señal sube.

2. Compresión SDK vs full-text

claude-mem usa el agent SDK de Claude para comprimir observaciones. Cada compresión gasta tokens. En proyectos activos puedes acabar pagando consumo solo por construir tu memoria. Es invisible hasta que miras la cuenta.

Engram indexa full-text con FTS5 de SQLite. Búsquedas BM25, sin embeddings, sin compresión, sin coste por observación más allá del espacio en disco. Una vez instalado, gastar tokens en guardar memoria deja de ser un coste recurrente.

3. Portabilidad

Esta es la que decidió el cambio. Mi flujo real:

Lunes: arranco una migración en Claude Code → guardo decisiones
Miércoles: pido revisión cruzada a Codex (GPT-5.5) → el modelo no ve mi memoria de Claude
Viernes: vuelvo a Claude Code → tengo que reinyectar contexto manualmente

Con Engram, esa rotura desaparece. Codex lee la misma base de datos, ve las decisiones del lunes, propone revisiones informadas. El miércoles deja de ser un punto de fricción.

4. Memory Protocol (la skill)

Engram trae un detalle no obvio: una skill llamada Memory Protocol que se inyecta en cada conversación de Claude Code. Es un prompt corto que le obliga al agente a:

• Guardar tras cada decisión, bugfix, descubrimiento o convención.
• Buscar memoria antes de empezar trabajo sobre un tema que pudo haberse tocado antes.
• Hacer mem_session_summary al cerrar sesión.

Esto convierte la memoria de "algo que tengo que recordar usar" a "algo que pasa por defecto". Reduce la fricción explícita y compensa la falta de captura automática.

Cuándo claude-mem sigue siendo la mejor opción

No quiero pintar Engram como universalmente superior. No lo es. Tres escenarios donde claude-mem sigue ganando:

• Tu workflow vive 100% en Claude Code. Si no saltas a otros agentes, la portabilidad de Engram es valor que no usas, y la captura automática de claude-mem es comodidad pura.
• Quieres lo mínimo de fricción inicial. claude-mem es un /plugin install y listo. Engram pide un binario instalado más setup por agente, aunque sea breve.
• Confías más en la compresión semántica que en full-text. Si tus observaciones son largas y matizadas, el vector store de claude-mem puede recuperar mejor que el FTS5 de Engram en queries vagas.

Si te encajan dos de los tres, quédate con claude-mem.

Setup: cómo correr Engram en paralelo a claude-mem

No es una migración hard. Es una transición de uso: el flujo nuevo va a Engram, el viejo se consulta donde está. claude-mem y Engram conviven sin tocarse — guardan en directorios distintos (~/.claude-mem/ vs ~/.engram/), así que puedes tener los dos activos en Claude Code mientras decides.

1. Instalar el binario

En macOS:

brew install gentleman-programming/tap/engram

Otras plataformas (Linux, Windows): ver docs/INSTALLATION.md del repo. Es un binario Go autocontenido, sin Node ni Python.

2. Registrarlo en Claude Code

claude plugin marketplace add Gentleman-Programming/engram
claude plugin install engram

El plugin registra automáticamente el servidor MCP, los hooks de sesión y la skill Memory Protocol. Reinicia Claude Code y las tools (mem_save, mem_search, mem_session_summary, etc.) están disponibles en cualquier conversación. No tocas ~/.claude/settings.json a mano.

3. Registrarlo en otros agentes

Una línea por agente:

engram setup codex
engram setup gemini-cli
code --add-mcp '{"name":"engram","command":"engram","args":["mcp"]}'   # VS Code

Cursor, Windsurf y resto en docs/AGENT-SETUP.md. Todos apuntan al mismo SQLite local, así que la memoria es la misma sin replicación manual.

4. Cómo se ve una llamada mem_save real

Engram expone 19 tools MCP. La que vas a usar el 80% del tiempo es mem_save. Estructura recomendada con bloque What/Why/Where/Learned:

title:   "Migrated auth from sessions to JWT"
type:    "decision"
content: |
  **What**: Replaced express-session with jsonwebtoken across the auth middleware.
  **Why**: Session storage no escala entre múltiples instancias (Hetzner load balancer).
  **Where**: src/middleware/auth.ts, src/routes/login.ts.
  **Learned**: httpOnly + secure flags obligatorios en la cookie del refresh token. Rotación de refresh va por endpoint aparte.

Cuando la semana siguiente arrancas una sesión y preguntas "qué hicimos con auth", mem_search con "JWT auth middleware" te trae esa observación con su contexto completo. Es la diferencia entre empezar de cero y arrancar donde lo dejaste.

El plugin además incluye la skill Memory Protocol que se inyecta como instrucción de sistema: obliga a guardar tras decisiones/bugfixes/descubrimientos y a hacer mem_session_summary antes de cerrar. La fricción de "tengo que acordarme de llamarlo" se evapora.

El matiz que no va en ninguna comparativa

Hay una verdad que ningún cuadro comparativo captura: ningún plugin de memoria persistente reemplaza tu CLAUDE.md.

CLAUDE.md fija reglas estáticas que tú escribes a conciencia: convenciones de proyecto, restricciones, principios. La memoria persistente captura decisiones dinámicas que toma el agente. Son capas complementarias. Sin lo primero, lo segundo se desboca; sin lo segundo, lo primero envejece.

Esto vale para claude-mem, para Engram y para cualquier sistema futuro. Tiempo de aprendizaje, que no tiempo perdido.

Preguntas frecuentes

¿Engram es gratis?

Sí. Binario open source (MIT), corre 100% local. Hay una versión Cloud opt-in (engram serve) para sincronizar entre máquinas, pero no es necesaria para uso individual.

¿Puedo usar los dos a la vez?

Sí, sin conflicto. claude-mem guarda en ~/.claude-mem/, Engram en ~/.engram/. Ningún proceso pisa al otro. La única "duplicación" es que en Claude Code tienes dos capas simultáneas escuchando. En proyectos serios yo dejé claude-mem solo para histórico, pero esa es una decisión personal.

¿Y si Engram introduce un bug en una tarea crítica?

Mismo riesgo que claude-mem: estás dejando que un proceso externo modifique tu workflow. Ambos son maduros pero relativamente nuevos. La salvaguarda real es no apoyarte en la memoria persistente para decisiones críticas: usarla como apoyo, no como fuente única de verdad. Toda decisión load-bearing debe vivir también en CLAUDE.md o en un ADR del repo.

Si quieres entender el problema desde cero antes de elegir, el post original sobre claude-mem sigue siendo la mejor introducción. Este post es el siguiente paso: qué pasa cuando tu workflow se reparte entre varios agentes.

Y si tu workflow ya vive en varios agentes, prueba Engram durante una semana en paralelo. Si la memoria empieza a viajar contigo entre Claude, Codex y Gemini, ya sabes qué decidir.

Repos: github.com/Gentleman-Programming/engram (Engram, MIT) · github.com/thedotmack/claude-mem (claude-mem, Apache 2.0). Ambos open source, ambos locales por defecto.