Degradación de la memoria en agentes de IA: por qué colapsan los LLM en conversaciones de varios turnos

Cuando llevaba noventa minutos construyendo mi sistema de deliberación⁹, el agente dejó de hacer referencia a la arquitectura que había discutido treinta minutos antes. Los registros de la sesión mostraban que Claude había comprimido y descartado el grafo de dependencias entre módulos para dejar espacio a nuevas salidas de herramientas. El agente siguió escribiendo código, pero ese código ya no reflejaba los contratos entre módulos que había establecido durante la primera hora. Las pruebas pasaban. La integración fallaba. El agente había olvidado su propio diseño.

Ese fallo me costó un día entero de depuración. La investigación ya explica por qué ocurrió.

En resumen

Microsoft Research y Salesforce probaron 15 LLM en más de 200 000 conversaciones simuladas y encontraron una caída media de rendimiento del 39 % al pasar de la interacción de un solo turno a la de varios turnos.¹ La degradación empieza con apenas dos turnos. Tres mecanismos independientes provocan el colapso: la compresión del contexto descarta estado crítico, la coherencia del razonamiento se fragmenta a medida que se reduce el presupuesto de tokens y la coordinación entre agentes se desmorona sin una verdad de referencia compartida. Ampliar la ventana de contexto no resuelve ninguno de los tres. El patrón del bucle Ralph (contexto nuevo en cada iteración, con el estado en el sistema de archivos) esquiva la pérdida por compresión, pero introduce sus propios costos. A continuación: la investigación, los tres mecanismos, métodos de detección que puedes aplicar hoy mismo y un protocolo para lograr resiliencia entre turnos.

El precipicio de los 90 minutos

Mi artículo sobre el contexto como arquitectura⁸ documentaba un sistema de contexto de siete capas repartido en 650 archivos. Construirlo exigía sesiones largas de programación en las que el agente debía sostener un estado arquitectónico complejo: límites de módulos, cadenas de dependencias, orden de ejecución de los ganchos y contratos entre archivos.

Medí la calidad de las sesiones a lo largo de 30 iteraciones del bucle Ralph durante enero y febrero de 2026.⁷ Los datos mostraron un patrón constante:

Minutos 0-30:   Ediciones precisas en varios archivos, referencias cruzadas correctas
Minutos 30-60:  Importaciones olvidadas puntuales, todavía recuperable
Minutos 60-90:  Visión de túnel en un solo archivo, pierde el contexto arquitectónico
Minutos 90+:    Intentos repetitivos, contradice decisiones anteriores

El precipicio de calidad aparecía sin importar el tipo de tarea. Las sesiones largas de refactorización, la construcción de suites de pruebas y las pasadas de documentación se degradaban siguiendo la misma curva. Lo que variaba era la gravedad: las tareas que requerían más estado repartido entre archivos sufrían el precipicio con más dureza que el trabajo aislado sobre un solo archivo.

Atribuí el patrón a la presión sobre la ventana de contexto y construí el bucle Ralph para sortearlo. Se lanza una instancia nueva de Claude por iteración; se inyecta el estado desde el sistema de archivos; nunca se depende de la memoria conversacional más allá de una iteración. El patrón funciona. Pero el estudio de MSR y Salesforce publicado en mayo de 2025 reveló que el problema es más estructural que el mero tamaño de la ventana de contexto.

Tres mecanismos del colapso entre turnos

Laban et al. descompusieron la degradación entre turnos en mecanismos independientes, y la distinción importa porque cada uno exige una intervención estructuralmente distinta.¹

Mecanismo 1: compresión del contexto

Toda conversación con una IA opera dentro de un presupuesto finito de tokens. A medida que la conversación crece, el sistema comprime los turnos anteriores para dar cabida al contenido nuevo. Esa compresión tiene pérdidas. Las decisiones arquitectónicas documentadas en el turno 3 pueden no sobrevivir hasta el turno 15.

