Degradação de Memória em Agentes de IA: Por Que Sessões Multi-Turn com LLMs Colapsam

Noventa minutos depois de construir meu sistema de deliberação, o agente parou de referenciar a arquitetura que havia discutido trinta minutos antes. Os logs da sessão mostraram que o Claude havia comprimido o grafo de dependências dos módulos para abrir espaço para novas saídas de ferramentas. O agente continuou escrevendo código, mas o código não refletia mais os contratos entre módulos que ele havia estabelecido na primeira hora. Os testes passaram. A integração falhou. O agente havia esquecido seu próprio design.

Essa falha me custou um dia inteiro de depuração. A pesquisa agora explica por que isso aconteceu.

TL;DR

A Microsoft Research e a Salesforce testaram 15 LLMs em mais de 200.000 conversas simuladas e encontraram uma queda média de 39% no desempenho entre interações single-turn e multi-turn.¹ A degradação começa em apenas dois turnos. Três mecanismos independentes causam o colapso: a compressão de contexto descarta estado crítico, a coerência do raciocínio se fragmenta conforme o orçamento de tokens diminui, e a coordenação entre agentes quebra sem uma fonte de verdade compartilhada. Janelas de contexto maiores não resolvem nenhum deles. O padrão do Ralph loop (contexto limpo por iteração com estado no sistema de arquivos) contorna a perda por compressão, mas introduz seus próprios custos. A seguir: a pesquisa, os três mecanismos, métodos de detecção que você pode executar hoje, e um protocolo para resiliência multi-turn.

O Penhasco dos 90 Minutos

Meu post sobre contexto como arquitetura documentou um sistema de contexto de sete camadas abrangendo 650 arquivos. Construir esse sistema exigiu sessões de codificação estendidas onde o agente precisava manter estado arquitetural complexo: fronteiras de módulos, cadeias de dependência, ordem de execução de hooks e contratos entre arquivos.

Medi a qualidade das sessões ao longo de 30 iterações do Ralph loop em janeiro e fevereiro de 2026. Os dados mostraram um padrão 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

O penhasco de qualidade apareceu independentemente do tipo de tarefa. Sessões longas de refatoração, construção de suítes de teste e passes de documentação — todas degradaram na mesma curva. O que variava era a severidade: tarefas que exigiam mais estado entre arquivos atingiam o penhasco com mais força do que trabalho isolado em um único arquivo.

Atribuí o padrão à pressão na janela de contexto e construí o Ralph loop para contornar isso. Criar uma nova instância do Claude por iteração; injetar estado a partir do sistema de arquivos; nunca depender de memória conversacional além de uma iteração. O padrão funciona. Porém, o estudo da MSR/Salesforce publicado em maio de 2025 revelou que o problema é mais estrutural do que apenas o tamanho da janela de contexto.

Três Mecanismos do Colapso Multi-Turn

Laban et al. decompuseram a degradação multi-turn em mecanismos independentes, e a distinção importa porque cada um requer uma intervenção estruturalmente diferente.¹

Mecanismo 1: Compressão de Contexto

Toda conversa de IA opera dentro de um orçamento finito de tokens. Conforme a conversa cresce, o sistema comprime turnos anteriores para abrir espaço para novo conteúdo. A compressão é com perda. Decisões arquiteturais documentadas no turno 3 podem não sobreviver até o turno 15.

Identifiquei isso diretamente durante a construção do sistema de deliberação. O agente estabeleceu um grafo de dependências de módulos nos primeiros 20 minutos: deliberation_engine.py depende de consensus_calculator.py, que depende de vote_aggregator.py. Por volta do minuto 75, o agente havia comprimido a cadeia de dependências e escreveu um ciclo de importação. O código era sintaticamente válido. A importação circular causou um crash em tempo de execução.

Detecção: Acompanhe a proporção de referências entre arquivos na saída do agente ao longo do tempo. Quando o agente para de referenciar arquivos que discutiu anteriormente, a compressão provavelmente descartou o 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: Perda de Coerência no Raciocínio

