Volver a artículos
Cómo recuerdan los agentes de código
03

Cómo recuerdan los agentes de código

Memoria agéntica · · IA agéntica · memoria · Hermes · Claude Code · agentes

En el artículo anterior propuse un framework de tres niveles para entender la memoria agéntica: declarada (lo que tú le dices al agente), inyectada (lo que el sistema recupera automáticamente) y aprendida (lo que el agente consolida por sí mismo). La mayoría de herramientas que usamos se mueve entre los dos primeros.

Pero no todas lo hacen igual. Voy a entrar en cómo funcionan por dentro usando como eje Hermes, un agente de Nous Research que llevo probando unas semanas y que tiene una de las arquitecturas de memoria más interesantes que he visto en el ecosistema open source.

El enfoque de Claude Code: tres capas y un agente que sueña

Empecemos por lo que probablemente ya conoces, aunque hay más debajo de lo que parece. Claude Code tiene una arquitectura de memoria de tres capas bien definidas.

La primera es el índice (MEMORY.md), que se carga en cada sesión y funciona como tabla de contenidos: punteros cortos (~150 caracteres por entrada) hacia archivos de detalle. La segunda son los topic files (debugging.md, api-conventions.md, etc.), archivos de conocimiento detallado que solo se cargan cuando son relevantes para la tarea en curso. La tercera son los transcripts JSONL, el historial completo de conversaciones, que nunca se cargan directamente en el contexto porque son demasiado costosos, pero sí se pueden buscar.

El context window es un recurso escaso y la arquitectura lo trata como tal. No se vuelca todo siempre; se carga lo mínimo necesario.

Sobre la gestión activa de esta memoria, hay un componente que pocas personas conocen: autoDream, un sub-agente que Claude Code ejecuta en background durante tiempo idle para consolidar lo acumulado en sesiones anteriores. Fusiona conocimiento nuevo en los topic files, resuelve contradicciones y poda el índice. Sus decisiones de diseño dan para mucho, así que lo desgrano en el próximo artículo de la serie.

El límite está en el control. Toda esa consolidación ocurre de forma autónoma y en segundo plano: el agente consolida lo que considera relevante, y tú no eliges el momento ni la consulta. La búsqueda en sesiones pasadas tampoco está expuesta como una herramienta que puedas invocar. Puedes pedirle que rebusque en sus transcripts, que al final son archivos en disco, pero el flujo de “¿qué decidimos la semana pasada sobre la migración?” no existe como operación nativa.

Para la gestión del contexto dentro de una sesión, Claude Code tiene varias estrategias: desde microcompactación inline de resultados de herramientas hasta compactación por resumen semántico de la conversación completa. Puedes influir en qué sobrevive mediante instrucciones en tu CLAUDE.md, pero el modelo toma las decisiones finales.

Hermes: memoria por capas

Hermes parte de una premisa diferente: ningún mecanismo único resuelve todos los problemas de memoria. Por eso implementa una pila de capas donde cada una hace una cosa concreta.

Capa 1: Archivos Markdown curados (siempre activos)

El nivel base son dos archivos, MEMORY.md y USER.md, que el agente lee al inicio de cada sesión y gestiona activamente con una herramienta dedicada. Puede añadir, reemplazar y eliminar entradas. Hasta aquí suena similar a un CLAUDE.md, pero hay una diferencia que cambia bastante la dinámica: aquí el agente también escribe, no solo el humano.

Los archivos tienen límites separados ajustados (~800 tokens para MEMORY.md, ~500 tokens para USER.md), lo que fuerza al agente a ser selectivo. No puede acumular todo; tiene que decidir qué merece persistir. Las escrituras son atómicas (archivo temporal + rename), lo que evita corrupción parcial. Un detalle que parece menor hasta que tienes múltiples terminales abiertos contra el mismo proyecto.

Capa 2: Búsqueda en sesiones pasadas (SQLite + FTS5)

