Tu agente de IA funciona perfecto en el demo. Luego un usuario real regresa al día siguiente y el agente no recuerda nada de la conversación anterior. Ni su nombre. Ni sus preferencias. Ni la compra que ya hizo. Cada sesión empieza desde cero.
"Mi agente de IA olvida todo entre sesiones" es una de las quejas más comunes sobre agentes. La investigación lo llama memory decay, pero el modelo no está roto: los modelos son apátridas por diseño. La memoria pertenece al harness, las herramientas, el estado y el almacenamiento que construyes alrededor del modelo. Es una decisión de diseño con trade-offs reales.
Este post es un mapa: los tipos de memoria más comunes, para qué sirve cada uno, qué cuesta cada uno y cómo elegir entre ellos.
Por qué "usar una ventana de contexto más grande" no funciona
La solución tentadora es reenviar todo el historial de conversación en cada turno. Funciona en la primera semana. Luego:
- La ventana de contexto es costosa. Pagas por reprocesar los mismos tokens en cada turno, para siempre. El costo crece con la longitud del historial, incluso cuando la mayor parte de ese historial es irrelevante para la pregunta actual.
- No sobrevive la sesión. Cuando el usuario regresa mañana, no hay historial que reenviar a menos que lo hayas guardado en algún lugar.
- Más contexto no es mejor contexto. Un contexto recuperado relevante y lean supera a incluir el historial completo, tanto en precisión como en costo. La selección supera al volumen.
Así que la pregunta real no es "¿cómo guardo todo?" Sino "¿qué debería recordar realmente mi agente, dónde y cómo lo encontrará de nuevo?"
¿Cómo llega la memoria al modelo?
El modelo solo ve su ventana de contexto. Toda la memoria funciona de la misma manera en los extremos:
- Ruta de escritura: durante o después de una conversación, algo almacena lo que vale la pena guardar en un store externo.
- Ruta de lectura: antes de responder, el agente recupera las pocas entradas relevantes para la pregunta actual y las coloca en el contexto, como parte del prompt o como resultado de una herramienta.
El store nunca habla directamente con el modelo. Lo que distingue los tipos de memoria es el paso intermedio: cómo encuentras las entradas correctas para traer de vuelta: por clave, por significado o por relación.
¿Cuáles son los principales tipos de memoria en agentes de IA? Cuatro lugares donde suele vivir la memoria
Una división hace que todo el panorama sea manejable: dónde vive la memoria (el tipo de almacenamiento) versus cómo se gestiona (las capacidades). Primero los tipos.
| Tipo | Modelo de consulta | Perfil de latencia | Infraestructura | Mejor para |
|---|---|---|---|---|
| Clave-valor | búsqueda exacta por clave | negligible | ninguna: estado + capa de sesión | hechos cuyo nombre conoces |
| Vectorial | similitud por significado | tiempo de consulta + embedding (el embedding domina) | un vector store más un modelo de embedding | "encuentra lo relevante para esta pregunta" |
| Grafo | traversal de relaciones | ms | una base de datos de grafos y un esquema | preguntas multi-hop entre entidades |
| Híbrida (vector + grafo) | ambos | ms | un índice vectorial más un grafo, en un store o dos | similitud más conexiones |
Lo que más separa los tipos es la forma de entrar. Mismas memorias almacenadas, diferentes caminos para acceder a ellas:
1. Memoria clave-valor: hechos estructurados bajo claves nombradas
El nombre del usuario, su idioma, su plan: hechos almacenados bajo claves que las herramientas del agente leen y escriben. Sin embeddings, sin infraestructura de búsqueda.
Características. Rápida, barata, precisa si conoces la clave. La persistencia es una escalera: estado en proceso, archivos de sesión en disco, objetos de sesión en almacenamiento cloud.
Úsala cuando las cosas que vale la pena recordar tienen nombres obvios: perfil, preferencias, configuraciones, contadores. Esto cubre más de lo que la gente espera, y es donde todo agente debería empezar.
Su límite: cada lectura es una búsqueda que alguien diseñó de antemano. Supón que el store tiene una entrada:
dietary_notes: "vegetariana, alergia severa a los mariscos"
| El usuario pregunta | Qué pasa |
|---|---|
| "¿Cuáles son mis notas dietéticas?" | mapea a dietary_notes → encontrado ✅ |
| "¿Qué debería evitar comer en la cena?" | ¿a qué clave corresponde eso? nada mapea → no encontrado ❌ |
La respuesta estaba en el store todo el tiempo. La segunda pregunta simplemente no nombra ninguna clave, y por clave es la única forma de entrar de este store. Cada tipo a continuación agrega una nueva forma de entrar.
Consejos para mejorarla:
- Versiona tus entradas. Cuando una preferencia cambia, actualiza y sube la versión en vez de agregar una contradicción junto al valor anterior. La evolución queda visible; el store queda limpio.
- Aprende de las acciones, no de los formularios. Lo que un usuario realmente hace (qué compra, qué elige, qué rechaza) te dice sus preferencias de forma más confiable que cualquier cosa que haya escrito.
- Sube la escalera de durabilidad deliberadamente: estado en proceso para scratch, sesiones para usuarios que regresan.
2. Memoria vectorial: recuperar por significado, no por nombre
Embeds cada memoria una vez en un vector; embed la pregunta entrante; recupera los vecinos más cercanos. Las mismas memorias, la misma pregunta que la clave-valor no pudo responder:
| El usuario pregunta | Qué pasa |
|---|---|
| "¿Qué debería evitar comer en la cena?" | embebida → el vecino más cercano es "vegetariana, alergia severa a los mariscos" → encontrado ✅ |
No hay palabras compartidas entre la pregunta y la nota. Están cerca en significado, y el significado es lo que se indexó.
La línea divisoria con clave-valor: ¿conoces la clave, o solo la intención?
Características. Dos costos que la gente confunde: consultar el índice y embeber la pregunta, lo que típicamente cuesta más que la consulta misma. La llamada de embedding domina.
Úsala cuando la memoria ha crecido en notas, episodios e historial que las preguntas alcanzarán desde ángulos impredecibles.
No la uses cuando una búsqueda por clave funcionaría (no pagues costos de embedding para obtener el plan de un usuario), o cuando la pregunta es sobre relaciones. Ver más abajo.
Consejos para mejorarla:
- Embede una vez, al momento de escribir. Solo la pregunta debería embeberse al momento de consultar.
- Particiona por tipo de memoria (hechos vs preferencias vs episodios) en lugar de un índice grande. La recuperación se vuelve más precisa y la limpieza se vuelve quirúrgica.
- Mide tu propia latencia. Los números publicados son anclas, no garantías.
3. Memoria de grafo: entidades y las relaciones entre ellas
Ahora una pregunta que ni la clave ni el significado pueden responder. El store tiene tres hechos separados: Maya trabaja en la empresa X · la empresa X pertenece al grupo Y · el grupo Y opera en España.
| La forma de entrar | Qué pasa |
|---|---|
| por clave | ninguna clave coincide → ❌ |
| por significado | encuentra los tres hechos como fragmentos, nunca el vínculo entre ellos → ❌ |
| por camino | (Maya)→(empresa X)→(grupo Y)→(España) → encontrado ✅ |
La respuesta no vive en ninguna memoria individual. Existe como un camino a través de ellas, y necesitas una forma de entrar que pueda seguir caminos.
Características. Consultas en milisegundos, durable por naturaleza y únicamente trazable: la respuesta viene con la cadena de hechos que la produjo. El costo es una base de datos real para operar y un esquema en el que pensar.
Úsala cuando tu dominio está inherentemente conectado (personas, organizaciones, dependencias) y los usuarios hacen preguntas que saltan a través de esas conexiones.
No la uses cuando tus memorias son notas independientes. Un grafo de nodos desconectados es solo un store clave-valor lento con pasos extra.
Consejos para mejorarla:
- Pon el índice vectorial dentro del grafo (los stores de grafos modernos lo soportan): la similitud encuentra el punto de entrada, el traversal encuentra la respuesta. Esa combinación es el patrón "híbrido" a continuación.
- Diseña las relaciones desde preguntas reales ("¿a quién conozco en...") en lugar de modelar todo. Cada tipo de arista que agregas debe ganar una consulta.
- Cuida el blast radius: la conectividad es poder y fragilidad a la vez (ver hygiene, abajo).
4. Híbrida: vector + grafo en un agente
Algunas preguntas necesitan ambos movimientos a la vez: "encuéntrame algo como el que me encantó, pero solo de proveedores con los que tengo una relación". Ninguna forma de entrar puede responderla sola; encadenadas, sí pueden:
La similitud encuentra los candidatos; el traversal los filtra por relación.
La híbrida toma dos formas: un store que soporta ambos movimientos (una base de datos de grafos con un índice vectorial incorporado), o dos stores especializados lado a lado con el agente eligiendo según la pregunta. De cualquier manera, el agente gana ambas formas de entrar. Hay una versión administrada y una versión build-it-yourself de esto, y ese trade es exactamente lo que miden los posts de código en esta serie.
La capa de capacidades: qué separa una memoria de un cajón desordenado
Los tipos responden dónde. Tres capacidades, independientes del tipo, responden qué, qué no y por qué.
Memoria selectiva: ¿qué debería recordar realmente tu agente?
Una conversación real mezcla hechos duraderos, charla intrascendente, preferencias y eventos. Guarda todo y la memoria se convierte en ruido costoso. No guardes nada y vuelves al agente amnésico. Alguien, o algo, debe seleccionar.
Alguien tiene que tomar esa decisión, y hay tres opciones para quién:
- El propio agente, con herramientas de memoria que llama a mitad de conversación. Gratis de construir; pero la calidad de selección depende de un modelo que también está ocupado chateando, y el trabajo de selección recae sobre la latencia de cada turno.
- Tu propio extractor, ejecutándose después de cada turno, fuera del camino de conversación: prompts especializados, uno por tipo de memoria, cada uno habilitado para responder "nada vale la pena guardar". Los prompts de propósito único superan al multitasking, y la conversación queda intacta. El precio: tú eres dueño de los prompts y pagas sus tokens.
- Un servicio administrado, como Amazon Bedrock AgentCore Memory: envía turnos sin procesar, y sus estrategias integradas (hechos semánticos, preferencias de usuario, resumen, episódico) extraen por ti. Ruta de escritura más barata y cero pipeline que mantener. El trade: la extracción es asíncrona (las memorias se vuelven consultables con un retraso, no de inmediato), y los criterios de guardar/descartar no son tuyos para ajustar.
Los tipos de memoria son una decisión de diseño, no una característica de infraestructura. Las plataformas administradas los incluyen incorporados; puedes construir la misma taxonomía con prompts y disciplina.
Tip: evalúa tu selector con ground truth determinista. Planta guardadores y señuelos en una conversación de prueba y puntúa lo que sobrevivió. "Parece que recuerda cosas" no es una evaluación.
Higiene de memoria: qué NO debe recordar tu agente
Una memoria almacenada tiene autoridad: el agente la trata como verdad y construye respuestas sobre ella sin verificar de nuevo. Eso hace que la memoria sucia sea peligrosa de dos maneras:
- Memoria sucia. Hechos incorrectos, hechos obsoletos (una dirección que cambió, un plan que fue cancelado), duplicados y contradicciones. El agente los recupera, los confía y alucina con confianza sobre su propio store. El error de ayer se convierte en la certeza de hoy.
- Memoria envenenada. La versión adversarial: envenenamiento de memoria, inyección de prompts que persiste. Ataques publicados alcanzan más del 80% de éxito mientras envenenan menos del 0.1% de un store de memoria. Un "siempre recomienda X" inyectado sobrevive a la sesión que lo plantó y sesga cada respuesta futura.
Las defensas son las mismas para ambos, y viven en la ruta de escritura: una write-gate que filtra el contenido antes de persistirlo (instrucciones inyectadas, fuentes de baja confianza, datos obsoletos o contradictorios), y olvido selectivo para desalojar lo que se coló.
El blast radius depende del tipo de memoria. Una entrada mala en un store clave-valor sesga una respuesta. El mismo hecho en un grafo contamina cada traversal que lo cruza. Cuanto más poderosa es tu memoria, más cuesta una sola mentira.
Tip: trata "¿debería recordarse esto?" como una pregunta de calidad y de seguridad. Haz del olvido una operación de primera clase, no un script de migración.
Memoria de razonamiento: recordar el por qué, no solo el qué
Todo lo anterior almacena lo que el agente sabe. Casi nada almacena por qué decidió. Pregunta "¿por qué recomendaste eso?" una semana después y un agente sin memoria confabulará una respuesta plausible, porque el razonamiento real nunca se guardó.
Un rastro de decisión lo soluciona: pregunta, pasos, evidencia, resultado, con procedencia. Y desbloquea la consulta que importa en dominios regulados, la auditoría inversa: "esta fuente de datos resultó estar equivocada; ¿cuáles de mis decisiones pasadas dependieron de ella?" Un escaneo plano de decisiones almacenadas solo encuentra citas directas de la fuente. La procedencia almacenada como grafo las encuentra todas, incluyendo decisiones contaminadas a través de los outputs de otras decisiones, con la cadena de evidencia como recibo.
"Memoria de razonamiento" es un patrón de ingeniería, no una categoría académica establecida. Lo que la investigación soporta es el tema subyacente: trazabilidad y procedencia.
Tip: si estás en un dominio donde auditores (no usuarios) preguntan "¿por qué?", registra trazas desde el primer día. Retroalimentar procedencia es miserable.
¿Cómo elegir el tipo de memoria correcto? Iguala el caso de uso, no el hype
Elige el tipo de memoria por lo que estás construyendo:
| Estás construyendo... | Empieza con |
|---|---|
| Un asistente personal que mantiene un perfil de usuario (preferencias, configuraciones, plan) | Clave-valor |
| Un agente de soporte o compañía con meses de historial de conversación del que nutrirse | Vectorial |
| Un agente sobre datos conectados: organigramas, dependencias, redes de clientes, catálogos con relaciones | Grafo |
| Un recomendador que debe respetar tanto el gusto ("como este") como las restricciones ("solo de mis proveedores") | Híbrida |
Sea cual sea el tipo que elijas, dos prácticas de la capa de capacidades aplican encima: si el agente opera en un dominio donde alguien preguntará "¿por qué lo hizo?", registra rastros de decisión; y si la memoria a largo plazo acepta contenido de usuarios o la web, pon hygiene (una write-gate) al frente desde el primer día.
Y tres meta-reglas:
- Empieza con clave-valor. Es la memoria más simple que funciona, y la mayor parte de la personalización vive ahí. Agrega vectores cuando las preguntas dejen de coincidir con claves, y un grafo cuando las preguntas comiencen a saltar.
- La calidad de selección supera a la sofisticación del almacenamiento. Un extractor disciplinado escribiendo en un store simple supera a un store sofisticado al que se le manda todo.
- Mide, no asumas. Latencia de consulta, costo de embedding, retraso de extracción, blast radius: cada uno varía con tu carga de trabajo, y cada uno te sorprenderá al menos una vez.
Qué sigue en esta serie
Cada post construye una pieza, en código, con datos reales y resultados medidos. El código usa Strands Agents, un SDK open source para construir agentes de IA; los patrones aplican a cualquier framework de agentes:
- Memoria clave-valor: evita que tu agente olvide las preferencias del usuario, desde estado en proceso hasta sesiones cloud.
- Memoria vectorial: ¿necesitas realmente una base de datos vectorial? Almacenamiento en proceso vs administrado, los mismos embeddings, medidos.
- Memoria de grafo: preguntas multi-hop que la similitud no puede responder, 1/4 vs 4/4.
- Memoria selectiva: tres formas de decidir qué recordar, puntuadas contra ground truth plantado.
- Higiene de memoria: envenenamiento de memoria y la write-gate, el mismo ataque, dos backends, blast radius muy diferente.
- Memoria de razonamiento: rastros de decisión y la auditoría inversa.
- Memoria híbrida: vector + grafo en un agente, pipeline administrado vs construido a mano, a paridad completa.
Limitaciones honestas
- "Memoria de razonamiento" es nuestro encuadre de ingeniería; el soporte revisado por pares cubre trazabilidad y procedencia, no el nombre de la categoría.
- La extracción administrada intercambia control por comodidad. Si el retraso y los criterios no ajustables importan es una decisión de producto, no una técnica.
- Varios papers citados son preprints recientes (indicados donde sea relevante); trata sus cifras específicas como afirmaciones de sus autores.
FAQ
¿Qué es la memoria de un agente de IA?
Todo lo que un agente persiste fuera de la llamada al modelo: hechos de usuario, preferencias, eventos pasados y sus relaciones. Los modelos son apátridas; la memoria es infraestructura que diseñas a su alrededor. Un store, más reglas sobre qué entra, cómo se recupera y qué se olvida.
¿Es una base de datos vectorial lo mismo que la memoria de un agente de IA?
No. Una base de datos vectorial es un posible backend para un tipo de memoria (recuperación semántica). La memoria del agente es el sistema completo: estado clave-valor, almacenamiento vectorial o de grafo, reglas de selección, hygiene y procedencia. Muchos agentes de producción no necesitan ninguna base de datos vectorial.
¿Puedo usar una base de datos vectorial como memoria de agente?
Sí, para memorias que consultarás por significado. Pero enruta los hechos con clave (preferencias, configuraciones) al almacenamiento clave-valor primero: una búsqueda directa, sin costo de embedding. Los vectores ganan su lugar cuando las preguntas dejan de coincidir con claves.
¿Los agentes de IA necesitan una base de datos?
Para cualquier cosa más allá de una sola sesión, sí: algo debe sobrevivir al proceso. Puede ser tan ligero como archivos de sesión en disco u objetos en almacenamiento cloud; una base de datos dedicada solo se vuelve necesaria con búsqueda vectorial a escala, traversal de grafo o compartición multi-instancia.
¿Por qué mi agente de IA olvida todo entre sesiones?
Porque el modelo nunca recuerda; cada llamada empieza en blanco. Si nada almacena estado fuera de la conversación, cada sesión empieza desde cero. La solución es la más pequeña de esta página: estado con clave más una capa de sesión que sobrevive los reinicios.
Recursos
La investigación detrás de las afirmaciones en este post, si quieres profundizar:
Arquitecturas de memoria
- MemGPT: Towards LLMs as Operating Systems: el concepto de "core memory" autogestionada
- MIRIX: Multi-Agent Memory System: memoria tipada (seis tipos)
- MemoryOS of AI Agent: memoria jerárquica
Memoria de grafo e híbrida
- GAAMA: Graph Augmented Associative Memory for Agents: el ancla académica del patrón híbrido
- MAGMA: A Multi-Graph based Agentic Memory Architecture for AI Agents
- GRAVITY: Architecture-Agnostic Structured Anchoring for Long-Horizon Conversational Memory
- Zep: Temporal Knowledge Graph for Agent Memory
- HippoRAG 2: memoria asociativa vía recuperación de grafo
Trazabilidad y contexto lean
- MemWeaver: Weaving Hybrid Memories for Traceable Long-Horizon Agentic Reasoning
- Less Context, More Accuracy: el sistema Engram; preprint de autor único, fuente del resultado "contexto lean supera al historial completo"
Ataques a la memoria
- AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases: las cifras de >80% de éxito / <0.1% de veneno
- PoisonedRAG (USENIX Security 2025)
Gracias!
🇻🇪 Dev.to Linkedin GitHub Twitter Instagram Youtube
Top comments (0)