Tu agente de código empieza cada sesión sin saber nada. El fallo que arreglasteis ayer, la decisión de arquitectura de la semana pasada, la convención que el equipo acordó hace un mes: nada de eso sobrevive al cierre de la sesión. Engram[1] propone una respuesta deliberadamente sencilla a ese problema, y en este artículo verás qué hace exactamente, qué no hace, y en qué casos la respuesta correcta es no instalarlo.

Puntos clave

  • Engram es un binario en Go con licencia MIT que guarda la memoria del agente en SQLite con FTS5, y se conecta a través de MCP.
  • Su reclamo es la ausencia de dependencias: ni Node, ni Python, ni Docker. Un binario y un fichero.
  • La búsqueda es léxica, no semántica. Recupera lo que escribiste con las palabras que escribiste. Eso cambia qué conviene guardar.
  • La sincronización entre máquinas va por git, así que la memoria acaba siendo un artefacto versionado del repositorio.
  • El proyecto tiene siete meses y su versión 2 está en candidata de release. Adoptarlo hoy es adoptar algo en movimiento.

Qué problema resuelve de verdad

Conviene separar dos cosas que suelen mezclarse. Una es dónde está el código: qué fichero define esta función, dónde se usa aquella constante. Los agentes actuales resuelven eso bien solos, leyendo el repositorio, y para eso no necesitan memoria persistente.

La otra es por qué decidimos esto. Por qué se descartó la biblioteca obvia, qué se probó antes y falló, qué convención de nombres se pactó y por qué. Eso no está en el código, o está disperso en mensajes de commit y conversaciones que ya nadie relee. Es información que se pierde y que cuesta dinero volver a generar, porque el agente vuelve a proponer lo que ya rechazasteis.

Engram apunta a lo segundo. El proyecto lo formula como un protocolo de tres pasos que le impone al modelo: guardar el conocimiento importante, buscar antes de repetir trabajo, y recuperar el detalle completo solo cuando hace falta.

Cómo funciona por dentro

El agente habla con Engram por MCP[2], el protocolo que estandariza cómo un modelo usa herramientas externas. Engram le expone cuatro: mem_save para guardar una observación, mem_search para buscar, mem_context para recuperar el contexto del proyecto al empezar, y mem_current_project para saber en cuál está.

Debajo hay SQLite con la extensión FTS5. Y aquí está el detalle técnico que casi ninguna reseña menciona, porque determina cómo debes usarlo. La documentación oficial de SQLite lo define sin ambigüedad:

FTS5 is an SQLite virtual table module that provides full-text search functionality to database applications.

Búsqueda de texto completo, léxica, con ranking BM25, consultas por frase, por prefijo y por proximidad. No hay embeddings ni similitud vectorial. Si guardaste una nota que decía «el pool de conexiones se satura con más de 40 workers» y luego preguntas por «límite de concurrencia», FTS5 no va a establecer esa relación por ti.

Esto no es un defecto, es una elección de diseño con una consecuencia práctica: escribe las notas con los términos que vas a volver a teclear. Nombres de funciones, mensajes de error literales, nombres de servicios. Nada de prosa elegante. Una memoria léxica premia el vocabulario consistente, igual que lo premia un grep.

Instalación y prueba

En macOS la vía recomendada es Homebrew:

brew install gentleman-programming/tap/engram
engram setup claude-code

El subcomando setup escribe la configuración del agente que le indiques. La lista de agentes soportados es larga: Claude Code, OpenCode, Gemini CLI, Codex, VS Code con Copilot, Cursor, Windsurf, Antigravity y cualquier otro que hable MCP.

Para ver qué está guardando hay una interfaz de terminal:

engram tui

Se navega con teclas de vim: j y k para moverse, Enter para entrar en una observación, / para buscar y Esc para volver. Es la forma rápida de auditar qué ha decidido recordar el agente, que en la práctica es la parte que más conviene vigilar.

La pregunta incómoda: ¿lo necesitas?

Si has seguido el argumento de que los agentes de código funcionan bien buscando directamente en el repositorio, la duda es razonable. Si el agente ya encuentra lo que necesita, ¿para qué una capa más?

La respuesta honesta es que depende del tamaño del equipo y de cuánta decisión no escrita arrastráis. En un proyecto personal con un CLAUDE.md bien mantenido, Engram añade una pieza móvil a cambio de poco. En un repositorio con más de una persona, meses de historia y decisiones que se toman en reuniones, la diferencia se nota.