O estudo da MSR/Salesforce descobriu que a degradação multi-turn se decompõe em dois componentes: uma perda menor de aptidão e um aumento significativo de falta de confiabilidade.¹ A aptidão mede se o modelo consegue produzir uma resposta correta. A confiabilidade mede se ele faz isso de forma consistente.

No modo single-turn, os modelos alcançaram aproximadamente 90% de desempenho médio em seis tarefas de geração. No modo multi-turn, o desempenho caiu para aproximadamente 65%: uma queda absoluta de 25 pontos. A descoberta crítica: “Quando LLMs tomam um caminho errado em conversas multi-turn, eles se perdem e não se recuperam.”¹

A perda de coerência no raciocínio se manifesta quando o agente contradiz suas próprias decisões anteriores. Não porque o sistema comprimiu o contexto (mecanismo 1), mas porque a cadeia de raciocínio do modelo se fragmentou entre turnos. Cada turno tem raciocínio localmente sólido, mas globalmente inconsistente.

O trabalho de Du et al. sobre roteamento cognitivo de decisões aborda esse mecanismo diretamente.² Inspirado pela teoria de processos duais de Kahneman (respostas intuitivas rápidas vs. raciocínio deliberado lento), o sistema adapta a profundidade do raciocínio com base nas demandas da tarefa. O insight: nem todo turno do agente requer a mesma profundidade de raciocínio, e aplicar profundidade uniforme desperdiça orçamento em etapas triviais enquanto subinveste em decisões críticas.

Detecção: Procure contradições entre a saída no início e no final da sessão. Se o agente defende a abordagem A no minuto 15 e a abordagem B no minuto 60 sem reconhecer a mudança, a coerência degradou.

Mecanismo 3: Falha de Coordenação

Sistemas multi-agente amplificam a degradação multi-turn com falhas de coordenação. Quando dois ou mais agentes colaboram em uma tarefa, o contexto de cada agente degrada independentemente. Um agente que esqueceu uma restrição compartilhada não consegue coordenar em torno dela.

Bhardwaj et al. abordam isso com Agent Context Protocols, estabelecendo canais de comunicação estruturados entre agentes.³ O framework alcançou 28,3% de precisão no AssistantBench ao definir protocolos explícitos para compartilhamento de contexto, propagação de erros e sincronização de estado. O Unified Agent Communication Protocol de Krishnan estende isso com fronteiras de segurança zero-trust entre agentes.⁴

Encontrei falha de coordenação durante uma deliberação com 10 agentes onde três revisores avaliaram a mesma mudança de código. Na quarta rodada de revisão, os agentes haviam divergido sobre como era a “versão atual” do código. O contexto de cada agente continha um snapshot diferente. As revisões se contradiziam não porque discordavam, mas porque revisavam código diferente.

Detecção: Em fluxos multi-agente, compare as premissas de estado que cada agente mantém. Se os agentes referenciam versões diferentes do mesmo artefato, a coordenação falhou.

Por Que Janelas de Contexto Maiores Não Resolvem

A resposta intuitiva à degradação multi-turn é “dar mais tokens ao modelo.” O estudo da MSR/Salesforce refuta essa intuição com um design experimental inteligente.

Eles testaram uma condição “Concat”: apresentar a conversa multi-turn completa como um único prompt concatenado. A condição Concat alcançou 95,1% do desempenho single-turn.¹ O comprimento do contexto era idêntico à condição multi-turn. O conteúdo de informação era idêntico. A única diferença era a estrutura de interação: um turno vs. vários turnos.

A degradação de 39% não é um problema de comprimento de contexto. Dobrar a janela de contexto de 200K para 400K tokens não eliminaria a degradação, porque ela vem das fronteiras entre turnos, não da falta de espaço.

A descoberta do Concat corresponde aos meus dados de produção. O Claude opera com aproximadamente 200.000 tokens de contexto. Minhas medições de gerenciamento de janela de contexto mostraram que as execuções mais longas em sessão única (3+ horas, uso intenso de ferramentas) consomem aproximadamente 180.000 tokens antes de a compactação ser acionada. Mas a qualidade degrada bem antes de a janela encher. O penhasco dos 90 minutos ocorre com aproximadamente 60-70% de utilização do contexto, não no limite. A dívida cognitiva resultante se acumula conforme o agente produz código mais rápido do que um desenvolvedor consegue verificar. Este é o mesmo problema de contexto composto em uma escala diferente: cada turno adiciona informação que interage de forma não linear com o que veio antes.

