Degradação de memória em agentes de IA: por que LLMs entram em colapso em conversas multi-turno

Noventa minutos depois de começar a construir meu sistema de deliberação⁹, o agente parou de citar a arquitetura que ele mesmo havia discutido trinta minutos antes. Os logs da sessão mostraram que o Claude tinha comprimido e descartado o grafo de dependências entre módulos para abrir espaço para novas saídas de ferramentas. O agente continuou escrevendo código, mas esse código já não refletia os contratos entre módulos que ele havia estabelecido na primeira hora. Os testes passavam. A integração falhava. O agente tinha esquecido o 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 da interação de turno único para a interação multi-turno.¹ A degradação começa com apenas dois turnos. Três mecanismos independentes provocam 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 encolhe e a coordenação entre agentes se desfaz sem uma fonte de verdade compartilhada. Aumentar a janela de contexto não resolve nenhum deles. O padrão do loop Ralph (contexto novo a cada iteração, com o estado no sistema de arquivos) contorna a perda por compressão, mas traz custos próprios. A seguir: a pesquisa, os três mecanismos, métodos de detecção que você pode aplicar hoje mesmo e um protocolo de resiliência multi-turno.

O abismo dos 90 minutos

Meu post sobre contexto como arquitetura⁸ documentou um sistema de contexto em sete camadas espalhado por 650 arquivos. Construir esse sistema exigiu sessões longas de programação em que o agente precisava sustentar um estado arquitetural complexo: fronteiras entre módulos, cadeias de dependências, ordem de execução dos ganchos e contratos entre arquivos.

Medi a qualidade das sessões ao longo de 30 iterações do loop Ralph em janeiro e fevereiro de 2026.⁷ Os dados mostraram um padrão consistente:

Minutos 0-30:   Edições precisas em vários arquivos, referências cruzadas corretas
Minutos 30-60:  Imports esquecidos de vez em quando, ainda recuperável
Minutos 60-90:  Visão de túnel em um único arquivo, perde o contexto arquitetural
Minutos 90+:    Tentativas repetitivas, contradiz decisões anteriores

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

Atribuí o padrão à pressão sobre a janela de contexto e construí o loop Ralph para contorná-la. Uma instância nova do Claude a cada iteração; o estado injetado a partir do sistema de arquivos; nenhuma dependência de memória conversacional além de uma iteração. O padrão funciona. Mas o estudo da MSR/Salesforce publicado em maio de 2025 revelou que o problema é mais estrutural do que o simples tamanho da janela de contexto.

Três mecanismos do colapso multi-turno

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

Mecanismo 1: compressão de contexto

Toda conversa com IA opera dentro de um orçamento finito de tokens. À medida que a conversa cresce, o sistema comprime os turnos anteriores para dar lugar ao conteúdo novo. Essa compressão tem perdas. Decisões de arquitetura documentadas no turno 3 podem não sobreviver até o turno 15.

Flagrei isso durante a construção do sistema de deliberação. O agente estabeleceu um grafo de dependências entre módulos nos primeiros 20 minutos: deliberation_engine.py depende de consensus_calculator.py, que depende de vote_aggregator.py. Aos 75 minutos, o agente já havia comprimido e descartado a cadeia de dependências e escreveu um ciclo de imports. O código era sintaticamente válido. O import circular derrubou a aplicação 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 mencionar arquivos que discutiu antes, é provável que a compressão tenha descartado 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-turno se decompõe em dois componentes: uma perda pequena de aptidão e um aumento expressivo da falta de confiabilidade.¹ A aptidão mede se o modelo é capaz de produzir uma resposta correta. A confiabilidade mede se ele faz isso de forma consistente.

No modo de turno único, os modelos alcançaram cerca de 90% de desempenho médio em seis tarefas de geração. No modo multi-turno, o desempenho caiu para aproximadamente 65%: uma queda absoluta de 25 pontos. A constatação decisiva: “quando LLMs tomam o rumo errado em uma conversa multi-turno, eles se perdem e não se recuperam”.¹

A perda de coerência no raciocínio se manifesta quando o agente contradiz as próprias decisões anteriores. Não porque o sistema tenha comprimido e descartado o contexto (mecanismo 1), mas porque a cadeia de raciocínio do modelo se fragmentou entre os turnos. O raciocínio de cada turno é sólido localmente, porém inconsistente no conjunto.

