Una nota personal antes de empezar. Si me preguntan qué subtema dentro de IA me parece más subestimado en 2026, la respuesta es la memoria de los LLMs. No los modelos. No los benchmarks. La memoria. Es donde se separan los demos bonitos de los agentes que funcionan en producción. Es lo que me apasiona genuinamente y donde llevo más tiempo experimentando.
Esta semana en bitneuronal voy a profundizar en este tema todos los días, si llevas tiempo intentando que tu agente mantenga coherencia entre sesiones, este es el momento de prestarle atención.
Hoy arrancamos con el diagnóstico y los cinco patrones arquitectónicos. Vamos.
El diagnóstico: RAM vs. Disco Duro
Si has notado que tu agente de IA parece "olvidar" instrucciones, se contradice o ignora restricciones después de varios pasos, probablemente culpes al modelo. Sin embargo, el diagnóstico real es mucho más simple:
Estás usando la ventana de contexto (RAM) como si fuera un disco duro (almacenamiento persistente).
Tratar la ventana de contexto como una base de datos donde simplemente añades cada resultado y preferencia genera fallos predecibles. Para que un agente funcione de manera confiable a través de cientos de llamadas, necesita una arquitectura de memoria limpia que separe la memoria de trabajo (para la tarea actual) de la memoria persistente (para información que debe sobrevivir entre sesiones).
A continuación presento cinco patrones de diseño independientes de cualquier framework para solucionar este problema, junto con los hallazgos clave sobre cómo se comportan los agentes en producción.
🛠️ Los 5 patrones de diseño para la memoria de tu agente
Para evitar que tu agente colapse bajo su propio historial, debes implementar estos cinco patrones arquitectónicos.
1. Fijación de restricciones estrictas (Hard Constraint Pinning)
Las restricciones que nunca deben violarse no pueden quedar enterradas en el historial de la conversación. Deben recuperarse de la memoria persistente en cada llamada y ser inyectadas en la parte superior del system prompt. De esta manera, la posición de la restricción no se ve afectada sin importar qué tan profunda sea la sesión.
Ejemplo concreto en Python:
# memoria persistente: restricciones que NUNCA se violan
HARD_CONSTRAINTS = [
"Nunca recomendar inversiones específicas",
"Nunca generar código que use eval() o exec()",
"Siempre responder en español",
]
def build_system_prompt(base_prompt: str, constraints: list[str]) -> str:
"""Inyecta restricciones al inicio del system prompt en CADA llamada."""
pinned = "\n".join(f"- {c}" for c in constraints)
return f"""# RESTRICCIONES ABSOLUTAS (no negociables)
{pinned}
---
{base_prompt}"""
# en cada turno, sin importar la longitud de la sesión:
system_prompt = build_system_prompt(
base_prompt=task_context,
constraints=HARD_CONSTRAINTS
)
El truco está en hacerlo en cada turno, no solo al inicio. La fijación no es un evento — es un proceso.
2. Resumen de resultados de herramientas antes de la inyección
No inyectes respuestas de API de 2.000 tokens directamente en la memoria de trabajo. En su lugar, resume los resultados crudos a los hechos relevantes para la tarea.
Con este patrón, diez llamadas a herramientas que normalmente ocuparían 20.000 tokens pueden reducirse a aproximadamente 1.000 tokens, manteniendo la memoria de trabajo ágil.
Un ejemplo: si tu agente llama a una API de clima y recibe 1.500 tokens de JSON con humedad, presión, índice UV, hora de salida del sol, viento y temperaturas por hora, lo que probablemente necesita es "27°C, soleado, 30% humedad" — 8 tokens.
3. Reinyección de modificadores activos (Active Modifier Re-injection)
Si el usuario da una instrucción a mitad de la tarea (ej. "haz que el reporte sea conciso"), no dejes que se pierda en el historial. Almacena estas instrucciones en un objeto de memoria de trabajo y reinyéctalas en el system prompt en cada llamada subsiguiente hasta que la tarea se complete.
Este patrón es la diferencia entre un agente que respeta tu última instrucción y uno que la olvida tres turnos después porque quedó sepultada bajo logs de herramientas.
4. Extracción al cierre de la sesión (Session-Close Extraction)
Cuando finaliza una sesión, debes realizar un único pase de extracción para guardar las preferencias estables del usuario en la memoria persistente y descartar todo lo demás. Este es el único momento en el que las observaciones de la memoria de trabajo se "gradúan" al almacenamiento a largo plazo.
¿Por qué un único pase y no continuo? Porque la extracción continua confunde estado transitorio con preferencia estable. "Hoy quiero el reporte corto" no es lo mismo que "este usuario prefiere reportes cortos".
5. Compresión estructurada con memoria externa
Para la compresión dentro de la sesión, usa un sistema que mantenga la coherencia narrativa (como el ContextCompressor de Hermes Agent o el summarizer de LangGraph), pero compleméntalo con un almacenamiento externo (como Mem0 o Letta).
Esto asegura que, aunque la compresión descarte valores exactos o razonamientos por falta de espacio, las preferencias exactas y restricciones estrictas sobrevivan en la memoria persistente y puedan ser reinyectadas cuando la tarea las necesite.
📊 Los hallazgos: ¿qué nos dicen los datos?
Al analizar cómo los LLMs manejan la memoria y el contexto, las investigaciones recientes han revelado cuatro descubrimientos que vale la pena tener presentes:
1. El decaimiento pasivo de la atención ("Lost in the Middle")
El rendimiento del modelo se degrada mucho antes de alcanzar el límite de tokens. El paper original Lost in the Middle (Liu et al., 2023) demostró que la información ubicada en el medio del contexto es sistemáticamente menos atendida que la del principio o el final — incluso en modelos con ventanas grandes.
En el caso de agentes específicamente: un estudio reciente muestra que si un agente sigue una regla correctamente en el turno 5 (73% de cumplimiento), para el turno 16 la tasa de cumplimiento de esa misma regla cae a un 33% si no se utilizan mitigaciones como la fijación de restricciones. El modelo simplemente presta menos atención al contenido antiguo cuando se entierra bajo ruido reciente.
2. Las ventanas de contexto gigantes no son la solución
Ampliar la ventana de contexto a 1 millón de tokens (Gemini 1.5 Pro, Gemini 3.5, Claude Opus con 1M, etc.) no previene la dilución de la atención — simplemente la retrasa y hace que cada inferencia sea mucho más costosa.
La memoria de trabajo exige un re-procesamiento completo en cada llamada (no hay "deltas" gratis), por lo que una ventana de 50.000 tokens cuesta lo mismo en cómputo aunque solo hayan cambiado 500 tokens entre turnos. Mover la carga útil a memoria externa con recuperación selectiva es estructuralmente más eficiente.
3. La compresión pierde el "por qué" y los "valores exactos"
Cuando los agentes comprimen su propio contexto, preservan el hecho de que algo sucedió, pero tienden a perder detalles críticos. Por ejemplo, "queremos luces a 2700K" se resume a "el usuario tiene preferencias de iluminación", y el razonamiento detrás de las decisiones clave desaparece casi por completo.
Esto convierte la compresión en una herramienta útil para reducir tokens, pero peligrosa si es la única estrategia de memoria. La regla práctica: comprimes para liberar espacio, pero los valores exactos y restricciones se guardan literales en memoria persistente, no comprimidos.
4. Eficiencia radical mediante arquitectura
El uso de algoritmos de memoria avanzados (extracciones jerárquicas y recuperación multi-señal) demostró en benchmarks recientes superar en precisión a los baselines de "contexto completo": 91.6% vs. 72.9% según el paper de Mem0 (Chhikara et al., 2025), al tiempo que reducían el costo de tokens a una cuarta parte y bajaban la latencia de 17.12 segundos a solo 1.44 segundos en benchmark LongMemEval.
Traducido al lenguaje de costos enterprise: un agente bien arquitectado puede costar 4x menos y responder ~12x más rápido que el mismo agente con "contexto completo". La diferencia se nota más en producción que en demo.
🧰 Frameworks que vale conocer (mini comparativa)
Framework | Fortaleza | Cuándo usarlo |
|---|---|---|
Memoria de usuario/agente con extracción automática y recuperación semántica | Cuando necesitas memoria persistente plug-and-play y no quieres construir el storage | |
Memoria jerárquica con "paginación" de contexto al estilo OS | Cuando tu agente necesita memoria de muy largo plazo con auto-gestión | |
Memoria integrada al grafo de ejecución del agente | Cuando ya usas LangGraph y quieres state management coherente con tu workflow | |
ContextCompressor robusto para sesiones largas | Cuando tu cuello de botella es compresión en sesión, no persistencia | |
Custom (Redis + pgvector) | Control total, sin lock-in | Cuando tus restricciones de privacy/regulatorias exigen autohospedaje |
Lo más importante: ninguno de estos frameworks resuelve los cinco patrones por ti. Resuelven dos o tres, y dejan los otros a tu arquitectura. La decisión sigue siendo tuya.
🌎 Para builders LATAM
Tres razones por las que esto importa más para nosotros:
Costo. Memoria mal arquitectada significa pagar por re-procesar tokens que no aportan información. Cuando tu run-rate está medido en miles de dólares al mes y no en millones, la diferencia entre 17s y 1.4s de latencia (y entre 4x el costo y 1x) se vuelve material. Es la diferencia entre quemar runway o no.
Multi-tenancy. La mayor parte del SaaS LATAM exitoso es B2B multi-tenant. Aislamiento de memoria por tenant no es opcional — es requisito de compliance, especialmente con leyes locales como la LGPD (Brasil) o la nueva ley mexicana de IA. Mem0 y Letta soportan aislamiento por user/tenant out-of-the-box; si construyes custom, tienes que diseñarlo desde el día uno.
Casos de uso regulados. Recordemos el caso Enter (Brasil, primer unicornio LATAM de IA): legaltech con clientes como Nubank y Bradesco. Para procesar 300.000 casos legales al año, no puedes darte el lujo de que el agente olvide una restricción regulatoria en el turno 16. La arquitectura de memoria es lo que permite que un vertical regulado funcione a escala.
✅ Checklist accionable para esta semana
Si llevas un agente en producción y quieres validar su salud de memoria, responde estas siete preguntas:
¿Tienes una lista explícita de restricciones absolutas que se reinyectan en cada turno? (Si no, Patrón #1.)
¿Tus resultados de herramientas se resumen antes de entrar a la memoria de trabajo? (Si no, Patrón #2.)
¿Los modificadores que el usuario da a mitad de tarea sobreviven al turno siguiente? (Si no, Patrón #3.)
¿Tienes un pase explícito al final de la sesión que gradúa preferencias a memoria persistente? (Si no, Patrón #4.)
¿Tu compresión preserva valores exactos o solo "el hecho de que algo pasó"? (Si solo lo segundo, complementa con memoria externa — Patrón #5.)
¿Has medido la degradación de cumplimiento de reglas entre turnos tempranos y tardíos en producción? (Si no, este es el experimento de la semana.)
¿Tu arquitectura de memoria es auditable por tenant/usuario? (Si no, planifícala antes de que un cliente regulado la pida.)
Si respondiste "no" a más de tres, no es problema del modelo. Es problema de arquitectura.📚 Lecturas obligatorias para profundizar
Lost in the Middle (Liu et al., 2023) — el paper que originó la conversación.
Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory (Chhikara et al., 2025) — la fuente del benchmark 91.6% vs. 72.9%.
LongMemEval (Wu et al., 2024) — el benchmark que estandariza la evaluación de memoria de largo plazo.
MemGPT (Packer et al., 2023) — el paper que introdujo la memoria jerárquica estilo OS.
Effective Context Engineering for AI Agents (Anthropic) — la guía oficial de Anthropic.
Esta semana vamos a estar hablando de este tema con más profundidad.
Si te apasiona esto tanto como a mí, vamos a tener una semana entretenida.