Lo detecté de forma directa mientras construía el sistema de deliberación. El agente estableció un grafo de dependencias entre módulos en los primeros 20 minutos: deliberation_engine.py depende de consensus_calculator.py, que a su vez depende de vote_aggregator.py. Para el minuto 75, el agente había comprimido y descartado la cadena de dependencias y escribió un ciclo de importaciones. El código era sintácticamente válido. La importación circular provocó un fallo en tiempo de ejecución.

Detección: vigila la proporción de referencias entre archivos en la salida del agente a lo largo del tiempo. Cuando el agente deja de mencionar archivos que ya había tratado antes, es probable que la compresión haya descartado el contexto relevante.

# Count unique file references per 30-min window in a session log
# Declining count signals compression loss
git log --since="2 hours ago" --pretty=format:"%s" | \
  grep -oP '[a-z_]+\.(py|js|ts)' | sort -u | wc -l

Mecanismo 2: pérdida de coherencia en el razonamiento

El estudio de MSR y Salesforce encontró que la degradación entre turnos se descompone en dos componentes: una pérdida menor de aptitud y un aumento notable de la falta de fiabilidad.¹ La aptitud mide si el modelo es capaz de producir una respuesta correcta. La fiabilidad mide si lo hace de forma consistente.

En modo de un solo turno, los modelos alcanzaron alrededor de un 90 % de rendimiento medio en seis tareas de generación. En modo de varios turnos, el rendimiento bajó hasta aproximadamente el 65 %: una caída absoluta de 25 puntos. El hallazgo clave: «cuando los LLM toman un rumbo equivocado en una conversación de varios turnos, se pierden y no se recuperan».¹

La pérdida de coherencia en el razonamiento se manifiesta cuando el agente contradice sus propias decisiones anteriores. No porque el sistema haya comprimido y descartado el contexto (mecanismo 1), sino porque la cadena de razonamiento del modelo se fragmentó entre turnos. El razonamiento de cada turno es sólido a nivel local, pero inconsistente a nivel global.

El trabajo de Du et al. sobre enrutamiento cognitivo de decisiones aborda este mecanismo de forma directa.² Inspirado en la teoría de los dos procesos de Kahneman (respuestas rápidas e intuitivas frente a razonamiento lento y deliberado), su sistema adapta la profundidad del razonamiento según las exigencias de la tarea. La idea de fondo: no todos los turnos del agente requieren la misma profundidad de razonamiento, y aplicar una profundidad uniforme malgasta presupuesto en pasos triviales mientras se invierte de menos en las decisiones críticas.

Detección: busca contradicciones entre lo que el agente produce al principio y al final de la sesión. Si defiende el enfoque A en el minuto 15 y el enfoque B en el minuto 60 sin reconocer el cambio, la coherencia se ha degradado.

Mecanismo 3: fallo de coordinación

Los sistemas multiagente agravan la degradación entre turnos al añadirle el fallo de coordinación. Cuando dos o más agentes colaboran en una tarea, el contexto de cada uno se degrada por separado. Un agente que ha olvidado una restricción compartida no puede coordinarse en torno a ella.

Los Agent Context Protocols de Bhardwaj et al. abordan esto estableciendo canales de comunicación estructurados entre agentes.³ Su marco alcanzó un 28,3 % de precisión en AssistantBench al definir protocolos explícitos para compartir contexto, propagar errores y sincronizar estado. El Unified Agent Communication Protocol de Krishnan lo extiende con fronteras de seguridad de confianza cero entre agentes.⁴

Me topé con un fallo de coordinación durante una deliberación de 10 agentes en la que tres revisores evaluaban el mismo cambio de código. Para la cuarta ronda de revisión, los agentes habían divergido sobre cómo era la «versión actual» del código. El contexto de cada agente contenía una instantánea distinta. Sus revisiones se contradecían no porque discreparan, sino porque estaban revisando código diferente.