O roteamento cognitivo de decisões de Du et al. reformula o problema: a questão não é quantos tokens o modelo consegue manter, mas quão eficientemente o modelo aloca recursos de raciocínio entre esses tokens.² O sistema alcançou uma redução de 34% nos custos computacionais com uma melhoria de 23% na consistência, roteando decisões simples pelo raciocínio rápido e decisões complexas pelo raciocínio deliberado.

A Solução de Contexto Limpo (E Seus Custos)

O Ralph loop resolve o mecanismo 1 (compressão) e parcialmente resolve o mecanismo 2 (coerência) ao nunca executar uma conversa tempo suficiente para que qualquer um deles se manifeste. Cada iteração cria uma nova instância do Claude com uma janela de contexto completa de 200K tokens. O estado persiste através do sistema de arquivos, não da memória 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 iteração recebe o orçamento completo de contexto. Sem artefatos de compressão de turnos anteriores. Sem fragmentos de coerência de cadeias de raciocínio anteriores. O sistema de arquivos serve como a memória externa do agente: jiro.state.json rastreia a história atual, jiro.progress.json registra o trabalho concluído entre iterações, e git diff fornece a verdade sobre o que realmente mudou.

O Recursive Language Models de Zhang, Kraska e Khattab adota uma abordagem complementar: em vez de criar novas instâncias, o modelo descarrega contexto para um ambiente REPL Python e raciocina sobre o contexto em código em vez de espaço de tokens.⁵ O RLM-Qwen3-8B superou sua linha de base em 28,3% em tarefas de contexto longo ao tratar prompts longos como estruturas de dados externas em vez de memória interna. Onde o Ralph loop externaliza estado em arquivos, os RLMs externalizam estado em código. Ambos os padrões resolvem o mesmo problema de compressão por mecanismos diferentes.

O sistema Wink de Nanda et al. aborda o que acontece quando a degradação já está em andamento.⁶ Analisando mais de 10.000 trajetórias reais de agentes, eles descobriram que maus comportamentos (desvio de especificação, loops repetitivos, falhas em chamadas de ferramentas) ocorrem em aproximadamente 30% de todas as sessões. O Wink observa a trajetória do agente e fornece correção de curso direcionada, resolvendo 90% dos maus comportamentos com intervenção única. A detecção é em tempo real: o Wink identifica padrões de degradação conforme eles surgem, em vez de esperar que uma falha se propague pelo codebase.

Os Custos

Iteração com contexto limpo não é gratuita. Três custos:

1. Overhead de orientação. Cada iteração gasta tokens relendo estado que a iteração anterior já compreendia. Minhas medições mostram que 15-20% do orçamento de tokens de cada iteração vai para a etapa de orientação: ler arquivos de estado, examinar histórico recente do git, reconstruir contexto suficiente para continuar. Uma iteração de 200K tokens começa com aproximadamente 160-170K tokens de capacidade utilizável.

2. Conhecimento implícito perdido. O contexto conversacional carrega conhecimento implícito que o estado no sistema de arquivos não consegue capturar: o raciocínio por trás de uma decisão de design, as alternativas consideradas e rejeitadas, a nuance de por que a abordagem A foi escolhida em vez da B. A etapa de orientação injeta fatos (o que mudou, o que vem a seguir). O raciocínio (por quê) evapora entre iterações.

3. Custo de coordenação. Se múltiplos Ralph loops rodam concorrentemente (implementação paralela de histórias), cada loop mantém estado independente. Coordenar entre loops requer lógica explícita de merge e resolução de conflitos que uma sessão longa única gerencia implicitamente.

