Degradación de la memoria en agentes de IA: por qué las conversaciones multi-turno con LLMs colapsan

A los noventa minutos de construir 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 el grafo de dependencias entre módulos para dar cabida 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 en la primera hora. Las pruebas pasaron. La integración falló. El agente había olvidado su propio diseño.

Esa falla me costó un día entero de depuración. La investigación actual explica por qué ocurrió.

TL;DR

Microsoft Research y Salesforce probaron 15 LLMs en más de 200.000 conversaciones simuladas y encontraron una caída promedio del 39% en rendimiento entre la interacción de un solo turno y la multi-turno.¹ La degradación comienza en tan solo dos turnos. Tres mecanismos independientes impulsan el colapso: la compresión del contexto descarta estado crítico, la coherencia del razonamiento se fragmenta a medida que los presupuestos de tokens se reducen, y la coordinación entre agentes colapsa sin una fuente de verdad compartida. Las ventanas de contexto más grandes no corrigen ninguno de estos problemas. El patrón del bucle Ralph (contexto fresco por iteración con estado en el sistema de archivos) evita 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 ejecutar hoy, y un protocolo para la resiliencia multi-turno.

El precipicio de los 90 minutos

Mi publicación sobre el contexto como arquitectura documentó un sistema de contexto de siete capas que abarca 650 archivos. Construir ese sistema requirió sesiones de programación extendidas donde el agente necesitaba mantener un estado arquitectónico complejo: límites de módulos, cadenas de dependencias, orden de ejecución de hooks y contratos entre archivos.

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

Minutes 0-30:   Precise multi-file edits, correct cross-references
Minutes 30-60:  Occasional missed imports, still recoverable
Minutes 60-90:  Single-file tunnel vision, loses architectural context
Minutes 90+:    Repetitive attempts, contradicts earlier decisions

El precipicio de calidad aparecía independientemente del tipo de tarea. Las sesiones largas de refactorización, la construcción de suites de pruebas y las pasadas de documentación se degradaban en la misma curva. Lo que variaba era la severidad: las tareas que requerían más estado entre archivos alcanzaban el precipicio antes que el trabajo aislado en un solo archivo.

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

Tres mecanismos del colapso multi-turno

Laban et al. descompusieron la degradación multi-turno en mecanismos independientes, y la distinción importa porque cada uno requiere una intervención estructuralmente diferente.¹

Mecanismo 1: Compresión del contexto

Toda conversación de IA opera dentro de un presupuesto finito de tokens. A medida que la conversación crece, el sistema comprime turnos anteriores para dar cabida a contenido nuevo. La compresión tiene pérdida. Las decisiones arquitectónicas documentadas en el turno 3 podrían no sobrevivir hasta el turno 15.

Detecté esto directamente durante la construcción del 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 depende de vote_aggregator.py. Al minuto 75, el agente había comprimido la cadena de dependencias y escribió un ciclo de importación. El código era sintácticamente válido. La importación circular causó un fallo en tiempo de ejecución.

Detección: Rastrea la proporción de referencias entre archivos en la salida del agente a lo largo del tiempo. Cuando el agente deja de hacer referencia a archivos que discutió antes, la compresión probablemente ha 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/Salesforce encontró que la degradación multi-turno se descompone en dos componentes: una pérdida menor de aptitud y un aumento significativo en la falta de fiabilidad.¹ La aptitud mide si el modelo puede producir una respuesta correcta. La fiabilidad mide si lo hace de manera consistente.

En modo de un solo turno, los modelos alcanzaron aproximadamente un 90% de rendimiento promedio en seis tareas de generación. En modo multi-turno, el rendimiento cayó a aproximadamente un 65%: una disminución absoluta de 25 puntos. El hallazgo crítico: “Cuando los LLMs toman un camino equivocado en una conversación multi-turno, 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 el contexto (mecanismo 1), sino porque la cadena de razonamiento del modelo se fragmentó entre turnos. Cada turno es localmente coherente pero globalmente inconsistente.

El trabajo de Du et al. sobre enrutamiento cognitivo de decisiones aborda este mecanismo directamente.² Inspirado en la teoría de procesamiento dual de Kahneman (respuestas intuitivas rápidas vs. razonamiento deliberado lento), su sistema adapta la profundidad del razonamiento según las demandas de la tarea. La clave: no todos los turnos del agente requieren la misma profundidad de razonamiento, y aplicar una profundidad uniforme desperdicia presupuesto en pasos triviales mientras subinvierte en decisiones críticas.