Y hay una alternativa que casi ninguna comparativa incluye: no instalar nada. Un fichero CLAUDE.md o AGENTS.md versionado en el repositorio es memoria persistente, se revisa por pull request y no requiere ningún proceso adicional. Es menos automático y no escala igual, pero tiene una propiedad que ninguna base de datos local ofrece: alguien lo lee antes de que entre.

Alternativas y cuándo elegir cada una

Opción Enfoque Encaja cuando
Engram Binario Go + SQLite/FTS5 local, vía MCP Quieres memoria sin montar infraestructura y te basta la búsqueda léxica
mem0 Plataforma orientada a la nube, con opción autoalojada Necesitas perfiles de usuario y personalización a largo plazo
Letta (antes MemGPT) Framework de agentes con memoria por niveles Agentes de horizonte largo; hay opción autoalojada gratuita
Zep / Graphiti[3] Grafo de conocimiento temporal Importa cuándo pasó algo, no solo qué pasó
Servidor memory de referencia de MCP El mínimo viable Quieres probar el concepto sin comprometerte
CLAUDE.md versionado Ninguna herramienta Proyecto pequeño; prefieres que la memoria se revise

Sobre Zep conviene un matiz de honestidad. Su artículo declara mejoras de precisión de hasta el 18,5 % y una reducción de latencia del 90 % frente a las implementaciones de referencia en LongMemEval. Son cifras publicadas por los autores del propio sistema evaluado, no un arbitraje independiente, y así hay que leerlas.

Sincronización por git, y lo que implica

Engram exporta la base a git en fragmentos comprimidos. El proyecto afirma que así se evitan los conflictos de fusión y los ficheros enormes; no lo hemos medido nosotros.

El matiz importante no es técnico sino de criterio. Si la memoria se sincroniza por git, la memoria es parte del repositorio. Todo lo que el agente decida guardar acaba en el historial, con la persistencia y la visibilidad que eso conlleva. Decide qué entra antes de que entre, y revisa la base con engram tui de vez en cuando en lugar de confiar en que el criterio del modelo coincida con el tuyo.

Existe además Engram Cloud, presentada como una capa de replicación opcional y autoalojada, para desplegar en Dokploy, Coolify, Portainer o un VPS pelado. La web del proyecto no publica precio.

El estado real del proyecto

Aquí van los números, leídos de la API de GitHub el 3 de septiembre de 2026, no de la página renderizada:

  • 6.286 estrellas y 670 forks.
  • Repositorio creado el 16 de febrero de 2026: unos siete meses de vida.
  • 60 versiones publicadas, de las cuales 55 son estables.
  • La última estable es la v1.20.0, del 20 de julio de 2026.
  • La más reciente, v2.0.0-rc.4, se publicó el 2 de septiembre de 2026 y es una candidata de release.

Es decir: la versión mayor en curso todavía no ha salido de candidatas, y el repositorio recibe cambios a diario. No es un argumento para descartarlo, pero sí para fijar la versión que instalas y no dar por hecho que la interfaz de hoy será la de dentro de tres meses.

Preguntas frecuentes

¿Funciona con agentes que no sean Claude Code?

Sí. Engram se comunica por MCP, así que sirve para cualquier agente que soporte el protocolo. El proyecto lista soporte explícito para OpenCode, Gemini CLI, Codex, Cursor, Windsurf y VS Code con Copilot, entre otros.

¿Necesito una base de datos vectorial?

No, y ese es justo el planteamiento. Engram usa FTS5, que es búsqueda léxica sobre SQLite. Ganas simplicidad de despliegue y pierdes la recuperación por significado: dos notas que dicen lo mismo con palabras distintas no se encuentran entre sí.

¿Puedo compartir la memoria con mi equipo?

Sí, por git o con la capa Cloud autoalojada. Antes de hacerlo, ten en cuenta que estarás publicando en el repositorio todo lo que el agente haya considerado digno de guardar.

Conclusión

Engram acierta en el diagnóstico y en la forma. El problema es real (los agentes olvidan las decisiones, no el código) y la solución elegida es un binario sin dependencias en lugar de una plataforma. Para quien ya autoaloja cosas, esa proporción entre lo que aporta y lo que hay que mantener resulta cómoda.

Las dos cosas que conviene tener claras antes de instalarlo son que la búsqueda es léxica, lo que obliga a escribir notas con vocabulario consistente, y que la versión 2 sigue en candidatas. Si tu proyecto es pequeño, prueba primero con un fichero de convenciones bien mantenido: puede que ya sea suficiente.

Este artículo también está disponible en inglés.

Fuentes

  1. Engram
  2. MCP
  3. Zep / Graphiti
  4. Engram, sitio del proyecto
  5. SQLite: FTS5 Extension

Ruta: Agentes de código: asistentes de programación con IA