Susana López Blanco Un cliente vuelve seis meses después. Durante ese tiempo rechazó una oferta, cambió de responsable dentro de su empresa, tuvo dos incidencias, compró otro producto y mantuvo conversaciones con ventas, soporte y administración. Parte de aquella historia sigue siendo útil. Otra parte ha caducado. Algunas cosas que eran ciertas en febrero ya no lo son en agosto.
El agente vuelve a encontrárselo. Puede recibir todos los correos, tickets, llamadas, notas del CRM y conversaciones anteriores antes de responder. Funcionará durante un tiempo. Cuando la relación acumule años, estaremos enviando una montaña de pasado para resolver una tarea que quizá dependa de tres hechos: quién decide ahora, qué ocurrió en la última negociación y qué compromiso sigue pendiente.
Guardar conversaciones resulta relativamente sencillo. Conseguir que seis meses después el sistema encuentre esos tres recuerdos, descarte cien irrelevantes y detecte que uno dejó de ser cierto exige diseño. Una memoria para agentes de IA tiene que seleccionar qué conserva, qué recupera, cuánto confía en ello, cuándo debe actualizarlo y durante cuánto tiempo puede seguir utilizándolo.
Este problema está en que los agentes de IA en la empresa dejan de resolver tareas aisladas y empiezan a participar en relaciones o procesos que duran semanas y meses. Aquí nos ocuparemos únicamente de esa continuidad. La infraestructura común de datos, herramientas, modelos y orquestación pertenece a otra decisión y la desarrollamos aparte en nuestra guía de arquitectura de IA a largo plazo.
Índice de contenidos
Una ventana de contexto enorme acaba llena de pasado
El modelo trabaja con un contexto: instrucciones, conversación reciente, resultados de herramientas, documentos recuperados y cualquier otra información que le entreguemos para resolver la tarea. Las ventanas disponibles son cada vez mayores, pero utilizarlas como archivo histórico produce una memoria bastante rudimentaria.
Imaginemos un agente que atiende durante dos años al mismo cliente. Podemos reconstruir cada sesión añadiendo todas las conversaciones anteriores. También podemos resumirlas e incorporar una y otra vez ese resumen. Ambos caminos terminan arrastrando hechos que ya no afectan a la decisión actual, versiones antiguas y detalles que ocupan espacio sin aportar demasiado.
Nadie relee cinco años de correo antes de contestar un mensaje. Busca el contrato vigente, recuerda la última negociación, comprueba qué ocurrió con una incidencia y quizá consulta quién tomó una decisión concreta. Una memoria persistente debería aproximarse a ese comportamiento: mantener la historia fuera del contexto inmediato y recuperar una pequeña parte cuando la tarea la reclama.
Esa separación permite además conservar la experiencia fuera del modelo. Una conversación puede terminar y el recuerdo seguir disponible. Otra aplicación puede utilizarlo después. Si cambia el proveedor de IA, la empresa mantiene la historia que acumuló durante meses. La independencia tecnológica completa pertenece al diseño de arquitectura, pero esta decisión concreta empieza aquí: la memoria duradera vive fuera del contexto efímero del modelo.
Qué papel cumple RAG cuando un agente necesita recordar
RAG, siglas de Retrieval-Augmented Generation, añade una fase de recuperación antes de generar una respuesta. Ante una consulta, el sistema busca fragmentos relacionados en una colección externa y entrega al modelo únicamente una selección.
En una empresa funciona especialmente bien con conocimiento documental: políticas, contratos, procedimientos, documentación técnica, manuales o bases de conocimiento. Un agente que responde sobre devoluciones puede recuperar la política aplicable sin cargar el manual completo.
La memoria añade acontecimientos y experiencia. El cliente pidió una excepción en abril. El equipo la aprobó. Una propuesta fue rechazada por precio. La última incidencia terminó con un abono. El responsable comercial acordó volver a contactar después del verano.
Ambas cosas conviven. RAG ayuda a recuperar conocimiento que está en documentos; la memoria persistente conserva además hechos ocurridos durante la relación y conclusiones que se han ido consolidando. En los dos casos hay recuperación, aunque un recuerdo necesita más información alrededor: fecha, procedencia, entidad a la que afecta, vigencia, nivel de confianza y posibles versiones posteriores.
Los embeddings y la búsqueda vectorial son útiles para localizar contenido semánticamente parecido. Una consulta real puede necesitar también filtros por cliente, proyecto, fecha, tipo de recuerdo, estado o permiso de acceso. Quien quiera profundizar en esta parte encontrará una relación directa con representación de datos, recuperación y evaluación en nuestro Máster en Data Science: Big Data e Inteligencia Artificial.
Qué merece quedarse en la memoria
Una conversación de veinte minutos puede generar centenares de frases. Convertir cada una en un recuerdo permanente llenaría enseguida el repositorio de observaciones triviales. Resumir demasiado crea el riesgo contrario: desaparecen detalles que meses después podían explicar una decisión.
Conviene definir criterios de selección. Pueden formalizarse en un scoring de memoria, siempre que represente decisiones comprensibles y no una fórmula inventada para dar apariencia científica al sistema.
- Relevancia: probabilidad de que el dato ayude en tareas futuras.
- Impacto: consecuencias de olvidarlo. Una excepción contractual pesa más que una preferencia estética puntual.
- Confianza: certeza que tenemos sobre lo registrado.
- Fuente: ERP, CRM, correo, cliente, empleado, documento o inferencia del modelo.
- Vigencia: tiempo durante el que esperamos que siga describiendo la situación.
- Frecuencia: diferencia entre un episodio aislado y un patrón repetido.
- Novedad: información nueva frente a hechos ya conocidos.
- Sensibilidad: restricciones de conservación y acceso.
Una queja puntual puede conservarse como episodio. Veinte incidencias parecidas durante un año quizá justifiquen una conclusión más estable: «este cliente tiene problemas recurrentes con la facturación internacional». Esa conclusión debería mantener el rastro de los episodios que la originaron. Si alguien pregunta meses después por qué aparece en la memoria, podremos reconstruir la evidencia.
El scoring también ayuda al recuperar. Una consulta comercial puede priorizar decisiones recientes y compromisos pendientes. Una reclamación necesitará episodios concretos y documentos. Una revisión de cuenta puede buscar patrones acumulados durante meses. Recuperar siempre los cinco recuerdos semánticamente más parecidos desperdicia fecha, importancia y contexto empresarial.
Cuatro memorias para cuatro necesidades distintas
Separar tipos de memoria ayuda a decidir qué conservar y cómo recuperarlo. Estas cuatro categorías resultan prácticas en sistemas empresariales sin necesidad de convertir el diseño en una lección de psicología.
Memoria de trabajo
Mantiene temporalmente lo necesario para terminar la tarea actual. Si el agente está resolviendo una devolución, conserva el pedido, el motivo, la política aplicable, los pasos ya ejecutados y cualquier excepción activa. Al terminar, buena parte de ese material deja de tener valor.
Memoria episódica
Registra acontecimientos. «El 14 de mayo el cliente rechazó la propuesta porque superaba su presupuesto». El episodio conserva qué ocurrió y cuándo ocurrió. Resulta útil para reconstruir una negociación, una incidencia o una decisión anterior.
Memoria semántica
Conserva hechos y conocimiento ya consolidados. «La empresa factura en dólares». «El cliente prefiere recibir propuestas por correo». «El proyecto utiliza SAP». Una memoria semántica bien mantenida evita redescubrir en cada conversación información relativamente estable.
Memoria procedimental
Guarda formas de actuar que conviene reutilizar: reglas, instrucciones, secuencias de trabajo o procedimientos. Puede recoger que determinadas incidencias requieren validación humana antes de emitir un abono o que cierto tipo de contrato debe revisarse siempre por una persona concreta.
Un mismo proceso utiliza normalmente varias. La memoria de trabajo ayuda a terminar lo que ocurre ahora; la episódica reconstruye lo que pasó; la semántica aporta conocimiento consolidado; la procedimental orienta la actuación. Esta relación entre agentes, workflows y aplicaciones empresariales forma parte del trabajo práctico de nuestro Máster en Agentes IA y Automatización No-Code.
Un recuerdo necesita fecha, fuente y contexto
Supongamos que la memoria contiene esta frase: «Ana es la directora financiera». Era correcta cuando se registró en febrero. En junio Ana dejó la compañía y Carlos asumió el puesto. En septiembre una búsqueda semántica podría seguir recuperando la afirmación antigua porque encaja perfectamente con una consulta sobre finanzas.
Guardar solo el texto del recuerdo elimina información necesaria para interpretarlo. Conviene registrar cuándo ocurrió el hecho, cuándo lo conocimos, quién o qué sistema lo aportó, a qué persona, empresa o proyecto afecta y durante cuánto tiempo esperamos que siga vigente. Cuando conocemos fecha de inicio o fin, ambas deberían acompañarlo.
La procedencia tiene un peso especial. En una misma memoria pueden convivir «el ERP registra una deuda de 12.400 euros», «el cliente asegura que ya pagó la factura» y «el modelo estima que probablemente existe un error de conciliación». Las tres afirmaciones pueden resultar útiles, pero ofrecen niveles de evidencia muy distintos. Si perdemos la fuente, meses después aparecen como recuerdos equivalentes.
También conviene distinguir hechos de inferencias. «El cliente pidió tres veces hablar por correo» describe acontecimientos observados. «Prefiere el correo al teléfono» resume un patrón. La segunda afirmación puede ser razonable y útil, siempre que conserve su grado de confianza y el rastro que permitió construirla.
La temporalidad mantiene además la historia sin confundirla con el presente. Ana fue directora financiera; Carlos lo es ahora. Borrar a Ana dificultaría entender conversaciones antiguas. Conservar ambos datos sin fechas introduce ambigüedad. Versionarlos permite saber quién ocupaba el puesto en cada momento.
Qué hacemos cuando dos recuerdos se contradicen
Las relaciones empresariales cambian constantemente. Un responsable sustituye a otro, una tarifa negociada deja de aplicarse, una incidencia se resuelve, una preferencia cambia o un proyecto pasa de activo a cerrado. La memoria necesita una política explícita para tratar esas modificaciones.
Algunas contradicciones admiten actualización directa. Si el ERP confirma que Carlos ocupa ahora un cargo que antes correspondía a Ana, el estado actual puede actualizarse y la versión anterior permanecer en el histórico.
Otras situaciones justifican mantener dos versiones durante un tiempo. El cliente afirma que prefiere correo, pero en conversaciones recientes solicita repetidamente llamadas. En lugar de sobrescribir una preferencia por otra a la primera señal, el sistema puede reducir la confianza del recuerdo anterior y esperar nuevas evidencias.
También existen conflictos que conviene escalar. Un contrato dice que el precio acordado es uno y una nota comercial registra otro. Elegir automáticamente la versión más reciente sería temerario. La fuente, la autoridad de cada documento y la materialidad del dato deben influir antes de consolidar nada.
La consolidación ayuda cuando aparecen muchos episodios similares. Veinte interacciones pueden resumirse en un patrón, siempre que el sistema conserve de dónde salió. La memoria deja así de crecer únicamente mediante acumulación y empieza a organizar experiencia.
Recordar también cuesta: qué conviene olvidar
Una memoria que conserva todo durante años acumula ruido, versiones obsoletas, costes y riesgos de privacidad. Algunas observaciones pierden valor rápidamente. Otras deben mantenerse por razones contractuales o de auditoría. Algunas contienen datos sensibles cuyo periodo de conservación está limitado.
El olvido puede adoptar varias formas. Un recuerdo temporal caduca al terminar el proceso. Otro pierde prioridad a medida que envejece. Varios episodios pueden consolidarse en un resumen y dejar de recuperarse individualmente salvo que una auditoría los requiera. Ciertos datos deben borrarse cuando termina el periodo de conservación autorizado.
La frecuencia de uso ofrece otra señal. Un detalle recuperado regularmente durante meses probablemente merece permanecer accesible. Otro que nunca vuelve a influir en ninguna tarea puede descender de prioridad sin necesidad de eliminarse de inmediato.
El coste también cuenta. Buscar en millones de recuerdos, calcular embeddings, ejecutar filtros y añadir fragmentos al contexto consume infraestructura y tiempo. Una política de memoria debería poder explicar qué conserva a largo plazo, qué archiva, qué resume y qué elimina.
Una memoria puede vivir en varios sitios
Un único almacén rara vez sirve igual de bien para todos los recuerdos. Los hechos estructurados pueden vivir en SQL o en una base similar. Los acontecimientos ordenados en el tiempo encajan bien en un almacén de eventos. Los fragmentos textuales y los resúmenes pueden indexarse mediante embeddings en una base vectorial. Las relaciones complejas entre personas, empresas, proyectos y decisiones pueden justificar un grafo.
El estado de una ejecución tiene otra vida. El paso actual de un workflow, una aprobación pendiente o una herramienta que todavía no ha respondido pertenecen a la tarea en curso y pueden desaparecer cuando termina.
Un dato estable del ERP tampoco necesita copiarse necesariamente a una base vectorial para que el agente lo «recuerde». Puede consultarse en su fuente cuando haga falta. La memoria debería evitar duplicar de forma indiscriminada aquello que ya existe de manera fiable en otro sistema.
Esta distribución conecta con decisiones de infraestructura más amplias: data mart, eventos, modelos, APIs y herramientas compartidas. Desarrollamos esa parte en nuestra guía de arquitectura de IA a largo plazo, donde la memoria aparece como una pieza dentro de un diseño empresarial mayor.
Cuando varios agentes comparten recuerdos
Un proceso puede tener un agente que analiza solicitudes, otro que prepara una propuesta y otro que controla incidencias. Compartir ciertos recuerdos evita que cada uno reconstruya por separado la historia del cliente o del proyecto.
Conviene distinguir varios ámbitos. Una memoria privada pertenece a una ejecución o agente concreto. La memoria de proceso contiene decisiones que afectan al workflow. La memoria de cliente o proyecto puede ser utilizada por distintos participantes. La memoria compartida reúne hechos que varias aplicaciones necesitan consultar.
Los permisos deben aplicarse antes de recuperar. Si un agente de marketing carece de autorización para acceder a determinada información financiera o de recursos humanos, esa información ni siquiera debería llegar a la selección que recibe el modelo. Recuperarla primero y decidir después si podía verla expone datos innecesariamente.
También conviene controlar quién escribe. Un agente puede tener permiso para consultar una decisión jurídica sin poder modificarla. Otro puede proponer un nuevo recuerdo que necesite validación humana antes de consolidarse. Compartir memoria amplía su utilidad y también multiplica el efecto de cualquier error.
Cómo saber si la memoria está ayudando
Una memoria puede parecer convincente durante una demostración y degradar decisiones cuando empieza a acumular meses de historia. Por eso necesita pruebas específicas.
Podemos medir cuántos recuerdos recuperados resultan realmente relevantes, cuántos hechos necesarios se quedan fuera y qué porcentaje del material recuperado está desactualizado. También interesa observar contradicciones, inferencias incorrectas, coste y latencia.
Una prueba especialmente útil compara la misma tarea con y sin memoria. ¿La decisión mejora? ¿Se resuelve antes? ¿El agente evita preguntar algo que ya conocíamos? ¿Aumentan los errores porque recupera información antigua? ¿Cambia el resultado empresarial que queríamos mejorar?
También deben probarse casos difíciles. Qué ocurre cuando hay dos responsables distintos registrados. Cuando la misma preferencia aparece con fechas diferentes. Cuando un dato procede de una fuente fiable y otro de una inferencia. Cuando el recuerdo más parecido semánticamente está caducado.
Los falsos recuerdos merecen vigilancia especial. Un error puntual afecta a una respuesta. Si ese error se convierte en memoria persistente, puede volver a aparecer durante meses, reforzarse mediante nuevas decisiones y terminar pareciendo un hecho asentado. La escritura de recuerdos necesita controles tan serios como su recuperación.
Cómo empezaría a construir memoria sin crear un monstruo
Empezaría pequeño. Elegiría un proceso donde la continuidad tenga valor claro y conservaría primero los acontecimientos básicos: decisiones, compromisos, incidencias relevantes y cambios de estado.
Después seleccionaría unos pocos hechos persistentes que realmente eviten reconstruir la historia en cada ejecución. Añadiría RAG para recuperar documentación relacionada cuando el trabajo lo requiera. En ese punto ya podemos observar qué recuerdos ayudan y cuáles generan ruido.
El siguiente paso sería introducir criterios de memoria: relevancia, impacto, confianza, fuente, vigencia y sensibilidad. Cada recuerdo debería llevar fecha y procedencia desde el principio; incorporarlas meses después obliga a reconstruir una historia que quizá ya hemos perdido.
Cuando aparezcan contradicciones reales, añadiremos versionado y políticas de actualización. Cuando varios agentes necesiten la misma historia, abriremos el acceso gradualmente y con permisos explícitos. La evaluación debería acompañar cada ampliación.
Esta secuencia evita diseñar desde el primer día una memoria universal para toda la empresa. La experiencia enseña qué merece persistir, qué conviene resumir y qué termina ocupando espacio sin mejorar ninguna decisión.
Dentro de unos años utilizaremos modelos diferentes de los actuales. Los clientes seguirán teniendo historia, los proyectos acumularán decisiones y la empresa habrá cometido errores y aprendido de ellos. Si esa experiencia permanece bien fechada, documentada y accesible, un modelo nuevo podrá empezar a trabajar con años de contexto empresarial desde su primera ejecución.
Preguntas frecuentes sobre memoria para agentes de IA
¿Qué es la memoria a largo plazo de un agente de IA?
Es información persistente que sobrevive a una conversación o ejecución y puede recuperarse semanas o meses después. Puede incluir acontecimientos, hechos consolidados, preferencias, decisiones y procedimientos, acompañados de fecha, fuente y reglas de vigencia.
¿RAG es lo mismo que memoria?
RAG es un mecanismo de recuperación de información externa para incorporarla al contexto del modelo. Puede formar parte de un sistema de memoria, especialmente para conocimiento documental. La memoria persistente suele añadir acontecimientos, estado, temporalidad, procedencia y políticas para actualizar o olvidar recuerdos.
¿Qué diferencia hay entre memoria episódica y semántica?
La episódica conserva acontecimientos concretos: «el cliente rechazó la propuesta el 14 de mayo». La semántica conserva conocimiento consolidado: «el cliente tiene un presupuesto máximo de 20.000 euros», siempre que ese hecho siga vigente.
¿Conviene guardar todas las conversaciones?
El historial bruto puede mantenerse por razones operativas, legales o de auditoría, pero eso no obliga a utilizarlo completo como memoria activa. Conviene extraer hechos y episodios relevantes, consolidar patrones y recuperar únicamente aquello que ayuda a la tarea actual.
¿Cómo sabe un agente qué recuerdos recuperar?
La recuperación puede combinar similitud semántica con filtros y criterios como entidad, fecha, relevancia, impacto, confianza, vigencia y tipo de recuerdo. Una consulta sobre una reclamación y otra sobre una propuesta comercial deberían priorizar recuerdos diferentes.
¿Qué ocurre cuando un recuerdo deja de ser cierto?
Puede actualizarse, versionarse, perder confianza o quedar marcado como histórico. La elección depende del tipo de dato y de su fuente. Mantener fechas permite conservar lo ocurrido sin presentar una situación pasada como si todavía estuviera vigente.
¿Puede una memoria funcionar con distintos modelos de IA?
Sí, si la memoria se mantiene fuera del contexto interno del modelo y dispone de mecanismos propios de almacenamiento y recuperación. Distintas aplicaciones pueden consultar la misma historia respetando permisos y formatos. La arquitectura necesaria para hacerlo de forma estable pertenece al diseño general de infraestructura de IA.