Engram 2.0: memoria persistente y más segura para tus agentes

“La primera versión estable de v2 reúne 462 commits desde v1.20.0 para hacer la memoria de los agentes más segura, contextual y operable”, anunciaba dnlrsls en X al publicar la release 2.0.0 de Engram, el sistema de memoria persistente para agentes de código que ya supera las 6.600 estrellas en GitHub.

De “recuerda cosas” a “recuerda cosas del proyecto correcto”

El cambio con más peso práctico de esta versión es la memoria consciente de proyecto. Engram ahora resuelve la identidad del proyecto de forma consistente a partir de configuración explícita, la variable ENGRAM_PROJECT, metadatos de Git o el directorio actual, y añade protección para que una escritura no acabe asignada a la sesión, el proyecto, el worktree o el proceso de agente equivocado. Es el tipo de bug silencioso que solo se nota cuando un agente “recuerda” algo de otro repositorio en medio de una tarea — y la 2.0 lo trata como problema de primera clase, no como edge case.

Encima de eso llega detección de conflictos entre memorias: mem_save puede señalar memorias que probablemente chocan con lo que se está guardando, y los nuevos mem_judge y mem_compare emiten veredictos persistentes —supersedes, conflicts_with, compatible, not_conflict— que después participan en la sincronización local, con Git y con la nube.

Qué más trae la 2.0.0

SQLite local sigue siendo la fuente de verdad en todos los casos; la nube es replicación y visibilidad opcional desde un dashboard, no un requisito para que Engram funcione.

Lo que rompe la actualización

Tres cambios de compatibilidad que conviene mirar antes de actualizar un proyecto en marcha:

• Ruta del módulo Go: quien consume Engram como librería tiene que apuntar a github.com/Gentleman-Programming/engram/v2.
• Alcance de lectura por defecto cambia: antes, omitir el selector de proyecto leía todos los proyectos implícitamente; ahora resuelve solo el proyecto actual. Hay que pasar --all o all_projects=true a propósito para una lectura global — quien dependa del comportamiento antiguo sin saberlo va a ver menos resultados de los que esperaba.
• Cloud más estricto: los despliegues con sync a la nube requieren ENGRAM_CLOUD_ALLOWED_PROJECTS y un ENGRAM_JWT_SECRET que no sea el valor por defecto; engram sync --cloud --all queda rechazado explícitamente.

El propio changelog recomienda un checklist concreto: respaldar ~/.engram/engram.db, actualizar el binario, correr engram doctor y seguir la ruta de reparación que reporte, y reiniciar los servidores MCP y sesiones de agente activos para que carguen los contratos de v2.

Limitaciones conocidas

El proyecto documenta tres issues abiertos junto al propio release: una sesión raíz obsoleta de OpenCode puede hacer fallar mem_save cuando se omite la sesión (hay que cerrarla o pasar el session_id), el adaptador dedicado para OpenCode 2.x todavía no está incluido —engram setup opencode apunta a la rama 1.x—, y procesos concurrentes pueden seguir topándose con contención de escritura en SQLite y pérdidas transitorias de conectividad MCP. Publicarlo en las notas de la propia release, en vez de dejarlo para que lo descubra cada usuario, es una señal razonable de qué tan maduro está el proyecto tratando su propio software.

Encaja con la misma tendencia que ya cubrimos en otras herramientas de agentes que maduran hacia multi-proyecto y multi-usuario: la primera versión resuelve “que el agente recuerde algo”; la segunda resuelve “que recuerde lo correcto, del proyecto correcto, sin pisar lo que ya sabía”.