Detección: en flujos de trabajo multiagente, compara las suposiciones de estado que sostiene cada agente. Si los agentes se refieren a versiones distintas del mismo artefacto, la coordinación ha fallado.

Por qué ampliar la ventana de contexto no lo soluciona

La respuesta intuitiva ante la degradación entre turnos es «dale más tokens al modelo». El estudio de MSR y Salesforce refuta esa intuición con un diseño experimental ingenioso.

Probaron una condición «Concat»: presentar la conversación completa de varios turnos como un único prompt concatenado. La condición Concat alcanzó el 95,1 % del rendimiento de un solo turno.¹ La longitud del contexto era idéntica a la de la condición de varios turnos. El contenido informativo era idéntico. La única diferencia estaba en la estructura de la interacción: un turno frente a muchos.

La degradación del 39 % no es un problema de longitud del contexto. Duplicar la ventana de 200K a 400K tokens no eliminaría el deterioro, porque este proviene de las propias fronteras entre turnos, no de quedarse sin espacio.

El hallazgo de Concat coincide con mis datos de producción. Claude opera con unos 200 000 tokens de contexto. Mis mediciones sobre gestión de la ventana de contexto mostraron que las ejecuciones más largas en una sola sesión (más de 3 horas, con uso intensivo de herramientas) consumen aproximadamente 180 000 tokens antes de que se active la compactación. Pero la calidad se degrada mucho antes de que la ventana se llene. El precipicio de los 90 minutos ocurre alrededor del 60-70 % de utilización del contexto, no en el límite. La deuda cognitiva resultante se acumula a medida que el agente produce código más rápido de lo que un desarrollador puede verificarlo. Es el mismo problema del contexto compuesto a otra escala: cada turno añade información que interactúa de forma no lineal con lo anterior.

El enrutamiento cognitivo de decisiones de Du et al. replantea el problema: la cuestión no es cuántos tokens puede sostener el modelo, sino con qué eficiencia reparte sus recursos de razonamiento entre esos tokens.² Su sistema logró una reducción del 34 % en costos computacionales con una mejora del 23 % en consistencia, encaminando las decisiones simples por la vía del razonamiento rápido y las complejas por la del razonamiento deliberado.

La solución del contexto nuevo (y lo que cuesta)

El bucle Ralph resuelve el mecanismo 1 (compresión) y resuelve en parte el mecanismo 2 (coherencia) porque nunca deja que una conversación se alargue lo suficiente para que cualquiera de los dos se manifieste. Cada iteración lanza una instancia nueva de Claude con los 200K tokens de contexto completos. El estado persiste en el sistema de archivos, no en la memoria conversacional.

# Simplified Ralph loop iteration (from jiro-artisan.sh)
while [ "$stories_remaining" -gt 0 ]; do
  # Orient: inject current state from filesystem
  state=$(cat jiro.state.json)
  progress=$(cat jiro.progress.json)
  git_state=$(git diff --stat HEAD)

  # Spawn fresh context with injected state
  claude --print \
    "State: $state" \
    "Progress: $progress" \
    "Git: $git_state" \
    "Task: implement next story from prd.json"

  # Update filesystem state from agent output
  update_state_from_output
done

Cada iteración recibe el presupuesto de contexto completo. Sin artefactos de compresión de turnos previos. Sin fragmentos de coherencia de cadenas de razonamiento anteriores. El sistema de archivos hace de memoria externa del agente: jiro.state.json registra la historia en curso, jiro.progress.json deja constancia del trabajo completado a lo largo de las iteraciones y git diff aporta la verdad de referencia sobre lo que realmente cambió.

Los Recursive Language Models de Zhang, Kraska y Khattab adoptan un enfoque complementario: en lugar de lanzar instancias nuevas, el modelo descarga el contexto a un entorno REPL de Python y razona sobre él en código en vez de en el espacio de tokens.⁵ RLM-Qwen3-8B superó a su modelo base en un 28,3 % en tareas de contexto largo al tratar los prompts extensos como estructuras de datos externas y no como memoria interna. Donde el bucle Ralph externaliza el estado a archivos, los RLM lo externalizan a código. Ambos patrones resuelven el mismo problema de compresión por vías distintas.

