kaeru da a Claude Code y Codex una memoria a largo plazo en forma de grafo a través de MCP

Cualquiera que trabaje con agentes de IA durante más de una semana conoce la escena. Abre un proyecto y el agente le pregunta algo que ya respondió ayer. Media hora después propone arreglar lo que usted decidió no tocar, y suena convincente porque desconoce el motivo. Y cuando el contexto se desborda y la conversación se comprime en un resumen, la mitad de la discusión queda reducida a un par de líneas.

El equipo de Lamantin AI propone resolver esto con una capa de memoria independiente. La herramienta se llama kaeru y su código fuente está en GitHub. A continuación se analiza cómo funciona y dónde están sus puntos débiles. El autor del texto original es el desarrollador de la propia herramienta, así que conviene leerlo como una visión desde dentro.

Por qué no basta un archivo de reglas

Todos empiezan igual: CLAUDE.md, AGENTS.md, .cursorrules o una nota en Obsidian. Aproximadamente al mes empiezan los problemas:

• el archivo se actualiza cuando alguien se acuerda de él, es decir, tres días después y con pérdida de detalles;
• solo crece: añadir es fácil, tachar da miedo, y el agente confía igual en la regla de ayer que en una anulada hace un mes;
• contiene el «qué», pero no el «por qué»: un «no tocar el parser» sin motivo no se puede ni comprobar ni revocar;
• cada miembro del equipo tiene su propio archivo.

Los ADR y los gestores de tareas como beads cubren parte de los problemas, pero no la capa de trabajo entre commits: hipótesis, comprobaciones, particularidades de los entornos de pruebas. Llevar todo eso al repositorio supone ensuciar el historial, y no anotarlo supone perderlo. kaeru está pensado para esa capa.

Cómo funciona

kaeru se ejecuta en su máquina como servidor MCP, y a él se conectan Claude Code, Codex, Cursor y otros clientes. La memoria se almacena como un grafo: observaciones («los archivos del cliente llegan en cp1251»), decisiones, tareas con plazos, hipótesis con el resultado de su comprobación y documentos. Las relaciones están tipadas: «surgió de», «sustituye», «refuta», «confirma», «bloquea», «contradice». El agente puede guardar entera la cadena que va de la observación a la decisión como un razonamiento.

Ejemplo del artículo: el agente sospecha que la exportación nocturna falla por el tamaño del archivo. Lo comprueba con un archivo de 2 ГБ y registra la hipótesis directamente con el veredicto «refutada». Si una semana después la exportación vuelve a fallar, el siguiente agente partirá de otra versión. Sin memoria, el resultado negativo es lo primero que se pierde: las soluciones que funcionan acaban en el código, las fallidas no van a ninguna parte.

Lo antiguo se puede sustituir de forma explícita. La llamada replace marca la entrada anterior como reemplazada y muestra qué conclusiones se apoyaban en ella. La entrada no se elimina: conserva su historial y se puede abrir su versión en cualquier momento.

También hay recordatorios: una entrada puede ocultarse hasta una fecha determinada. Ejemplo del autor: el certificado de un entorno de pruebas se renueva cada seis días. El quinto día ese dato hace falta; el primero solo estorba. El plazo del recordatorio se cuenta desde la primera vez que se muestra, de modo que no caduca tras unas vacaciones.

Qué hacen los hooks y qué hace el servidor

El servidor se encarga del almacenamiento y del resumen. Cuándo solicitarlo y qué hacer al comprimir el contexto lo decide el cliente, mediante hooks en Claude Code y Codex. El autor escribió algunos hooks para uso propio y, por ahora, no forman parte de kaeru. En el repositorio hay kaeru-first: antes de que el agente haga una pregunta a una persona, el hook busca coincidencias en la memoria y propone leer primero lo encontrado.

Hay además una observación útil. Al agente simplemente se le sugirió leer los razonamientos guardados y, a lo largo de siete sesiones, no lo hizo ni una vez. Por eso el resumen se inyecta automáticamente al inicio de la sesión.

Limitaciones

• kaeru no garantiza que las entradas sean ciertas. El agente puede anotar disparates igual que en un archivo de reglas. La ventaja es que se ve de qué observaciones surgió una conclusión y que un error se puede marcar y rehacer la cadena.
• La sustitución de lo antiguo debe invocarla el propio agente. En el caso del autor, durante dos semanas convivieron dos reglas con ID distintos de las mismas personas en GitLab: se registró la nueva, pero no se sustituyó la antigua.
• Que una búsqueda coincida por palabras no significa que la entrada contenga la respuesta.
• El servidor de equipo kaeru-cloud lo despliega usted mismo. Está pensado para un equipo de confianza, con un único espacio común dividido por proyectos; por ahora no hay aislamiento entre usuarios ni organizaciones. Por defecto los proyectos son privados, y antes del envío las entradas se escanean en busca de claves y tokens.

Qué hacer con esto

Si sus agentes trabajan más de un par de días en el mismo proyecto, conviene separar el conocimiento en dos capas. Los acuerdos estables se quedan en el repositorio (reglas, ADR) y pasan por revisión. Los hallazgos de trabajo, las hipótesis descartadas y los «porqués» necesitan un almacén aparte, con historial y sustitución explícita de lo obsoleto. Incluso sin kaeru merece la pena adoptar dos prácticas: anotar las hipótesis junto con su veredicto e inyectar al agente un resumen corto de forma automática, en lugar de confiar en que lo lea por su cuenta.