Los plugins de memoria para agentes de IA le están sacando el jugo a una premisa equivocada: que el agente «olvida», asà que la cura es «recordar mejor». Un artÃculo de Kevin Liao que anduvo dando vueltas en Hacker News lo pone en duda con un argumento simple: los agentes no necesitan memoria, necesitan documentación. Lo revisé y lo contrasté con mi propia infraestructura, y tengo opiniones.
Toda la «memoria» es lo mismo: RAG con suerte
La arquitectura tÃpica de estos plugins es siempre la misma: revisan las transcripciones de tus sesiones, generan fragmentos sueltos, los meten en una base vectorial y en cada prompt inyectan los cinco más parecidos según similitud de embeddings. A veces agregan un buscador para que el agente escarbe en la base cuando se confunde, o demonios de fondo que deduplican y «sueñan» reescribiendo recuerdos en la noche. Cada caracterÃstica nueva quema tokens para parchar el mismo defecto de base.
¿Y por qué falla? Porque la similitud en el espacio vectorial no te dice si lo que recuperó está vigente ni si está correcto. Los fragmentos viajan sin contexto, el pasado se trata como verdad aunque tu código cambió ayer, y el agente no busca lo que no sabe que existe. Si tienes 500 fragmentos sobre autenticación, ¿cuántos siguen siendo verdad hoy? Nadie lo sabe, porque la tienda no es auditable. Nadie re-mira la reunión de hace tres años para recordar una decisión; la gente escribe las cosas y las vuelve a leer.
Lo que dice experiencia propia: el cerebro en Markdown
Hace un tiempo este problema se me dio en carne propia. Tengo un sistema personal con agentes crones que corren tareas programadas cada dÃa: publican en mi blog, revisan fuentes de noticias y mandan reportes. Entre sesión y sesión tenÃan una memoria persistente con presupuesto tan apretado que cabÃa poco más que un puñado de notas; el resto era re-descubrir el mundo en cada corrida.
La memoria no bastaba: lo que de verdad sostuvo al sistema fue documentarlo. Un directorio de archivos en Markdown planito, legibles y versionados, donde el agente consulta documentos relevantes antes de cada tipo de tarea, actualiza lo desactualizado después de cada corrida, y anota lecciones cuando algo se rompe: esa ruta del WAF bloquea curl, ese flag se reemplaza por tal otro, ese servicio cambió de URL. Además de «skills»: instructivos paso a paso para tareas recurrentes. Nada de embeddings ni bases opacas; cuando algo falla, hago git diff y veo qué cambió.
El cambio conceptual es tratar el ciclo agéntico como prompt → consultar → construir → actualizar, en vez de prompt → construir → olvidar. Un agente que sabe qué documentos tiene no se queda pegado: consulta antes, trabaja, y deja el documento al dÃa, igual que un compañero de equipo con la libreta al dÃa. Y el efecto secundario es que tú puedes leer, corregir y compartir ese «cerebro»: es texto plano, no una caja negra.
¿La memoria vectorial sobra?
No del todo: el historial crudo de sesiones sirve para responder «¿qué pasó y cuándo?». Pero como fuente principal de contexto, la similitud de embeddings es una loterÃa: te devuelve lo parecido, no lo correcto ni lo actual. Lo correcto vive en un documento que alguien mantuvo.
Si estás armando agentes para tus proyectos o tu pega, mi consejo: antes de pagar por un plugin que sueña en la noche con tus recuerdos, prueba lo aburrido. Un directorio de Markdown versionado, instrucciones que digan dónde está cada documento, y la regla de actualizar después de cada corrida. Cuesta menos, es auditable, y lo entiendes tú igual.
Fuente: Agents Don’t Need Memory. They Need Documentation., de Kevin Liao.
Fuente de inspiración: Agents Don’t Need Memory. They Need Documentation. | Kevin Liao
