Publicado el 20 October 2026
“Dale memoria al agente” es uno de esos requisitos que parecen sencillos hasta que intentas implementarlos. En la práctica, la memoria no es una sola función: son varios mecanismos distintos que resuelven problemas diferentes, y confundirlos es una de las razones más comunes por las que los agentes de AI en producción olvidan cosas que no deberían o recuerdan cosas que los hacen más lentos, más caros y, a veces, incorrectos.
Antes de añadir memoria a un agente, conviene ser preciso sobre qué tipo de memoria necesita realmente una tarea concreta, porque la memoria a corto y largo plazo en los sistemas de agentes no son solo “lo mismo a distinta escala temporal” — son problemas arquitectónicos diferentes.
Memoria a corto plazo: gestión de la ventana de contexto
La memoria a corto plazo en un agente es, en la práctica, gestión de la ventana de contexto: lo que se incluye en el prompt para la tarea actual para que el modelo tenga lo que necesita para actuar. Esto incluye los intercambios recientes de la conversación, los resultados de llamadas a herramientas realizadas antes en la misma sesión y cualquier razonamiento intermedio que el agente necesite seguir mientras resuelve una tarea de varios pasos.
Aquí el reto no es el almacenamiento, sino la relevancia y el coste. Cada token en la ventana de contexto cuesta dinero y atención; volcar todo el historial de la conversación y todos los resultados de las herramientas en cada llamada posterior degrada el rendimiento y dispara la latencia y el gasto. Los sistemas de agentes en producción suelen necesitar una estrategia deliberada para decidir qué permanece en el contexto activo: resumir los turnos antiguos, descartar las salidas de herramientas una vez que su resultado ya se ha incorporado a una decisión, y volver a obtener detalles solo cuando realmente hagan falta otra vez, en lugar de mantenerlos cargados “por si acaso”.
Memoria a largo plazo: qué debe persistir entre sesiones
La memoria a largo plazo es un problema completamente distinto: ¿qué debería seguir sabiendo el agente la próxima vez que se invoque, quizá días o semanas después, en una sesión diferente, posiblemente para otro usuario o tarea? Aquí es donde se toman la mayoría de las decisiones de arquitectura, porque la memoria a largo plazo necesita responder preguntas como:
- ¿Se trata de un dato sobre un usuario o cliente concreto (preferencias, historial, decisiones previas) que deba recuperarse bajo demanda y no cargarse por completo cada vez?
- ¿Se trata de un dato sobre la empresa o el dominio (políticas, catálogo de productos, resultados anteriores) que pertenece a un repositorio de conocimiento compartido y no a una sola conversación?
- ¿Es este estado operativo —dónde quedó un flujo de trabajo de varios pasos— algo que deba sobrevivir a un reinicio o a un traspaso a una instancia distinta del agente?
Cada uno de estos casos suele encajar en un patrón de almacenamiento distinto: un almacén vectorial o una base de datos estructurada para memoria basada en recuperación (la mecánica es la misma que hay detrás de retrieval-augmented generation), un registro relacional para el flujo de trabajo y el estado operativo, y a veces un almacén clave-valor mucho más simple para datos pequeños y de acceso frecuente que no necesitan búsqueda semántica en absoluto.
Por qué “guardar todo y recuperarlo” no funciona bien
Un error temprano muy común es tratar la memoria a largo plazo como un cajón sin distinguir: cada interacción se convierte en un embedding y se almacena, y cada nueva tarea recupera memorias “relevantes” mediante búsqueda por similitud. Esto suele degradarse de una forma concreta y predecible a medida que crece el almacén de memoria: la recuperación empieza a mostrar datos plausibles pero desactualizados o contradictorios, y el comportamiento del agente se vuelve más difícil de razonar porque nadie puede decir con certeza qué “sabe” en un momento dado.
Los sistemas de memoria en producción necesitan la misma disciplina que cualquier otro almacén de datos: los hechos deben tener una fuente clara, una forma de actualizarse o invalidarse cuando cambian y, idealmente, un alcance que limite lo que se incorpora a cada tarea. Un agente que atiende soporte al cliente no necesita acceso sin restricciones a cada memoria guardada sobre cada cliente: necesita las memorias correctas, acotadas al cliente y la tarea actuales, recuperadas de forma deliberada y no volcada en bloque.
Las barreras de seguridad importan más en la memoria que en la mayoría de los demás componentes del agente
La memoria es también donde afloran muchas de las preguntas más complejas de barreras de seguridad en el diseño de agentes. Si un agente puede escribir en su propia memoria a largo plazo, ¿qué impide que almacene algo incorrecto y luego actúe una y otra vez sobre ese dato erróneo en sesiones futuras? Si la memoria persiste entre usuarios o inquilinos, ¿qué evita que los datos de un usuario se filtren al contexto de otro a través de un almacén de recuperación compartido? No son casos límite: son preguntas estándar en cualquier diseño de memoria para producción, y necesitan respuesta antes de que un agente entre en vivo con permiso de escritura sobre su propia memoria, no después de un incidente.
Un marco práctico para decidir qué debe recordar un agente
En lugar de asumir “guardar todo”, es más útil clasificar lo que un agente concreto necesita recordar en tres grupos y diseñar el almacenamiento para cada uno:
- Memoria acotada a la tarea — existe solo durante una tarea o sesión concreta y se descarta después. No hace falta ninguna infraestructura especial más allá de una gestión cuidadosa del contexto.
- Memoria acotada a la entidad — datos vinculados a un cliente, caso o registro específico, que se recuperan cada vez que esa entidad vuelve a aparecer. Es la forma más común de memoria a largo plazo “útil” en agentes de negocio.
- Memoria acotada al dominio — conocimiento compartido que se aplica a todas las tareas y usuarios, y que normalmente se gestiona mejor con una base de conocimiento adecuada o un sistema RAG que con el propio mecanismo de memoria del agente.
Gran parte del valor de la memoria de un agente surge de acertar con la memoria acotada a la entidad — de forma fiable, con reglas claras de actualización e invalidación — más que de construir una arquitectura de memoria general cada vez más sofisticada que intente tratar los tres casos por igual.
Por dónde empezar
Si estás creando o evaluando un sistema de agentes y la memoria sigue apareciendo como un requisito difuso, el ejercicio útil consiste en revisar las tareas reales que el agente debe ejecutar y preguntarse, en cada una, qué necesita recordar de verdad y desde dónde. La mayoría de las veces, ese ejercicio revela que el agente necesita mucha menos “memoria” en sentido genérico y una recuperación mucho más precisa desde un pequeño número de fuentes bien definidas, lo que es un sistema bastante más fácil y fiable de construir y mantener. Ayudamos a los equipos a diseñar arquitecturas de agentes, incluidas las capas de memoria y recuperación, que resisten cargas reales de producción; contáctanos si estás trabajando en esto para tu propio desarrollo de agente.
Relacionado