O trabalho de Du et al. sobre roteamento cognitivo de decisões ataca esse mecanismo diretamente.² Inspirado na teoria dos dois processos de Kahneman (respostas rápidas e intuitivas versus raciocínio lento e deliberado), o sistema deles adapta a profundidade do raciocínio às exigências da tarefa. A ideia por trás disso: nem todo turno do agente exige a mesma profundidade de raciocínio, e aplicar uma profundidade uniforme desperdiça orçamento em passos triviais e investe pouco nas decisões críticas.

Detecção: procure contradições entre o que o agente produz no início e no fim da sessão. Se ele defende a abordagem A aos 15 minutos e a abordagem B aos 60 sem reconhecer a mudança, a coerência se degradou.

Mecanismo 3: falha de coordenação

Em sistemas multiagente, a falha de coordenação se soma à degradação multi-turno. Quando dois ou mais agentes colaboram em uma tarefa, o contexto de cada um se degrada de forma independente. Um agente que esqueceu uma restrição compartilhada não consegue se coordenar em torno dela.

Os Agent Context Protocols de Bhardwaj et al. atacam isso estabelecendo canais de comunicação estruturados entre agentes.³ O framework deles alcançou 28,3% de acurácia 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 essa ideia com fronteiras de segurança de confiança zero entre agentes.⁴

Esbarrei em uma falha de coordenação durante uma deliberação com 10 agentes em que três revisores avaliavam a mesma mudança de código. Na quarta rodada de revisão, os agentes já divergiam sobre como era a “versão atual” do código. O contexto de cada agente guardava um retrato diferente. As revisões se contradiziam não porque discordassem, mas porque revisavam códigos diferentes.

Detecção: em fluxos de trabalho multiagente, compare as suposições de estado que cada agente sustenta. Se os agentes citam versões diferentes do mesmo artefato, a coordenação falhou.

Por que janelas de contexto maiores não resolvem o problema

A resposta intuitiva à degradação multi-turno é “dê mais tokens ao modelo”. O estudo da MSR/Salesforce refuta essa intuição com um desenho experimental engenhoso.

Eles testaram uma condição “Concat”: apresentar a conversa multi-turno inteira como um único prompt concatenado. A condição Concat atingiu 95,1% do desempenho de turno único.¹ O comprimento do contexto era idêntico ao da condição multi-turno. O conteúdo informacional era idêntico. A única diferença estava na estrutura da interação: um turno contra muitos turnos.

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

O achado do Concat bate com meus dados de produção. O Claude opera com cerca de 200.000 tokens de contexto. Minhas medições de gerenciamento da janela de contexto mostraram que as execuções mais longas em uma única sessão (mais de 3 horas, com uso intenso de ferramentas) consomem aproximadamente 180.000 tokens antes de a compactação disparar. Mas a qualidade se degrada muito antes de a janela encher. O abismo dos 90 minutos acontece por volta de 60% a 70% de utilização do contexto, não no limite. A dívida cognitiva resultante se acumula à medida que o agente produz código mais rápido do que um desenvolvedor consegue verificar. É o mesmo problema do contexto composto em outra escala: cada turno acrescenta 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 sustentar, e sim com que eficiência ele distribui recursos de raciocínio entre esses tokens.² O sistema deles obteve redução de 34% nos custos computacionais com melhora de 23% na consistência, encaminhando decisões simples pelo raciocínio rápido e decisões complexas pelo raciocínio deliberado.

A solução do contexto novo (e o que ela custa)

O loop Ralph resolve o mecanismo 1 (compressão) e resolve parcialmente o mecanismo 2 (coerência) porque nunca deixa uma conversa se estender o bastante para que qualquer um dos dois se manifeste. Cada iteração cria uma instância nova do Claude com a janela completa de 200 mil tokens. O estado persiste no sistema de arquivos, não na 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 de contexto inteiro. Nenhum artefato de compressão dos turnos anteriores. Nenhum fragmento de coerência de cadeias de raciocínio antigas. O sistema de arquivos funciona como memória externa do agente: jiro.state.json registra a história em andamento, jiro.progress.json guarda o trabalho concluído ao longo das iterações e o git diff fornece a verdade de referência sobre o que realmente mudou.

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

O sistema Wink, de Nanda et al., trata do que acontece quando a degradação já está em curso.⁶ Analisando mais de 10.000 trajetórias reais de agentes, eles descobriram que comportamentos anômalos (desvio da especificação, loops repetitivos, falhas em chamadas de ferramentas) aparecem em aproximadamente 30% de todas as sessões. O Wink observa a trajetória do agente e oferece correções de rumo direcionadas, resolvendo 90% dos casos que se corrigem com uma única intervenção. A detecção é em tempo real: o Wink identifica padrões de degradação conforme eles surgem, em vez de esperar que a falha se espalhe pela base de código.

Os custos