Detección: Busca contradicciones entre la salida temprana y tardía de la sesión. Si el agente 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 multi-agente agravan la degradación multi-turno con fallos de coordinación. Cuando dos o más agentes colaboran en una tarea, el contexto de cada agente se degrada de manera independiente. Un agente que ha olvidado una restricción compartida no puede coordinarse en torno a ella.

Bhardwaj et al. abordan esto con los Agent Context Protocols, estableciendo canales de comunicación estructurados entre agentes.³ Su framework alcanzó un 28,3% de precisión en AssistantBench al definir protocolos explícitos para el intercambio de contexto, la propagación de errores y la sincronización de estado. El Unified Agent Communication Protocol de Krishnan extiende esto con límites de seguridad de confianza cero entre agentes.⁴

Encontré un fallo de coordinación durante una deliberación con 10 agentes donde tres revisores evaluaron el mismo cambio de código. Para la cuarta ronda de revisión, los agentes habían divergido sobre cómo lucía la “versión actual” del código. El contexto de cada agente contenía una instantánea diferente. Sus revisiones se contradecían entre sí, no porque estuvieran en desacuerdo, sino porque revisaban código diferente.

Detección: En flujos de trabajo multi-agente, compara las suposiciones de estado que mantiene cada agente. Si los agentes hacen referencia a versiones diferentes del mismo artefacto, la coordinación ha fallado.

Por qué las ventanas de contexto más grandes no lo solucionan

La respuesta intuitiva a la degradación multi-turno es “darle más tokens al modelo.” El estudio de MSR/Salesforce refuta esta intuición con un diseño experimental ingenioso.

Probaron una condición “Concat”: presentar la conversación multi-turno completa 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 condición multi-turno. El contenido informativo era idéntico. La única diferencia era la estructura de interacción: un turno vs. muchos turnos.

La degradación del 39% no es un problema de longitud de contexto. Duplicar la ventana de contexto de 200K a 400K tokens no eliminaría la degradación, porque esta proviene de los límites entre turnos, no de quedarse sin espacio.