El sistema Wink de Nanda et al. atiende lo que ocurre cuando la degradación ya está en marcha.⁶ Tras analizar más de 10 000 trayectorias reales de agentes, encontraron que los comportamientos anómalos (desviación respecto de la especificación, bucles repetitivos, fallos en las llamadas a herramientas) aparecen en aproximadamente el 30 % de todas las sesiones. Wink observa la trayectoria del agente y ofrece correcciones de rumbo dirigidas, con lo que resuelve el 90 % de los casos que se arreglan con una sola intervención. La detección es en tiempo real: Wink identifica los patrones de degradación conforme emergen, en vez de esperar a que un fallo se propague por la base de código.

Los costos

La iteración con contexto nuevo no es gratis. Tiene tres costos:

1. Sobrecosto de orientación. Cada iteración gasta tokens releyendo un estado que la iteración anterior ya comprendía. Mis mediciones indican que entre el 15 y el 20 % del presupuesto de tokens de cada iteración se va en el paso de orientación: leer archivos de estado, revisar el historial reciente de git y reconstruir el contexto suficiente para continuar. Una iteración de 200K tokens arranca con unos 160-170K tokens de capacidad utilizable.

2. Conocimiento implícito perdido. El contexto conversacional arrastra un conocimiento implícito que el estado en el sistema de archivos no captura: el razonamiento detrás de una decisión de diseño, las alternativas consideradas y descartadas, el matiz de por qué se eligió el enfoque A sobre el B. El paso de orientación inyecta hechos (qué cambió, qué sigue). El razonamiento (el porqué) se evapora entre iteraciones.

3. Costo de coordinación. Si varios bucles Ralph corren a la vez (implementación de historias en paralelo), cada bucle mantiene su propio estado. Coordinarlos exige lógica explícita de fusión y resolución de conflictos que una única sesión larga maneja de forma implícita.

El cálculo de costo-beneficio es claro: para sesiones de menos de 60 minutos, una sola conversación resulta más eficiente. A partir de los 90 minutos, el patrón de contexto nuevo produce mejores resultados pese al sobrecosto de orientación. El punto de cruce depende de la complejidad de la tarea: mucho estado repartido entre archivos lo adelanta; el trabajo aislado sobre un solo archivo lo retrasa.

Medir la degradación antes de que golpee

No hace falta esperar a un fallo en producción para detectar la degradación entre turnos. Tres métodos, del más sencillo al más exhaustivo:

Método 1: monitoreo de la presión de contexto

Vigila la utilización del contexto en tiempo real. Mi gancho context-pressure.sh se ejecuta después de cada llamada a una herramienta y avisa cuando la utilización supera el 60 %:

# Simplified context pressure check
context_used=$(wc -c < "$CONVERSATION_LOG" | awk '{print int($1/4)}')
context_max=200000
utilization=$(( context_used * 100 / context_max ))

if [ "$utilization" -gt 60 ]; then
  echo "[WARN] Context at ${utilization}% — quality degradation likely"
fi

if [ "$utilization" -gt 80 ]; then
  echo "[CRITICAL] Context at ${utilization}% — start new session"
fi

Método 2: seguimiento de referencias cruzadas

Controla cuántos archivos distintos referencia el agente por salida. Una tendencia decreciente señala pérdida por compresión:

# Track file reference diversity in recent commits
for commit in $(git log --oneline -5 --format="%H"); do
  files=$(git diff-tree --no-commit-id --name-only -r "$commit" | wc -l)
  echo "$commit: $files files touched"
done

Método 3: detección de contradicciones

Compara a lo largo del tiempo las afirmaciones arquitectónicas del agente. Si en el minuto 20 sostiene que «el módulo A depende del módulo B» y en el minuto 70 que «el módulo A no tiene dependencias externas», la coherencia se ha degradado. La versión automatizada: haz un diff de las sentencias EXPLAIN del agente (o de sus comentarios de diseño) entre las salidas tempranas y las tardías de la sesión.

