Memoria en agentes de IA: qué es y por qué olvidan
Un agente no recuerda nada por sí mismo. Todo lo que «sabe» de ti se lo vuelven a leer cada vez que trabaja. Te explico cómo funciona esa memoria por capas y por qué falla, con los errores reales de un sistema de un centenar de tareas automáticas que tengo funcionando en una Raspberry Pi 5.
Lo esencial en dos párrafos
La memoria de un agente no vive dentro del modelo: es un sistema de notas, archivos y resúmenes que un programa externo administra y le enseña al modelo en cada turno. Falla de dos maneras distintas, olvidando lo que debía saber o tratando como actual algo que ya caducó, y la segunda es la más peligrosa porque no da ningún error.
Datos clave de mi sistema (septiembre y octubre de 2026): 2.800 caracteres de notas fijas, 4 escrituras rechazadas en una sola noche, 105 claves para 9 recuerdos vivos y 1.320 recuerdos en la base semántica.
¿Qué es la memoria de un agente de IA?
La memoria de un agente de IA es todo lo que el sistema guarda fuera del modelo para volver a ponérselo delante más tarde: datos sobre ti, decisiones tomadas, errores que ya ocurrieron, el resumen de lo que se habló hace una hora. El modelo de lenguaje, por sí solo, no recuerda nada entre una llamada y la siguiente.
Esto sorprende a casi todo el mundo, y me incluyo. Cuando empecé a montar agentes daba por hecho que «el modelo aprendía» de lo que le contaba. No es así. Sus parámetros quedan fijados al terminar el entrenamiento y no cambian porque tú le digas que prefieres respuestas cortas. Si la próxima vez te responde corto, es porque alguien guardó esa preferencia en una nota y se la volvió a enseñar.
Si todavía no tienes claro qué separa un agente de un chatbot, empieza por la guía de qué es un agente de IA. Esta es la siguiente pieza: cómo recuerda.
Una analogía: el empleado del turno de noche
Imagina un empleado brillante con un problema raro: cada vez que entra a trabajar ha olvidado todo lo anterior. Para que pueda rendir, la empresa le prepara cuatro cosas:
- La mesa de trabajo. Los papeles que tiene delante ahora mismo. Solo caben unos cuantos y, cuantos más hay, peor los lee.
- Los pósits pegados al monitor. Pocas notas, cortas, que lee siempre al sentarse: «el cliente odia el formato largo», «la impresora del pasillo no funciona».
- El archivador. Miles de fichas. No las lee todas: busca las que parecen relacionadas con lo que está haciendo.
- El parte del turno anterior. Un resumen de lo que pasó, porque las conversaciones completas no caben en la mesa.
Un agente funciona exactamente así. La mesa es la ventana de contexto; los pósits, las notas fijas; el archivador, la memoria semántica; el parte, la compresión o resumen de la conversación. Y los fallos también se parecen: pósits que nadie quita aunque ya no sean verdad, fichas que no aparecen al buscar, un parte que se deja fuera justo lo importante.
¿Por qué un modelo no recuerda nada por sí solo?
Porque cada llamada a un modelo es independiente. Le llega un bloque de texto, devuelve un bloque de texto y se acabó. Lo que hace que un chat parezca tener memoria es que el programa le reenvía la conversación entera en cada mensaje. Cada mensaje nuevo arrastra todos los anteriores.
Eso tiene dos consecuencias prácticas. La primera es el dinero: pagas por leer otra vez todo el historial en cada turno. La segunda es menos obvia y más importante: más texto no significa mejor memoria.
El estudio Lost in the Middle (Stanford y otros, julio de 2023) midió que los modelos aciertan más cuando el dato relevante está al principio o al final del texto, y fallan bastante más cuando está en el medio. En julio de 2025, Chroma probó 18 modelos, incluidos GPT-4.1, Claude 4 y Gemini 2.5, con tareas muy simples, y vio que el rendimiento se vuelve menos fiable a medida que crece la entrada. Lo bautizaron context rot: el contexto se «pudre».
Anthropic lo resume en su guía de ingeniería de contexto (29 de septiembre de 2025): el contexto es un recurso finito con rendimientos decrecientes, y el objetivo es encontrar el conjunto más pequeño de información que sea de verdad útil. Esa frase es la base de todo lo que viene después.
Las cuatro capas de memoria, una a una
| Capa | En la analogía | Qué guarda | Cómo es en mi sistema |
|---|---|---|---|
| Ventana de contexto | La mesa | La conversación y el trabajo en curso | Se resume al llegar a la mitad de su capacidad |
| Notas fijas | Los pósits | Hechos estables sobre el entorno y sobre el usuario | 2.800 caracteres de notas + 1.375 del perfil |
| Memoria semántica | El archivador | Recuerdos sueltos que se buscan por significado | 1.320 recuerdos a 6 de octubre de 2026 |
| Compresión | El parte del turno | Un resumen de lo que ya no cabe | Comprime a un 20% y protege los últimos 20 mensajes |
1. La ventana de contexto: lo que el agente tiene delante
Es la única «memoria» que el modelo ve de verdad. Todo lo demás existe para decidir qué entra aquí. Tiene un tamaño máximo fijo, y si lo superas el proveedor te devuelve un error del tipo context length exceeded. Pero el límite real llega antes, por lo que acabamos de ver: mucho antes de llenarse, el modelo ya presta peor atención.
2. Las notas fijas: los pósits que lee siempre
Son un texto corto que se pega al principio de cada sesión. El agente que uso, Hermes Agent, separa dos ficheros: uno con las notas del propio agente (por defecto 2.200 caracteres; yo lo tengo subido a 2.800) y otro con el perfil del usuario, de 1.375. Hoy, mientras escribo esto, las notas ocupan 2.252 caracteres, un 80%.
Hay un detalle de diseño que conviene conocer porque explica muchos «¿por qué no se acuerda?». Las notas se cargan una sola vez, al empezar la sesión, como una foto congelada. Si el agente guarda algo nuevo a mitad de conversación, se escribe en disco al momento, pero no lo verá en sus pósits hasta la siguiente sesión. Lo hacen así a propósito, para aprovechar la caché del proveedor y que cada turno cueste menos. La consecuencia es que, si una charla dura semanas sin reiniciarse, lo aprendido en ella no entra nunca en su contexto fijo.
3. La memoria semántica: el archivador con buscador
Aquí no se guarda texto para leerlo entero, sino recuerdos sueltos que se buscan por parecido de significado. Cada recuerdo se convierte en un vector, una lista de números que representa de qué trata, y cuando el agente necesita contexto busca los vectores más cercanos a la pregunta actual.
La referencia más citada es el artículo de Mem0 (abril de 2025). Su sistema extrae los hechos importantes de cada conversación, los consolida y los recupera cuando hacen falta. En su banco de pruebas obtuvo un 26% de mejora relativa sobre la memoria de OpenAI, un 91% menos de latencia en el percentil 95 y más de un 90% de ahorro de tokens frente a meter la conversación entera. Son cifras de los propios autores, así que tómalas como lo que son: un buen punto de partida, no una garantía.
Yo uso la versión libre de Mem0 con una base de vectores (Qdrant) en la misma Raspberry Pi. Dos decisiones que aprendí a golpes:
- El modelo que crea los vectores tiene que entender tu idioma. El primero que probé solo funcionaba bien en inglés y mezclaba temas cuando le hablaba en español. Lo cambié por bge-m3, que es multilingüe y corre en local sin coste.
- No todo el mundo debe escribir en el archivador. Solo la conversación principal guarda recuerdos. Las tareas programadas no leen ni escriben ahí. Si lo hicieran, más de cien procesos llenarían la base de ruido y pagarían una extracción en cada ejecución.
Coste medido: la extracción de recuerdos con un modelo barato sale a unos 0,0007 dólares por turno, alrededor de 1 dólar al mes con 50 turnos diarios. El resto corre en local. Si te interesa el desglose completo de lo que me cuesta mantener todo esto, está en cuánto cuesta de verdad correr agentes IA.
4. La compresión: el parte del turno anterior
Cuando la conversación crece demasiado, un modelo secundario resume la parte antigua y el agente sigue trabajando con ese resumen. Anthropic lo llama compaction y lo describe como la primera palanca para que un agente aguante tareas largas. En mi configuración la compresión salta al llegar al 50% de la ventana, intenta dejar lo antiguo en un 20% de su tamaño y nunca toca los 3 primeros mensajes ni los 20 últimos.
Esos dos números protegidos no son casualidad. Los primeros mensajes suelen contener el encargo; los últimos, lo que se está haciendo ahora. Lo del medio, que es justo la zona donde los modelos ya rinden peor según el estudio de 2023, es lo que se resume.
¿Cómo decide un agente qué recordar?
El ciclo tiene cuatro pasos, y cada uno puede fallar por separado:
- Escribir. Alguien decide que algo merece guardarse. La documentación de LangChain distingue dos momentos: «en caliente», durante la conversación, cuando el propio agente llama a una herramienta de memoria, o «en segundo plano», cuando otro proceso repasa la charla después y extrae hechos.
- Guardar. El recuerdo va a un sitio con límites: un fichero con tope de caracteres, una base de vectores o un historial.
- Recuperar. En el siguiente turno, el sistema elige qué recuerdos le enseña al modelo. Las notas fijas entran siempre; las del archivador, solo si la búsqueda las encuentra.
- Inyectar. Lo recuperado se coloca en la ventana de contexto, junto a la pregunta.
Un recuerdo que se escribió bien pero no se recupera es, a efectos prácticos, un recuerdo que no existe. Y uno que se recupera pero ya no es cierto es peor que no tener ninguno.
Este esquema por niveles viene de lejos. El artículo MemGPT (octubre de 2023, de investigadores de Berkeley) propuso tratar al modelo como un sistema operativo, con memoria rápida y pequeña y memoria lenta y grande, moviendo datos entre ambas. Aquel proyecto es hoy Letta, y la idea de capas la ha copiado casi todo el sector.
¿Por qué un agente olvida? Cuatro causas reales
Cuando un agente «no se acuerda» de algo, casi siempre es uno de estos casos:
| Causa | Qué pasó | Cómo se nota |
|---|---|---|
| No se guardó | Lo mencionaste de pasada y nadie lo escribió | Te lo vuelve a preguntar |
| No se recuperó | Está en el archivador, pero la búsqueda no lo trajo | Lo recuerda solo si se lo preguntas con las mismas palabras |
| Se perdió al resumir | El resumen de la conversación lo dejó fuera | Olvida algo que dijisteis hace una hora en la misma charla |
| La libreta estaba llena | La escritura se rechazó por falta de espacio | Cree que lo guardó; no lo guardó |
La cuarta me pasó a mí, y es la que mejor explica por qué la memoria hay que vigilarla como cualquier otra pieza.
Los números de este apartado están en mis mediciones publicadas. El 7 de septiembre de 2026, a la 1:15 de la madrugada, la herramienta de memoria rechazó cuatro escrituras seguidas. Las notas estaban al 98%: 2.764 de 2.800 caracteres. Lo primero que pensé fue que el proceso que las limpia estaba roto. No lo estaba. Lo ejecuté a mano y funcionó a la primera: pasó de 2.764 a 2.061 caracteres y liberó 739.
El problema era el horario. La limpieza corría a las 3:30 y a las 17:30. Entre las 17:30 y las 3:30 había una ventana ciega de 10 horas en la que nadie recortaba nada. Y la memoria no se llena por horario, se llena cuando hay conversación: una noche activa metía 700 caracteres y la poda llegaba tarde. La lección que saqué es que un proceso que reacciona al reloj no puede contener otro que reacciona al uso. La poda tiene que mirar el nivel, no la hora.
Lo peor fue que el fallo era invisible desde fuera. Solo lo veía el agente en su propio turno, al intentar guardar. Ninguno de mis paneles lo mostraba.
¿Por qué un agente recuerda mal? La memoria que miente
Olvidar es molesto. Recordar mal es peligroso, porque el agente no duda: afirma el dato viejo con la misma seguridad que uno recién verificado. En inglés lo llaman memory staleness, memoria caducada. Mem0 publicó el 23 de septiembre de 2026 un buen análisis del problema, y la frase que mejor lo define es suya: un recuerdo caducado no era falso el día que se escribió, se volvió falso después y nada marcó el momento.
Distinguen dos versiones. La fácil: algo se contradice de forma explícita («Alicia tiene acceso» y después «a Alicia le quitaron el acceso») y el sistema retira el viejo. La traicionera: nadie contradice nada, el dato simplemente deja de importar o de ser cierto, y sigue ahí apareciendo en las búsquedas.
Mi caso fue de la segunda clase. El 5 de octubre de 2026 revisé la base semántica: había acumulado 1.221 recuerdos en 9 días, unos 135 al día, y cerca de un 10% no eran hechos sino planes y tareas en curso. Frases del tipo «el asistente se ofreció a pasar varias tareas a modelos gratuitos, pendiente de aprobación». Eso era cierto el día que se escribió. Una semana después, cuando ya estaba decidido, el agente lo recuperaba y lo trataba como algo todavía pendiente.
El arreglo tiene dos partes y ninguna usa IA:
- Un barrido que busca recuerdos con forma de plan («se ofreció a», «planea», «pendiente de») y con más de 7 días, y los saca de la base.
- Antes de borrarlos, los archiva completos en un fichero aparte. Si el patrón se pasa de listo y se lleva algo bueno, se restaura.
La regla que más me costó afinar fue la del patrón. La primera versión era demasiado amplia y cazaba decisiones del usuario y hechos duraderos. Ahora una decisión o una preferencia mía no caduca nunca por ese barrido: solo caducan los planes.
Hubo otro síntoma del mismo problema, más sutil. El sistema propone a veces cambios a las notas fijas («sustituye esta línea por esta otra»). De las 7 propuestas registradas hasta el 5 de octubre, 6 se descartaron porque la línea que querían cambiar ya no existía: la memoria se había reescrito entre que se propuso el cambio y se intentó aplicar. Descartarlas fue lo correcto. Aplicar una edición pensada sobre una versión vieja es la manera más rápida de corromper unas notas.
Buenas prácticas que aplico (y por qué)
| Sí guardo | No guardo |
|---|---|
| Hechos estables: «la web está detrás de Cloudflare» | Progreso de tareas: «fase 2 terminada» |
| Preferencias del usuario: «explicar sin jerga» | Cualquier cosa que caduque en menos de 7 días |
| Lecciones con fecha: «la poda por horario dejó una ventana de 10 h» | Números de incidencia, versiones del momento, identificadores |
| Frases declarativas: «el proyecto usa pytest» | Órdenes: «ejecuta siempre pytest» |
La última fila parece un matiz y no lo es. Una nota escrita como orden se vuelve a leer en cada sesión como si fuera una instrucción nueva, también en contextos donde ya no tiene sentido. Escrita como hecho, el agente decide si aplica.
Otras cuatro reglas que me han ahorrado problemas:
- Separar el perfil del usuario de las notas del agente. Las notas del agente se pueden regenerar observando el sistema. El perfil son datos de una persona y no se podan por una puntuación automática.
- Consolidar es redactar, no borrar. El 20 de septiembre de 2026 el perfil estaba al 94% (1.298 de 1.375 caracteres). Lo reescribí más corto, 1.246 caracteres, y después comprobé uno a uno que cada dato seguía presente. Un resumen sin esa comprobación siempre le parece correcto a quien lo escribe.
- Archivar antes de borrar. Las notas que salen de los pósits van a un archivo frío que se puede consultar. Hoy ese archivo tiene 59.873 caracteres: mucho más de lo que cabría en el contexto, y nada perdido.
- Un solo escritor por memoria. La documentación de Hermes lo advierte: dos agentes escribiendo en la misma memoria acaban mezclando entradas que no escribió ninguno de los dos. Si dos agentes necesitan compartir, mejor una base externa.
Lo que nadie te dijo
La memoria también hay que auditarla, y el auditor puede mentir. El sistema guarda un fichero con la fecha de último uso de cada nota, para saber cuáles se pueden retirar. El 14 de septiembre de 2026 descubrí que tenía 105 claves para solo 9 notas vivas. Cada vez que una nota se reescribía, su clave vieja se quedaba ahí para siempre. Lo grave era que una comprobación automática decía «0 claves huérfanas»: buscaba coincidencias parciales de texto, y casi todo coincidía con algo. Tras la limpieza, el fichero pasó de 10.668 a 922 bytes. Ningún error lo había delatado.
Una regla documentada no es una regla aplicada. Revisando el código del proceso que poda las notas, el 7 de septiembre, encontré cuatro reglas descritas en la documentación (aislar las notas con poca puntuación, tope de notas por nivel, caducidad a los 60 días y poda del perfil) que estaban declaradas como constantes y no se usaban en ninguna parte. Llevaban semanas «activas» en el papel. Las borré, porque una norma que no se cumple y que todos creen vigente es peor que no tenerla.
Los arreglos también caducan. Para cerrar la ventana ciega de 10 horas añadí un vigilante que comprobaba el nivel cada hora. A finales de septiembre se retiró por solaparse con la poda principal, y la ventana nocturna ha vuelto a estar abierta. Lo cuento porque es exactamente el tipo de cosa que nadie publica, y porque así funciona un sistema real: una decisión razonable en un sitio deshace otra en otro. Lo que hago ahora es medir el síntoma (escrituras rechazadas) en lugar de fiarme de que el arreglo sigue ahí.
Más memoria no es mejor memoria. Es tentador guardar todo «por si acaso». Pero cada recuerdo de más compite por la atención del modelo y aumenta la probabilidad de que salga uno caducado. Si me preguntas qué ajuste ha mejorado más a mis agentes, no fue añadir memoria, fue quitarla.
Si te interesa el lado de la evaluación, cuando el agente dice «hecho» y no lo ha hecho, lo cuento en el caso de las 14 veces que mi agente me dijo que estaba arreglado. Y la auditoría completa de los vigilantes que no vigilaban está en este post-mortem.
¿Memoria o RAG? No son lo mismo
Se confunden mucho porque las dos usan búsqueda por vectores. La diferencia está en quién escribe y cuándo. RAG consulta documentos que ya existían antes de la conversación (un manual, el catálogo, la base de conocimiento de una empresa) y normalmente solo los lee. La memoria la escribe el propio agente mientras trabaja: lo que le contaste, lo que decidisteis, lo que salió mal. ImplementaHQ lo explica bien en español: la memoria guarda hechos aprendidos durante la operación que deben sobrevivir al final de la conversación.
En la práctica, un agente serio usa las dos. Yo tengo además un segundo cerebro en Obsidian que hace de biblioteca de consulta, y que no se mezcla con las notas del agente.
Preguntas frecuentes
¿Un agente de IA aprende de mis conversaciones?
No en el sentido de cambiar su cerebro. El modelo no se modifica al hablar contigo. Lo que cambia son las notas y los recuerdos que el programa que lo rodea guarda y le vuelve a mostrar en la siguiente conversación.
¿Qué diferencia hay entre memoria y RAG?
RAG consulta documentos que ya existían, como un manual, y normalmente solo los lee. La memoria la escribe el propio agente mientras trabaja: lo que le contaste, lo que decidisteis o lo que falló.
¿Una ventana de contexto más grande soluciona el olvido?
Ayuda poco. Los estudios de 2023 y de julio de 2025 citados arriba midieron que los modelos rinden peor cuanto más texto reciben. Elegir bien qué entra funciona mejor que meterlo todo.
¿Por qué mi agente no recuerda algo que le dije hace un rato?
Mira las cuatro causas de la tabla: no se guardó, no se recuperó, se perdió al resumir o la libreta estaba llena. Y comprueba si tu herramienta usa una foto congelada de las notas: en ese caso lo guardado hoy se ve en la próxima sesión, no en esta.
¿Cuánto cuesta darle memoria a largo plazo a un agente?
Puede ser casi gratis. En mi caso la base de recuerdos y el modelo de vectores corren en local, y la extracción con un modelo barato sale por unos 0,0007 dólares por turno, alrededor de 1 dólar al mes (medido en septiembre de 2026).
Qué me llevo de todo esto
Cuando monté mi primer agente pensaba en la memoria como en un disco duro: cuanto más grande, mejor. Hoy la veo más como la mesa de alguien que trabaja bien, que tiene poco encima y sabe dónde está lo demás. Las cuatro capas existen porque ninguna sirve sola: la mesa es pequeña, los pósits se llenan, el archivador devuelve fichas viejas y el resumen se deja cosas.
Lo que de verdad me ha cambiado la forma de trabajar es aceptar que la memoria no es un sitio donde guardar, sino un proceso que hay que mantener: escribir con criterio, caducar lo que caduca, archivar antes de borrar y medir si funciona en vez de suponerlo. Mis 1.320 recuerdos de hoy no valen por ser muchos. Valen si el que aparece mañana sigue siendo verdad.
Esta guía es el punto de partida del bloque de memoria y contexto del hub de agentes. Los casos concretos irán colgando de aquí.