O cálculo custo-benefício é claro: para sessões com menos de 60 minutos, uma única conversa é mais eficiente. Além de 90 minutos, o padrão de contexto limpo produz saída de maior qualidade apesar do overhead de orientação. O ponto de cruzamento depende da complexidade da tarefa: alto estado entre arquivos empurra o cruzamento para mais cedo; trabalho isolado em arquivo único empurra para mais tarde.

Medindo a Degradação Antes Que Ela Aconteça

Você não precisa esperar por uma falha em produção para detectar degradação multi-turn. Três métodos, do mais simples ao mais completo:

Método 1: Monitoramento de Pressão de Contexto

Acompanhe a utilização do contexto em tempo real. Meu hook context-pressure.sh executa após cada chamada de ferramenta e alerta quando a utilização excede 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: Rastreamento de Referências Cruzadas

Monitore quantos arquivos distintos o agente referencia por saída. Uma tendência de queda sinaliza perda por compressão:

# 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: Detecção de Contradições

Compare as afirmações arquiteturais do agente ao longo do tempo. Se o agente afirma “módulo A depende do módulo B” no minuto 20 e “módulo A não tem dependências externas” no minuto 70, a coerência degradou. A versão automatizada: faça diff das declarações EXPLAIN do agente (ou comentários de design) entre saídas do início e do final da sessão.

Um Protocolo para Resiliência Multi-Turn

Três níveis, cada um abordando um mecanismo diferente. Comece pelo Nível 1 e adicione camadas conforme necessário.

Nível 1: Checkpoint de Estado

A cada 30 minutos, serialize o entendimento arquitetural atual do agente em um arquivo. Não a conversa completa, mas o estado estrutural: quais módulos existem, como se conectam, quais restrições se aplicam.

# 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

Se o comportamento do agente degradar, restaure a partir do checkpoint em vez de continuar com contexto degradado.

Nível 2: Iterações com Contexto Limpo

Para sessões que excedem 60 minutos, mude para o padrão Ralph loop. O ponto-chave é a etapa de orientação: injetar estado suficiente para o novo contexto continuar produtivamente sem reler todo o histórico da conversa.

Estado necessário para a etapa de orientação: 1. Tarefa atual e critérios de aceitação 2. Arquivos modificados na iteração anterior (via git diff) 3. Decisões arquiteturais e seus raciocínios 4. Restrições conhecidas e modos de falha

Nível 3: Protocolos de Coordenação de Agentes

Para fluxos multi-agente, estabeleça um documento de estado compartilhado que todos os agentes leem e escrevem. O documento serve como fonte de verdade, prevenindo a divergência que observei durante as revisões de deliberação.

{
  "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 lê este documento no início do seu turno e o atualiza no final. Conflitos disparam uma pausa de coordenação em vez de divergência silenciosa. Os melhores agentes operam dessa forma de maneira invisível — como explorado em The Invisible Agent, o objetivo é infraestrutura que funciona sem o desenvolvedor perceber.

Pontos-Chave

• A degradação multi-turn é estrutural, não um problema de comprimento de contexto. O estudo da MSR/Salesforce mostrou 39% de degradação mesmo quando o comprimento do contexto permaneceu constante. As fronteiras entre turnos, não os limites de tokens, causam o colapso.¹
• Três mecanismos independentes requerem três intervenções diferentes. Perda por compressão precisa de checkpoint de estado. Perda de coerência precisa de iteração com contexto limpo. Falha de coordenação precisa de protocolos de estado compartilhado.
• O penhasco dos 90 minutos é real e mensurável. Acompanhe utilização do contexto, diversidade de referências cruzadas e contradições arquiteturais para detectar degradação antes que falhas em produção se manifestem.
• Iteração com contexto limpo funciona, mas custa 15-20% de overhead. O padrão Ralph loop troca overhead de orientação por orçamentos completos de contexto por iteração. A troca favorece contexto limpo além de 60-90 minutos.
• Alocação adaptativa de raciocínio supera profundidade uniforme. O roteamento cognitivo de decisões de Du et al. alcançou 34% de redução de custo com 23% de melhoria em consistência ao adequar a profundidade do raciocínio às demandas da tarefa.²

FAQ

Referências