Un protocolo para la resiliencia entre turnos

Tres niveles, cada uno dirigido a un mecanismo distinto. Empieza por el nivel 1 y añade capas según haga falta.

Nivel 1: puntos de control de estado

Cada 30 minutos, serializa a un archivo la comprensión arquitectónica actual del agente. No la conversación entera, sino el estado estructural: qué módulos existen, cómo se conectan, qué restricciones se aplican.

# Pre-compaction checkpoint (runs before Claude compresses context)
mkdir -p .claude/checkpoints
cat > ".claude/checkpoints/$(date +%s).md" << 'CHECKPOINT'
## Architectural State
- Module graph: [current understanding]
- Active constraints: [list]
- Design decisions made this session: [list with reasoning]
CHECKPOINT

Si el comportamiento del agente se degrada, restaura desde el punto de control en lugar de seguir con un contexto deteriorado.

Nivel 2: iteraciones con contexto nuevo

Para sesiones que superen los 60 minutos, cambia al patrón del bucle Ralph. La clave está en el paso de orientación: inyectar el estado suficiente para que el contexto nuevo pueda continuar de forma productiva sin releer todo el historial de la conversación.

Estado necesario para el paso de orientación: 1. Tarea actual y criterios de aceptación 2. Archivos modificados en la iteración anterior (a partir de git diff) 3. Decisiones arquitectónicas y su razonamiento 4. Restricciones conocidas y modos de fallo

Nivel 3: protocolos de coordinación entre agentes

Para flujos de trabajo multiagente, establece un documento de estado compartido que todos los agentes lean y escriban. Ese documento hace de verdad de referencia y evita la divergencia que observé durante las revisiones de deliberación.

{
  "version": 7,
  "last_updated": "2026-02-22T14:30:00Z",
  "active_files": ["engine.py", "calculator.py", "aggregator.py"],
  "constraints": [
    "No circular imports between modules",
    "All public functions require type annotations"
  ],
  "decisions": [
    {"decision": "Use RRF for vote aggregation", "reasoning": "Handles rank-only data", "turn": 3}
  ]
}

Cada agente lee este documento al empezar su turno y lo actualiza al terminar. Los conflictos activan una pausa de coordinación en lugar de una divergencia silenciosa. Los mejores agentes operan así, de forma invisible: como se explora en El agente invisible, la meta es una infraestructura que funcione sin que el desarrollador se dé cuenta.

Ideas clave

• La degradación entre turnos es estructural, no un problema de longitud del contexto. El estudio de MSR y Salesforce mostró un deterioro del 39 % incluso manteniendo constante la longitud del contexto. Lo que provoca el colapso son las fronteras entre turnos, no los límites de tokens.¹
• Tres mecanismos independientes exigen tres intervenciones distintas. La pérdida por compresión requiere puntos de control de estado. La pérdida de coherencia requiere iterar con contexto nuevo. El fallo de coordinación requiere protocolos de estado compartido.
• El precipicio de los 90 minutos es real y medible. Vigila la utilización del contexto, la diversidad de referencias cruzadas y las contradicciones arquitectónicas para detectar el deterioro antes de que aflore en producción.
• La iteración con contexto nuevo funciona, pero acarrea un sobrecosto del 15-20 %. El patrón del bucle Ralph cambia el sobrecosto de orientación por un presupuesto de contexto completo en cada iteración. La compensación favorece al contexto nuevo más allá de los 60-90 minutos.
• Asignar el razonamiento de forma adaptativa supera a la profundidad uniforme. El enrutamiento cognitivo de decisiones de Du et al. logró un 34 % de reducción de costos con un 23 % de mejora en consistencia al ajustar la profundidad del razonamiento a las exigencias de la tarea.²

Preguntas frecuentes

Referencias