Memoria para agentes: patrones que funcionan de verdad en producción
Todo framework de agentes promete memoria. Pocos la entregan bien. Esto es lo que funciona.
23 marzo, 2026
Todo framework de agentes promete memoria.
"Memoria persistente entre sesiones." "Aprendizaje a largo plazo." "Agentes que recuerdan."
Y luego intentas usarlo en producción.
Tu agent olvida contexto crítico a mitad de una conversación. La memoria se infla hasta que las respuestas se arrastran. El agente "recuerda" cosas que nunca ocurrieron. La recuperación saca memorias irrelevantes y se pierde las obvias.
He construido sistemas de memoria para agentes de resolución de disputas que manejan más de 15.000 casos, IA de marketing que mantiene la voz de marca a través de miles de interacciones, y asesores financieros que rastrean carteras complejas de clientes.
Esto es lo que aprendí: la memoria del agente es un problema de sistemas, no un interruptor de funcionalidad. Los frameworks te dan primitivas. Hacer que funcionen requiere arquitectura.
Por qué la memoria es difícil
Primero, entendamos por qué esto es más difícil de lo que parece.
La trampa de la ventana de contexto
Los LLM tienen ventanas de contexto. Grandes ahora—128K, 200K tokens. Así que ¿por qué no meterlo todo?
Porque la atención se degrada. Con 128K tokens, el modelo literalmente no puede atender a todo por igual. La información del medio se pierde. Los detalles relevantes se ahogan en el ruido.
Más contexto ≠ mejor memoria. A menudo significa peor.
El problema de la recuperación
"Simplemente usa RAG para la memoria" suena razonable hasta que lo intentas.
La recuperación de memoria es distinta de la recuperación de documentos:
- • Las consultas son implícitas (¿qué necesita saber el agente ahora mismo?)
- • La relevancia es contextual (la misma memoria es relevante en una situación, no en otra)
- • La cercanía en el tiempo importa (las interacciones recientes suelen pesar más que las antiguas)
- • Las relaciones importan (la memoria A es relevante por su conexión con la memoria B)
La similitud vectorial estándar no captura esto.
El problema de la obsolescencia
Las memorias se vuelven obsoletas. Las preferencias del usuario cambian. Los hechos se actualizan. Las relaciones evolucionan.
Un agente que "recuerda" tu restaurante favorito de hace dos años no es útil—es molesto. Los sistemas de memoria necesitan decaimiento, actualizaciones y resolución de contradicciones.
El problema de la consistencia
En sistemas multi-agente, varios agentes podrían acceder y actualizar memoria compartida simultáneamente. Sin coordinación, aparecen inconsistencias. El agente A cree que el usuario prefiere X. El agente B cree que prefiere Y. Sobreviene el caos.
La arquitectura de memoria que funciona
Después de construir varios sistemas en producción, he convergido en una arquitectura por capas:
Arquitectura de memoria de 4 capas
Capa 1: Memoria de trabajo
Contexto de la conversación actual. Vive en el prompt.
- • Mensajes recientes (últimos 5-10 turnos)
- • Estado activo de la tarea
- • Scratchpad para razonamiento
Capa 2: Memoria a corto plazo
Historial de sesiones e interacciones recientes.
- • Resúmenes de conversación
- • Decisiones recientes y su justificación
- • Preferencias y correcciones temporales
Capa 3: Memoria a largo plazo
Conocimiento persistente sobre usuarios, entidades, patrones.
- • Perfiles y preferencias de usuario
- • Relaciones entre entidades
- • Patrones e insights aprendidos
Capa 4: Memoria episódica
Interacciones pasadas específicas que podrían ser relevantes.
- • Conversaciones destacadas
- • Decisiones clave y resultados
- • Eventos importantes
Cada capa sirve a un propósito distinto. Cada una tiene características diferentes de almacenamiento, recuperación y ciclo de vida.
Capa 1: Memoria de trabajo
La memoria de trabajo es lo que está en el prompt ahora mismo. Es la conciencia inmediata del agente.
Qué va aquí
- • Los últimos N turnos de conversación (típicamente 5-10)
- • Descripción y estado actuales de la tarea
- • Contexto relevante recuperado de otras capas
- • Scratchpad para razonamiento chain-of-thought
El patrón: Ventana deslizante + resumen
class WorkingMemory:
def __init__(self, max_turns: int = 10, max_tokens: int = 4000):
self.max_turns = max_turns
self.max_tokens = max_tokens
self.turns = []
self.summary = ""
def add_turn(self, role: str, content: str):
self.turns.append({"role": role, "content": content})
# If exceeding limits, summarize older turns
if len(self.turns) > self.max_turns:
self._compress()
def _compress(self):
# Summarize oldest turns
old_turns = self.turns[:5]
new_summary = llm.summarize(old_turns)
# Update summary and remove old turns
self.summary = f"{self.summary}\n{new_summary}"
self.turns = self.turns[5:]Idea clave: No simplemente trunques los mensajes antiguos—resúmelos. Pierdes detalle pero preservas lo importante.
Anti-patrón: Meterlo todo
He visto sistemas que vuelcan el historial completo de conversación en el contexto. Con 50 turnos, estás quemando 20K+ tokens y ahogando al modelo en ruido.
Más no es mejor. Sé selectivo.
Capa 2: Memoria a corto plazo
La memoria a corto plazo conecta sesiones. Es lo que el agente recuerda de más temprano hoy, ayer, esta semana.
Qué va aquí
- • Resúmenes de conversación de sesiones recientes
- • Correcciones temporales del usuario ("En realidad, prefiero X")
- • Decisiones recientes y su contexto
- • Tareas activas y su estado
El patrón: Caché con decaimiento temporal
class ShortTermMemory:
def __init__(self, redis_client, decay_hours: int = 72):
self.redis = redis_client
self.decay_hours = decay_hours
def store(self, user_id: str, key: str, value: dict):
memory_key = f"stm:{user_id}:{key}"
value["timestamp"] = time.time()
value["access_count"] = 0
self.redis.setex(
memory_key,
timedelta(hours=self.decay_hours),
json.dumps(value)
)
def retrieve(self, user_id: str, key: str) -> dict | None:
data = self.redis.get(f"stm:{user_id}:{key}")
if data:
value = json.loads(data)
# Boost TTL on access (frequently accessed = more important)
value["access_count"] += 1
self.redis.setex(...) # Extend TTL
return value
return NoneIdea clave: Usa TTLs y patrones de acceso para decaer naturalmente las memorias irrelevantes. Las memorias que no se acceden se desvanecen.
Patrón de promoción
Las memorias a corto plazo importantes deberían promocionarse a almacenamiento a largo plazo:
- • Acceso frecuente (access_count > 5) → Promocionar
- • El tipo es "preference" → Promocionar
- • Marcada explícitamente como importante → Promocionar
Capa 3: Memoria a largo plazo
La memoria a largo plazo es conocimiento persistente. Perfiles de usuario, preferencias aprendidas, relaciones entre entidades.
Qué va aquí
- • Perfil de usuario (nombre, preferencias, resumen de historial)
- • Relaciones entre entidades (usuario → empresa, usuario → proyectos)
- • Patrones aprendidos (el usuario tiende a preferir X sobre Y)
- • Hechos importantes (el usuario es alérgico al marisco)
El patrón: Híbrido estructurado + no estructurado
La memoria a largo plazo necesita tanto almacenamiento estructurado (para recuperación confiable) como almacenamiento no estructurado (para búsqueda semántica).
Base de datos de grafos
Para relaciones explícitas y consultas estructuradas
Neo4j, Amazon Neptune
Almacén vectorial
Para búsqueda de similitud semántica
Pinecone, Weaviate, Qdrant
Idea clave: Usa el grafo para relaciones explícitas y consultas estructuradas. Usa vectores para similitud semántica. Necesitas ambos.
Patrón de actualización: Resolución de contradicciones
¿Qué pasa cuando la nueva información contradice memorias antiguas?
- • Verifica contradicciones contra los hechos existentes
- • Si el timestamp más reciente gana → Marca el hecho antiguo como "superseded"
- • Rastrea la proveniencia → Podrías necesitar depurar por qué el agente "cambió de opinión"
No simplemente sobrescribas. Rastrea la proveniencia.
Capa 4: Memoria episódica
La memoria episódica almacena interacciones pasadas específicas—conversaciones memorables, decisiones clave, eventos importantes.
Qué va aquí
- • Conversaciones destacadas (no todas, solo las significativas)
- • Decisiones clave y sus resultados
- • Eventos importantes (el usuario se quejó, el usuario elogió, el usuario cambió preferencias)
- • Excepciones y casos límite
El patrón: Almacenamiento selectivo con scoring de importancia
No puedes almacenar cada interacción. Necesitas decidir qué vale la pena recordar.
Señales de importancia
- • El usuario expresó una emoción fuerte → Alta importancia
- • Se tomó una decisión → Alta importancia
- • El usuario corrigió al agente → Alta importancia
- • La conversación fue larga/participativa → Importancia media
- • El usuario dijo explícitamente "recuerda esto" → La mayor importancia
Idea clave: No todas las interacciones merecen ser memorias. Puntúa la importancia y sé selectivo.
Errores comunes (y cómo evitarlos)
Error 1: Recordar todo
Problema: La memoria se infla. La recuperación se ralentiza. Las memorias irrelevantes desplazan a las relevantes.
Solución: Sé agresivo con lo que almacenas. Puntúa la importancia. Deja que las cosas decaigan.
Error 2: Sin estrategia de recuperación de memoria
Problema: Almacenas memorias pero recuperas mal. Los agentes pierden contexto relevante o recuperan ruido.
Solución: Combina búsqueda semántica con consultas estructuradas. Usa filtrado por metadatos. Pondera por cercanía temporal.
Error 3: Tratar la memoria como solo-append
Problema: Las memorias se vuelven obsoletas o equivocadas. Las contradicciones se acumulan.
Solución: Construye lógica de actualización y resolución de contradicciones. Rastrea la proveniencia. Permite la deprecación.
Error 4: Un solo almacén de memoria para todo
Problema: Los distintos tipos de memoria tienen características diferentes. Una solución única para todo no funciona.
Solución: Usa la arquitectura por capas. Almacenamiento distinto para propósitos distintos.
Error 5: Sin memoria en los prompts
Problema: Recuperas memorias pero no las incluyes eficazmente en los prompts.
Solución: Estructura el contexto de memoria con claridad. Separa lo que el agente sabe de lo que está ocurriendo ahora.
Consideraciones de rendimiento
La memoria añade latencia. Así es como se gestiona:
Recuperación en paralelo
Ejecuta todas las recuperaciones en paralelo con asyncio.gather()
Caché
Cachea el perfil de usuario (cambia con poca frecuencia) con TTL
Carga diferida
Recupera la memoria episódica solo si la consulta requiere contexto histórico
La memoria del agente no es una funcionalidad de casilla. Es un desafío de diseño de sistemas.
Los frameworks te dan bloques de construcción—vector stores, buffers de conversación, extractores de entidades. Pero hacer que la memoria funcione—de forma confiable, performante, correcta—requiere arquitectura.
El enfoque por capas aborda los desafíos centrales:
- • Ventanas de contexto finitas (memoria de trabajo con resumen)
- • Continuidad de sesión (memoria a corto plazo con decaimiento)
- • Conocimiento persistente (memoria a largo plazo con estructura)
- • Recuerdo relevante (memoria episódica con scoring de importancia)
Construye la memoria como un sistema. Pruébala como pruebas la recuperación.
Tus agentes te lo agradecerán. O al menos, recordarán hacerlo.
¿Construyes agentes que necesitan recordar?
HablemosLa arquitectura de memoria es una de las partes más delicadas de los sistemas de agentes en producción.
Artículos relacionados
Sistemas Multi-Agente
La arquitectura multi-agente que realmente escala
Patrones que descubrimos después de 5 despliegues en producción.
RAG & GraphRAG
Por qué tu pipeline RAG te está mintiendo
La mayoría de pipelines RAG recuperan chunks equivocados el 30-40% de las veces.
Guías de frameworks
CrewAI vs. Agno vs. LangGraph
Un marco de decisión para elegir la herramienta correcta.
Newsletter
Patrones de arquitectura de agentes e insights de producción—cada martes.
Únete a más de 2.500 ingenieros y líderes que reciben insights prácticos de implementación de IA.
Suscríbete a AI That Ships