Las conversaciones con asistentes de programación suelen tener un problema incómodo: resuelven cosas, pero las olvidan. En una sesión se decide una arquitectura, se corrige un error difícil, se descubre una dependencia problemática o se documenta una convención interna. Días después, buena parte de ese aprendizaje queda enterrado en el historial, fuera del alcance del siguiente agente y, muchas veces, también del propio equipo.
Claude Memory Compiler intenta atacar justo ese punto. El proyecto, publicado en GitHub por coleam00, propone convertir las conversaciones mantenidas con Claude Code en una base de conocimiento estructurada, consultable y viva. No se limita a guardar transcripciones. Su objetivo es extraer decisiones, patrones, lecciones aprendidas y advertencias técnicas para organizarlas en artículos Markdown con referencias cruzadas, de forma que el conocimiento generado durante el trabajo diario no desaparezca al cerrar la sesión.
La idea se inspira en la arquitectura de “LLM Knowledge Base” popularizada por Andrej Karpathy, pero aplicada a un caso muy concreto: el desarrollo de software asistido por agentes. En vez de recopilar artículos, papers o notas externas, la materia prima son las propias conversaciones con Claude Code. El resultado es una especie de memoria externa para proyectos de programación, pensada para evolucionar con el código y no solo con los documentos que el equipo escribe manualmente.
Una memoria que se construye a partir de sesiones reales
El funcionamiento del sistema es relativamente sencillo de entender. Claude Code permite usar hooks, es decir, acciones que se ejecutan automáticamente en determinados momentos del ciclo de trabajo. Claude Memory Compiler aprovecha esos hooks para capturar sesiones cuando terminan y también antes de que el contexto se compacte en conversaciones largas. Esa segunda parte es importante, porque muchos aprendizajes aparecen a mitad de una sesión extensa y podrían perderse si solo se guardase el cierre final.
Una vez capturada la conversación, el sistema lanza un proceso en segundo plano. Ese proceso usa Claude Agent SDK para decidir qué merece guardarse: decisiones técnicas, soluciones a errores, patrones de arquitectura, dependencias conflictivas, convenciones del proyecto o cualquier aprendizaje que pueda ser útil en el futuro. La información extraída se añade a un registro diario en Markdown.
Después entra la fase de compilación. El proyecto transforma esos registros diarios en artículos organizados por conceptos, conexiones y preguntas frecuentes. También mantiene un índice que sirve como punto de entrada para futuras consultas. La clave es que no se trata de un historial cronológico, sino de una base de conocimiento reordenada alrededor de temas.
| Fase | Qué ocurre | Resultado |
|---|---|---|
| Captura | Hooks de Claude Code guardan la conversación al cerrar sesión o antes de compactar contexto | Transcripción disponible para procesar |
| Extracción | Claude Agent SDK identifica decisiones, patrones y aprendizajes relevantes | Registro diario en Markdown |
| Compilación | El sistema organiza los logs en artículos por concepto | Base de conocimiento estructurada |
| Consulta | El agente lee el índice y recupera páginas relevantes | Respuestas basadas en conocimiento acumulado |
| Linting | Se revisan enlaces rotos, páginas huérfanas, contradicciones y contenido obsoleto | Mantenimiento de calidad |
Este enfoque cambia la forma de pensar la memoria en herramientas de IA. No intenta modificar el modelo ni prometer una memoria mágica dentro de Claude. Construye una capa externa, basada en archivos Markdown, que puede leerse, auditarse, versionarse y consultar con herramientas normales.
Sin base vectorial ni embeddings: Markdown como infraestructura
Uno de los puntos más llamativos del proyecto es su rechazo inicial a un sistema RAG tradicional. Claude Memory Compiler no depende de una base vectorial, ni de embeddings, ni de una infraestructura adicional para recuperar fragmentos similares. En su lugar, usa un índice Markdown que el modelo puede leer para decidir qué páginas consultar.
La apuesta tiene sentido en bases pequeñas o medianas. En un proyecto personal o en un equipo reducido, con decenas o algunos cientos de artículos, un índice bien estructurado puede ser más útil que una búsqueda semántica basada en similitud de palabras. El modelo no solo busca términos parecidos: interpreta la pregunta, revisa el índice y selecciona los documentos que parecen relevantes.
El propio proyecto reconoce el límite de esta estrategia. A partir de cierto tamaño, cuando la base de conocimiento alcanza miles de artículos o el índice ya no cabe cómodamente en la ventana de contexto, puede ser necesario añadir una capa de búsqueda híbrida o RAG. Pero para el uso personal o por proyecto, la simplicidad es parte del atractivo: todo vive en Markdown, se puede abrir en un editor, sincronizar con Git o convertir en un vault de Obsidian.
Esa decisión también facilita la auditoría. Una base vectorial puede ser opaca para muchos equipos. Un directorio de Markdown con enlaces, resúmenes y páginas por concepto resulta mucho más fácil de revisar. Si el agente ha entendido mal una decisión o ha resumido de forma incorrecta una conversación, el desarrollador puede corregir el archivo directamente.
Qué aporta a los equipos de desarrollo
El valor práctico aparece en tareas repetitivas. Un agente de programación suele perder contexto entre sesiones: por qué se eligió una librería, qué error apareció al migrar una versión, qué patrón de autenticación se usa, qué comandos son seguros, qué pruebas hay que ejecutar antes de tocar una parte del código o qué decisiones de arquitectura ya se descartaron.
Con una base de conocimiento compilada a partir de sesiones reales, el agente puede empezar una nueva conversación con más contexto útil. No necesita que el desarrollador repita todo. Puede consultar el índice, recuperar artículos y trabajar con una memoria de proyecto más cercana a la realidad del código.
Esto no sustituye a la documentación formal. Tampoco reemplaza a un buen README, a los ADR, a los tests o a la revisión humana. Su papel es diferente: capturar el conocimiento informal que normalmente se pierde. Muchas decisiones importantes no llegan nunca a un documento oficial porque surgen durante una depuración, una migración o una conversación exploratoria con la IA. Claude Memory Compiler intenta convertir ese conocimiento disperso en material reutilizable.
También puede ser útil para equipos que están adoptando agentes de programación de forma más intensiva. A medida que las sesiones con IA se vuelven más largas y frecuentes, el historial deja de ser una simple conversación y empieza a parecerse a un registro técnico de trabajo. La pregunta ya no es si conviene guardarlo todo, sino cómo separar lo relevante del ruido.
La parte delicada: privacidad, costes y control
El proyecto también obliga a pensar en riesgos. Las conversaciones con agentes de programación pueden contener código propietario, rutas internas, nombres de clientes, tokens, claves, credenciales, errores de seguridad o detalles de infraestructura. Automatizar su captura exige una política clara: qué se guarda, dónde se guarda, quién puede leerlo y cómo se eliminan datos sensibles.
El hecho de que la base esté en Markdown no elimina esos riesgos. Al contrario, puede hacer que información sensible quede más visible si no se configura bien el repositorio, el .gitignore o los permisos de acceso. En entornos profesionales, este tipo de herramienta debería implantarse con revisión de seguridad, reglas de exclusión y controles de acceso.
También hay que leer con cuidado la parte económica y de autenticación. El README del proyecto indica que el uso personal del Claude Agent SDK estaría cubierto por suscripciones Claude Max, Team o Enterprise, sin créditos API separados. Al mismo tiempo, la documentación oficial del SDK describe el uso de claves API y advierte sobre las condiciones para desarrolladores externos. Para usuarios particulares puede ser suficiente, pero en empresas conviene revisar las condiciones vigentes de Anthropic antes de depender de este flujo en producción.
Por diseño, Claude Memory Compiler parece más una herramienta para desarrolladores avanzados que un producto listo para cualquier organización. Requiere Claude Code, configuración de hooks, Python, uv, comprensión del flujo de archivos y cierta disciplina para revisar lo que el sistema genera. Su atractivo está precisamente en esa franqueza: no promete una plataforma cerrada con memoria universal, sino un patrón reproducible para hacer que el conocimiento de las sesiones se acumule.
La dirección es interesante porque encaja con una tendencia más amplia. Los agentes de IA ya no solo necesitan mejores modelos. Necesitan mejores sistemas alrededor: contexto persistente, permisos, trazabilidad, recuperación de decisiones, memoria de proyecto y mecanismos para no repetir los mismos errores. En programación, donde el conocimiento depende tanto del historial de decisiones como del estado actual del código, esa capa puede marcar diferencias reales.
Claude Memory Compiler apunta a una idea sencilla y poderosa: una conversación útil con IA no debería morir al cerrar la ventana. Si de ella sale una decisión, una advertencia o una lección técnica, puede compilarse, enlazarse y volver a aparecer cuando haga falta. Para muchos desarrolladores, esa puede ser la diferencia entre usar un agente como copiloto puntual o convertirlo en una herramienta que aprende de verdad del proyecto.
Preguntas frecuentes
¿Qué es Claude Memory Compiler?
Claude Memory Compiler es un proyecto open source que convierte conversaciones con Claude Code en una base de conocimiento Markdown. Extrae decisiones, patrones y aprendizajes de las sesiones para reutilizarlos en futuras consultas.
¿Utiliza RAG o una base vectorial?
No en su diseño inicial. El proyecto usa un índice Markdown y recuperación guiada por el modelo. La idea es que, a escala personal o de proyecto, un índice bien estructurado puede ser suficiente sin necesidad de embeddings ni base vectorial.
¿Sustituye a la documentación técnica tradicional?
No. Puede complementar README, ADR, wikis internas y documentación de arquitectura, pero no debería sustituir procesos formales de documentación, revisión y seguridad.
¿Qué riesgos tiene capturar conversaciones automáticamente?
El principal riesgo es guardar información sensible, como código propietario, credenciales, datos de clientes o detalles internos de infraestructura. Antes de usarlo en empresas conviene definir reglas de seguridad, exclusiones y permisos claros.