El hallazgo de Concat coincide con mis datos de producción. Claude opera con aproximadamente 200.000 tokens de contexto. Mis mediciones de gestión de la ventana de contexto mostraron que las ejecuciones de sesión única más largas (más de 3 horas, 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 con aproximadamente un 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 verificar. Este es el mismo problema de contexto compuesto a una escala diferente: cada turno agrega información que interactúa de manera no lineal con lo que vino antes.

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

La solución de contexto fresco (y sus costos)

El bucle Ralph resuelve el mecanismo 1 (compresión) y parcialmente el mecanismo 2 (coherencia) al no ejecutar nunca una conversación lo suficientemente larga para que ninguno se manifieste. Cada iteración crea una instancia fresca de Claude con una ventana de contexto completa de 200K tokens. El estado persiste a través del sistema de archivos, no de 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 obtiene el presupuesto de contexto completo. Sin artefactos de compresión de turnos anteriores. Sin fragmentos de coherencia de cadenas de razonamiento previas. El sistema de archivos sirve como la memoria externa del agente: jiro.state.json rastrea la historia actual, jiro.progress.json registra el trabajo completado entre iteraciones, y git diff proporciona la verdad sobre lo que realmente cambió.

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

El sistema Wink de Nanda et al. aborda lo que sucede cuando la degradación ya está en curso.⁶ Analizando más de 10.000 trayectorias de agentes del mundo real, encontraron que los comportamientos erróneos (desviación de especificaciones, bucles repetitivos, fallos en llamadas a herramientas) ocurren en aproximadamente el 30% de todas las sesiones. Wink observa la trayectoria del agente y proporciona correcciones dirigidas, resolviendo el 90% de los comportamientos erróneos de intervención única. La detección es en tiempo real: Wink identifica patrones de degradación a medida que emergen, en lugar de esperar a que un fallo se propague por el código.

Los costos

La iteración con contexto fresco no es gratuita. Tres costos:

1. Sobrecarga de orientación. Cada iteración gasta tokens releyendo estado que la iteración anterior ya comprendía. Mis mediciones muestran que entre el 15-20% del presupuesto de tokens de cada iteración se destina al paso de orientación: leer archivos de estado, escanear el historial reciente de git, reconstruir suficiente contexto para continuar. Una iteración de 200K tokens comienza con aproximadamente 160.000-170.000 tokens de capacidad útil.

2. Pérdida de conocimiento implícito. El contexto conversacional porta conocimiento implícito que el estado del sistema de archivos no puede capturar: 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 (por qué) se evapora entre iteraciones.

3. Costo de coordinación. Si múltiples bucles Ralph se ejecutan concurrentemente (implementación paralela de historias), cada bucle mantiene estado independiente. La coordinación entre bucles requiere lógica explícita de fusión y resolución de conflictos que una sesión larga única maneja implícitamente.

El cálculo costo-beneficio es claro: para sesiones de menos de 60 minutos, una sola conversación es más eficiente. Más allá de los 90 minutos, el patrón de contexto fresco produce resultados de mayor calidad a pesar de la sobrecarga de orientación. El punto de cruce depende de la complejidad de la tarea: un alto estado entre archivos adelanta el cruce; el trabajo aislado en un solo archivo lo retrasa.

Medir la degradación antes de que impacte

No necesitas esperar a un fallo en producción para detectar la degradación multi-turno. Tres métodos, del más simple al más exhaustivo:

Método 1: Monitoreo de presión del contexto

Rastrea la utilización del contexto en tiempo real. Mi hook context-pressure.sh se ejecuta después de cada llamada a herramienta y advierte 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: Rastreo de referencias cruzadas

Monitorea cuántos archivos distintos referencia el agente por salida. Una tendencia descendente 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 las afirmaciones arquitectónicas del agente a lo largo del tiempo. Si el agente afirma “el módulo A depende del módulo B” en el minuto 20 y “el módulo A no tiene dependencias externas” en el minuto 70, la coherencia se ha degradado. La versión automatizada: compara las declaraciones EXPLAIN del agente (o los comentarios de diseño) entre las salidas tempranas y tardías de la sesión.

Un protocolo para la resiliencia multi-turno

Tres niveles, cada uno abordando un mecanismo diferente. Comienza con el Nivel 1 y agrega capas según sea necesario.

Nivel 1: Puntos de control de estado

Cada 30 minutos, serializa la comprensión arquitectónica actual del agente en un archivo. No la conversación completa, sino el estado estructural: qué módulos existen, cómo se conectan, qué restricciones 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 continuar con contexto degradado.

Nivel 2: Iteraciones de contexto fresco

Para sesiones que superen los 60 minutos, cambia al patrón del bucle Ralph. La clave es el paso de orientación: inyectar suficiente estado para que el nuevo contexto continúe productivamente sin releer todo el historial de la conversación.

Estado requerido para el paso de orientación: 1. Tarea actual y criterios de aceptación 2. Archivos modificados en la iteración anterior (desde 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 multi-agente, establece un documento de estado compartido que todos los agentes lean y escriban. El documento sirve como fuente de verdad, previniendo 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 inicio de su turno y lo actualiza al final. Los conflictos disparan una pausa de coordinación en lugar de una divergencia silenciosa. Los mejores agentes operan así de manera invisible — como se explora en The Invisible Agent, el objetivo es una infraestructura que funcione sin que el desarrollador la note.

Conclusiones clave

• La degradación multi-turno es estructural, no un problema de longitud de contexto. El estudio de MSR/Salesforce mostró un 39% de degradación incluso cuando la longitud del contexto se mantuvo constante. Los límites entre turnos, no los límites de tokens, impulsan el colapso.¹
• Tres mecanismos independientes requieren tres intervenciones diferentes. La pérdida por compresión necesita puntos de control de estado. La pérdida de coherencia necesita iteración de contexto fresco. El fallo de coordinación necesita protocolos de estado compartido.
• El precipicio de los 90 minutos es real y medible. Rastrea la utilización del contexto, la diversidad de referencias cruzadas y las contradicciones arquitectónicas para detectar la degradación antes de que surjan fallos en producción.
• La iteración de contexto fresco funciona pero cuesta entre un 15-20% de sobrecarga. El patrón del bucle Ralph intercambia sobrecarga de orientación por presupuestos de contexto completos por iteración. El balance favorece el contexto fresco más allá de los 60-90 minutos.
• La asignación adaptativa de razonamiento supera a la profundidad uniforme. El enrutamiento cognitivo de decisiones de Du et al. logró una reducción del 34% en costos con una mejora del 23% en consistencia al ajustar la profundidad del razonamiento según las demandas de la tarea.²

FAQ

Referencias