No puedes, salvo que guardes el contexto en un lugar que no sea propiedad de ninguna de las dos herramientas. Esa es exactamente la idea detrás de Engrim: una base de datos SQLite local que almacena las decisiones, restricciones y el estado actual de tu proyecto fuera de cualquier agente, y te los reinyecta al arrancar cada sesión — en Claude Code, Cursor, Windsurf, Antigravity o Codex CLI, sobre el mismo repositorio.
El problema le suena a cualquiera que use más de un agente. Pasas cuarenta minutos explicándole a Claude Code por qué la cola es Redis y no SQS, por qué ese módulo no se toca hasta que salga la migración y en qué estabas justo cuando lo dejaste. Después cambias a Cursor para otra cosa y vuelves a explicarlo todo. Cada herramienta tiene su propia memoria — CLAUDE.md, AGENTS.md, archivos de reglas, servidores MCP de memoria — y ninguna habla con las demás.
Engrim es la respuesta de Tim Gordon: versión 1.3.0, publicada en PyPI el 7 de septiembre de 2026, licencia MIT, Python 3.10 o superior. Llegó a la portada de Hacker News esa misma semana — alrededor de 80 puntos y unos 50 comentarios al momento de escribir esta nota.
¿Qué es Engrim y dónde guarda tu contexto?
Todo vive en un único archivo SQLite en ~/.engrim/memory.db. Sin sincronización en la nube, sin telemetría, sin cuenta. La búsqueda es híbrida: texto completo con FTS5 más embeddings vectoriales estáticos vía model2vec, que corre en CPU y carga en unos 30 milisegundos. Si no quieres embeddings, ENGRIM_EMBED=off lo deja en modo puramente léxico.
Los registros son tipados — decision, fact, feedback, state, user, reference — y con alcance por proyecto. El archivo se escribe con permisos POSIX restringidos (0600) y *.db está en el .gitignore por defecto.
El número que importa es el presupuesto. engrim context genera un paquete de arranque de sesión limitado por cantidad de caracteres, 4.000 por defecto (engrim context -b 4000). Ese tope es la verdadera decisión de diseño: no se trata de “recordar todo”, sino de decidir qué merece ocupar 4.000 caracteres al arrancar.
¿Por qué CLAUDE.md y AGENTS.md no resuelven el cambio de agente?
Porque son archivos de una sola herramienta, y el problema aparece justo entre herramientas. AGENTS.md funciona bien como convención compartida para instrucciones estáticas: cómo se compila el proyecto, qué estilo se usa, qué no se toca. Lo que no hace es capturar el estado de una sesión concreta — la decisión que tomaste hace veinte minutos, la razón por la que descartaste una alternativa, el punto exacto donde te quedaste.
Engrim ataca esa segunda capa. El propio autor lo plantea como complemento, no como reemplazo: los registros arquitectónicos versionados en git siguen siendo el lugar de la documentación duradera. Lo que Engrim guarda es lo que hoy se pierde al cerrar la sesión.
¿Cómo se instala Engrim en Claude Code, Cursor, Windsurf, Antigravity y Codex CLI?
La instalación es un solo comando:
pip install engrim
Después deja que detecte lo que tienes instalado:
engrim setup
Eso autodetecta los entornos presentes — Antigravity, Claude Code, Cursor, Codex CLI, Windsurf — y configura cada uno. Si prefieres ir de a uno:
engrim setup --claudeconecta los hooksSessionStart,SessionEnd,StopyUserPromptSubmiten~/.claude/settings.jsonengrim setup --agyconfigura los hooks en~/.gemini/config/hooks.json, despliega una skill en~/.gemini/config/skills/engrim/y registra el servidor MCPengrim setup --cursorañade Engrim a~/.cursor/mcp.jsonengrim setup --codexconecta los hooks en~/.codex/hooks.jsonengrim setup --allhace todo lo anterior
Windsurf es el único caso manual. Añade esto a ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"engrim": {
"command": "engrim",
"args": ["serve", "--mcp"]
}
}
}
Todos los comandos de setup aceptan --dry-run, que imprime lo que cambiaría sin tocar tu configuración. Úsalo. Estos comandos editan archivos que otras herramientas también escriben.
A través de MCP, los agentes reciben cuatro herramientas: engrim_recall, engrim_add, engrim_context y engrim_review.
¿Cómo es el loop del día a día?
El autor lo llama continue-as-clear, y vale la pena entenderlo porque invierte la costumbre habitual de estirar una sesión larga hasta que se degrada.
Capturas las decisiones a medida que las tomas:
engrim add -t decision -s "La cola se queda en Redis; migración a SQS bloqueada hasta Q4"
Te dejas un puntero a la siguiente tarea, etiquetado como tal. Después, antes de limpiar, revisas qué se te pasó:
engrim review
review inspecciona los logs de la transcripción buscando decisiones que tomaste pero nunca registraste. Si vuelve limpio, haces /clear sin ceremonia — la memoria se reinyecta en el siguiente prompt. Dos comandos completan el cuadro: engrim recall -q "database" para búsqueda híbrida, y engrim supersede --id 12 --status superseded para cuando una decisión deja de ser cierta, que importa más de lo que parece. Un almacén de memoria que solo acumula termina estando equivocado.
¿Funciona de verdad la memoria de los agentes?
Esta fue la objeción más afilada en Hacker News, y es la correcta: hay gente que ha visto a los LLM guardar basura en memoria y después recuperarla en contextos irrelevantes.
La respuesta del autor es que Engrim no intenta ser autónomo. La memoria está pensada para curarse a mano y tratarse como referencia contextual, no como autoridad para tomar decisiones. Él describe el almacén como un cuaderno de escritorio a nivel de sesión. Si esperas un sistema que te observe trabajar y deduzca qué es importante, no es esto, y el diseño tampoco lo pretende.
Dos cosas que planteó el hilo siguen abiertas: qué pasa cuando varios agentes escriben a la vez, y cómo distingue el almacén entre trabajo terminado y un plan abandonado cuando una sesión muere a mitad de camino. Ninguna tiene respuesta documentada por ahora.
¿Qué dicen los números del autor y qué no?
El README de Engrim reporta 105 sesiones continuas sobre una base de código de trading algorítmico de 50.000 líneas, con más de 153.000 tokens de trabajo consolidados en menos de 1.000 tokens — una reducción reclamada de más del 99% en el contexto recargado por reinicio, y cero regresiones en 186 tests unitarios.
Léelo como lo que es: el estudio de caso del propio autor sobre un único proyecto. No ha sido reproducido de forma independiente, y una base de código en un dominio con un estilo de trabajo no es un benchmark. El mecanismo es evidentemente sensato — un paquete de 4.000 caracteres cuesta menos que recargar 200.000 tokens, y para ver eso no hace falta un estudio de caso — pero ese porcentaje concreto pertenece a su proyecto, no al tuyo.
Conviene mantener también la proporción: una portada en Hacker News mide atención, no adopción. Un solo mantenedor, sin página de releases. Si montas un flujo de trabajo sobre esto, mantenlo lo bastante simple como para poder volver a tus archivos CLAUDE.md sin perder gran cosa.
Un detalle más si lees el README con atención: sus ejemplos nombran modelos que ya quedaron viejos. Lo que hay que llevarse es el patrón, no las cadenas de modelo concretas.
¿Claude Code vs Cursor? Con Engrim dejas de tener que elegir
Si usas un solo agente, probablemente todavía no te haga falta — CLAUDE.md y la memoria propia de la herramienta te cubren. Si te mueves habitualmente entre dos o tres sobre el mismo repositorio, esto es lo primero que veo apuntado directamente al traspaso, y no a que un agente recuerde mejor.
Se instala con un comando, guarda todo en un archivo que puedes borrar, y --dry-run te muestra antes qué va a tocar. Es un experimento barato.
Si lo que buscas es memoria persistente dentro de Claude Code y nada más, ya cubrimos esa vía en su momento: Claude-mem: dale a Claude Code la memoria que le falta.
Claude Code Cursor mcp memoria agents-md open-source windsurf