Aquí Hermes resuelve algo que Claude Code solo hace en background. Todas las conversaciones se almacenan en SQLite con una tabla FTS5 para búsqueda de texto completo. Cuando necesitas recuperar algo de una sesión anterior, el agente busca por palabras clave y recupera los mensajes relevantes directamente de la base de datos, tal cual se escribieron, sin pasarlos por un modelo que los resuma.

En lugar de inyectar transcripciones completas en el contexto, caro y ruidoso, el sistema trae solo lo que encaja con la consulta. Y sin embeddings ni base de datos vectorial en esta capa: FTS5 a secas, con operadores booleanos, frases exactas y wildcards. Es rápido, predecible y cubre bien el caso de uso de “¿qué hicimos la semana pasada?”.

Capa 3: Proveedores de memoria externos (plugins)

Hermes permite activar un proveedor externo que se integra en el ciclo de vida del agente con hooks en momentos clave: al inicio de sesión (initialize), antes de cada llamada al modelo (prefetch), después de cada turno (sync_turn), antes de una compactación (on_pre_compress), y al final de la sesión (on_session_end). Solo puede haber uno activo a la vez.

El más maduro es Honcho, que parte de un enfoque distinto al almacenamiento de hechos. En lugar de guardar “al usuario le gusta TypeScript”, Honcho construye una representación dialéctica del usuario mediante razonamiento interno. Es modelado cognitivo, no un almacén de pares clave-valor.

Pero el que más me ha llamado la atención es la memoria holográfica. Usa Representaciones Holográficas Reducidas (HRR) con codificación de fase: cada concepto es un vector de ángulos, bind (asociar dos conceptos) es suma de fases y unbind (recuperar un valor asociado) es la operación inversa. No son embeddings convencionales. La diferencia práctica es que permite consultas composicionales: “encuentra hechos que involucren a la entidad A y a la entidad B” se resuelve como una operación algebraica sobre los vectores, algo que una base de datos vectorial al uso no ofrece.

Además incluye detección de contradicciones (hechos con alta superposición de entidades pero baja similitud de contenido) y un sistema de confianza con feedback asimétrico: un “útil” suma 0.05, un “no útil” resta 0.10. Los datos malos decaen más rápido de lo que crecen los buenos.

Capa 4: Compresión iterativa del contexto

Similar a la compactación de Claude Code, con la diferencia clave de que los proveedores de memoria reciben un hook (on_pre_compress) antes de que se descarte el contexto, lo que les permite extraer información valiosa antes de que desaparezca. Así la compresión, además de reducir, alimenta las otras capas.

Capa 5: Skills como memoria procedimental

Después de completar tareas complejas, Hermes puede crear skills autónomamente: archivos Markdown con instrucciones, referencias y scripts. El agente no solo recuerda qué hizo, sino cómo hacerlo. Las skills se mejoran con cada uso y siguen el estándar abierto de agentskills.io.

Control vs. autonomía

La diferencia real entre Claude Code y Hermes no es capacidad. Es quién decide.

Claude Code hace muchas de estas cosas: consolidación, búsqueda en historial, gestión por capas. Pero las hace de forma autónoma y en segundo plano. Tú ves el resultado, no el proceso. Hermes expone cada capa como una herramienta explícita que el agente puede invocar y que tú puedes auditar.

Mi experiencia probando ambos: Claude Code funciona bien cuando confías en que el agente tome buenas decisiones de memoria por su cuenta. Y en general las toma. Hermes tiene más fricción inicial pero te da visibilidad sobre qué recuerda el agente y por qué, lo cual importa cuando trabajas en proyectos largos o con equipos donde la continuidad entre sesiones no es negociable.

Más que una respuesta correcta, hay una pregunta previa: ¿prefieres que el sistema gestione la memoria por ti, o gestionarla tú con las herramientas adecuadas?

En el próximo artículo entro a fondo en autoDream: de dónde sale lo que sabemos de él (un leak accidental del código fuente de Claude Code), cómo decide cuándo consolidar y por qué su diseño de aislamiento de escrituras me parece la decisión más interesante de todo el sistema.

Referencias