Memoria de agentes desde cero: del problema de los tokens a tu propio segundo cerebro

El video abre como secuela de un breve video sobre memoria publicado cuatro meses antes. Aquel video ofrecía un arreglo rápido para el problema de Claude Code leyendo archivos innecesarios y quemando tokens, pero su corta duración dejaba la mayoría de las preguntas de los espectadores sin respuesta. El nuevo video busca cerrar esa brecha, llegando justo cuando los debates sobre la memoria de agentes vuelven a encenderse. La autora plantea el marco de entrada: toda la explicación corre sobre Claude Code porque es a la vez muy usado y un ejemplo concreto cuya estructura de archivos y herramientas de seguimiento hacen tangible el tema.

Se despliega una hoja de ruta de seis partes. Primero vienen los orígenes del concepto de memoria y el problema de los tokens, luego el enfoque clásico de recuperación y las estructuras de grafo. La segunda parte cubre el comportamiento de memoria por defecto de Claude Code, la tercera el formato llm-wiki y la cuarta el seguimiento con Obsidian. La quinta parte pregunta dónde encajan las herramientas listas para usar como NotebookLM en este panorama, y la última examina el sistema de memoria integrado de Hermes Agent.

El problema central es uno que todos reconocen: tras recibir un prompt, el agente lee cada archivo, relevante o no, quema tokens y no guarda ningún registro separado del usuario. Cada nueva sesión relee los archivos antiguos. La tesis del video es que un agente que recuerda algo tiene exactamente un significado práctico: leer el archivo correcto en el momento correcto. Así que el sistema que el usuario debe construir no es magia, es solo una organización de archivos que hace que el agente lea los archivos correctos en cada entrada.

El núcleo teórico son dos rutas y tres partes. La ruta de escritura sintetiza la conversación terminada en archivos; la ruta de lectura encuentra el archivo correcto cuando llega una pregunta y lleva su contenido de vuelta al chat. Las tres partes son el almacén de datos, el mapa y el archivo de reglas: un almacén de archivos Markdown, un mapa de índice que indica al agente qué archivo visitar, y el archivo de reglas del lado de Claude Code que define cómo leer el mapa. El video lo explica con la analogía de un plano de la ciudad: los almacenes son las tiendas, el índice son las indicaciones y el archivo de reglas es la guía para leer el plano.

El dolor de los tokens viene del lado de la lectura. Si la escritura se hace mal, el agente lo lee todo y la factura crece. La ruta de lectura ya existe; lo que hay que construir es la escritura de los archivos para que el mapa salga bien. Un sistema de memoria no es, por tanto, nada más que datos registrados correctamente y leídos correctamente por el agente. Esta definición se convierte en la vara de medir para cada elección de herramienta en el resto del video.

Luego viene el origen del concepto: el enfoque de recuperación. En el esquema clásico, los grandes conjuntos de datos se dividían en fragmentos, se convertían en vectores mediante modelos de embedding, y el fragmento más cercano se adjuntaba a la respuesta cuando llegaba una pregunta. Ese es exactamente el método que la autora usaba antaño para voluminosos archivos de coordenadas 3D en un trabajo anterior. Pero ese esquema servía para conjuntos de datos estáticos y gigantescos, no para un sistema personal actualizado cada día. En el esquema actual de agentes, el propio modelo hace la recuperación, y el trabajo del humano es construir correctamente el índice y el mapa.

El concepto de grafo se vuelve concreto a través de la interfaz de Obsidian. Los nodos representan unidades de trabajo y las aristas transferencias de información y resultados; una arista solo cuenta cuando ocurre una transferencia genuina. El mecanismo de consulta surge de esto: el usuario pregunta, el agente lee los archivos relevantes, produce un resultado conjunto, y esa síntesis se guarda como un nuevo documento y se actualiza en sesiones posteriores. El agente queda, en la práctica, entrenado desde cero al mostrarle cómo operar el sistema.

La sección más franca cubre el comportamiento por defecto de Claude Code. El agente no recuerda de verdad; un subsistema llamado auto memory toma notas sobre la experiencia, las correcciones dentro del chat, los proyectos en curso y las referencias externas. Un archivo de índice llamado MEMORY.md se carga parcialmente al inicio de cada sesión, mientras que los registros de chat permanecen en las carpetas de proyecto durante treinta días por defecto y luego se eliminan. El resultado es familiar: el agente sabe quién eres pero no puede seguir un tema de hace meses, olvida el formato del trabajo rutinario, y el problema de los tokens regresa en los proyectos grandes.

El formato llm-wiki se presenta como la capa de solución. Es solo un estándar de maquetación Markdown: la estructura del vault, el mapa de índice, los registros de bitácora y los enlaces cruzados entre páginas siguen un esquema fijo. La autora construye un ejemplo en vivo a partir de temas recogidos de los comentarios de los espectadores, entregando al agente los comandos de ingesta, consulta y control de salud a mano mientras el agente sintetiza archivos y actualiza el índice y la bitácora. Lo llamativo es que Obsidian no aparece en ninguna parte de esta etapa; el formato y los comandos hacen el trabajo de enlace.

Obsidian se sitúa en esta arquitectura como una capa de monitoreo y visualización, no de almacenamiento. Abrir el vault revela en la vista de grafo qué página enlaza a dónde y qué nodos están huérfanos. Los archivos de reglas sin enlaces aparecen como huérfanos, mientras que las páginas bien enlazadas se convierten en rutas que el agente puede seguir. La advertencia es tajante: volcar archivos en el visualizador antes de construir enlaces con un agente no muestra nada más que nodos huérfanos. Para proyectos pequeños de una sola vez, montar un vault separado se considera innecesario.

La quinta parte aborda la cuestión de las herramientas listas para usar a través de NotebookLM. Se demuestran partir de una cuenta nueva, añadir fuentes, subir un archivo de diseño y generar resúmenes y tarjetas de información. El veredicto es equilibrado: una herramienta lista basta para una investigación puntual, pero el conocimiento vive solo dentro de esa aplicación y llegar a él cuesta tokens extra. Si el vault está bien construido, el agente no necesita leer decenas de archivos; la herramienta lista y el vault personal no son rivales sino respuestas a distintas escalas.

La última parte cubre Hermes Agent, y la diferencia cabe en una frase: Claude Code anota temas, Hermes anota operaciones. Un servicio en ejecución continua, una tarea activada cada mañana y un archivo de habilidades que actúa como cerebro comprueban en cada ronda si la conversación contiene algo que valga la pena aprender, y luego registran notas breves sin tocar el chat principal. La organización de carpetas y el mecanismo de habilidades se parecen a Claude Code, pero el bucle de escritura-lectura-limpieza que funciona automáticamente desde el primer momento lo distingue del esquema llm-wiki. Al cerrar, la autora señala que los comandos que usó están compartidos en la descripción.