A iteração com contexto novo não sai de graça. São três custos:

1. Sobrecarga de orientação. Toda iteração gasta tokens relendo um estado que a iteração anterior já entendia. Minhas medições mostram que 15% a 20% do orçamento de tokens de cada iteração vai para a etapa de orientação: ler arquivos de estado, varrer o histórico recente do git, reconstruir contexto suficiente para continuar. Uma iteração de 200 mil tokens começa com cerca de 160 mil a 170 mil tokens de capacidade utilizável.

2. Conhecimento implícito perdido. O contexto conversacional carrega um conhecimento implícito que o estado em arquivos não captura: o raciocínio por trás de uma escolha de design, as alternativas consideradas e descartadas, a nuance de por que a abordagem A foi preferida à B. A etapa de orientação injeta fatos (o que mudou, o que vem a seguir). O raciocínio (o porquê) evapora entre as iterações.

3. Custo de coordenação. Se vários loops Ralph rodam ao mesmo tempo (implementação de histórias em paralelo), cada loop mantém o próprio estado. Coordená-los exige lógica explícita de merge e resolução de conflitos que uma única sessão longa resolve de forma implícita.

A conta de custo-benefício é clara: para sessões de menos de 60 minutos, uma conversa única é mais eficiente. Passados 90 minutos, o padrão de contexto novo entrega resultado de qualidade superior, apesar da sobrecarga de orientação. O ponto de cruzamento depende da complexidade da tarefa: muito estado espalhado entre arquivos o antecipa; trabalho isolado em um único arquivo o adia.

Medir a degradação antes que ela chegue

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

Método 1: monitoramento da pressão de contexto

Acompanhe a utilização do contexto em tempo real. Meu gancho context-pressure.sh roda depois de cada chamada de ferramenta e avisa quando a utilização passa de 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 ele diz “o módulo A depende do módulo B” aos 20 minutos e “o módulo A não tem dependências externas” aos 70, a coerência se degradou. A versão automatizada: faça um diff das declarações EXPLAIN do agente (ou dos comentários de design) entre as saídas do começo e do fim da sessão.

Um protocolo de resiliência multi-turno

Três níveis, cada um voltado a um mecanismo diferente. Comece pelo nível 1 e acrescente camadas conforme a necessidade.

Nível 1: checkpoints de estado

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

# 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 se degradar, restaure a partir do checkpoint em vez de continuar com o contexto deteriorado.

Nível 2: iterações com contexto novo

Para sessões que passam de 60 minutos, mude para o padrão do loop Ralph. A chave está na etapa de orientação: injetar estado suficiente para que o contexto novo consiga continuar de forma produtiva 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 (a partir do git diff) 3. Decisões de arquitetura e o raciocínio por trás delas 4. Restrições conhecidas e modos de falha

Nível 3: protocolos de coordenação entre agentes

Para fluxos de trabalho multiagente, estabeleça um documento de estado compartilhado que todos os agentes leiam e escrevam. Esse documento funciona como fonte de verdade e evita a divergência que observei nas 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ê esse documento no começo do seu turno e o atualiza no fim. Conflitos disparam uma pausa de coordenação em vez de uma divergência silenciosa. Os melhores agentes trabalham assim, de forma invisível — como explorei em O agente invisível, o objetivo é uma infraestrutura que funcione sem que o desenvolvedor perceba.

Principais conclusões

• A degradação multi-turno é estrutural, não um problema de comprimento de contexto. O estudo da MSR/Salesforce mostrou 39% de degradação mesmo com o comprimento do contexto mantido constante. O que provoca o colapso são as fronteiras entre turnos, não os limites de tokens.¹
• Três mecanismos independentes exigem três intervenções diferentes. A perda por compressão pede checkpoints de estado. A perda de coerência pede iteração com contexto novo. A falha de coordenação pede protocolos de estado compartilhado.
• O abismo dos 90 minutos é real e mensurável. Acompanhe a utilização do contexto, a diversidade de referências cruzadas e as contradições arquiteturais para detectar a degradação antes que ela apareça em produção.
• A iteração com contexto novo funciona, mas custa de 15% a 20% de sobrecarga. O padrão do loop Ralph troca a sobrecarga de orientação pelo orçamento de contexto completo em cada iteração. A balança pende para o contexto novo depois de 60 a 90 minutos.
• Alocar raciocínio de forma adaptativa vence a profundidade uniforme. O roteamento cognitivo de decisões de Du et al. obteve 34% de redução de custo com 23% de melhora na consistência ao ajustar a profundidade do raciocínio às exigências da tarefa.²

FAQ

Referências