Dégradation de la mémoire des agents IA : pourquoi les conversations multi-tours des LLMs s'effondrent

Quatre-vingt-dix minutes après le début de la construction de mon système de délibération, l’agent a cessé de référencer l’architecture qu’il avait discutée trente minutes plus tôt. Les journaux de session montraient que Claude avait compressé le graphe de dépendances des modules pour faire de la place aux nouvelles sorties d’outils. L’agent a continué à écrire du code, mais ce code ne reflétait plus les contrats inter-modules qu’il avait établis durant la première heure. Les tests passaient. L’intégration échouait. L’agent avait oublié sa propre conception.

Cette défaillance m’a coûté une journée entière de débogage. La recherche explique désormais pourquoi cela s’est produit.

TL;DR

Microsoft Research et Salesforce ont testé 15 LLMs sur plus de 200 000 conversations simulées et constaté une baisse moyenne de performance de 39 % entre l’interaction mono-tour et multi-tours.¹ La dégradation commence dès deux tours. Trois mécanismes indépendants provoquent l’effondrement : la compression du contexte élimine l’état critique, la cohérence du raisonnement se fragmente à mesure que le budget de tokens se réduit, et la coordination entre agents s’effondre sans vérité partagée. Des fenêtres de contexte plus grandes ne corrigent aucun de ces problèmes. Le patron de boucle Ralph (contexte neuf par itération avec état sur le système de fichiers) contourne la perte par compression mais introduit ses propres coûts. Ci-dessous : la recherche, les trois mécanismes, les méthodes de détection applicables dès aujourd’hui, et un protocole pour la résilience multi-tours.

La falaise des 90 minutes

Mon article sur le contexte comme architecture documentait un système de contexte à sept couches couvrant 650 fichiers. Construire ce système nécessitait des sessions de codage prolongées où l’agent devait maintenir un état architectural complexe : frontières de modules, chaînes de dépendances, ordre d’exécution des hooks et contrats inter-fichiers.

J’ai mesuré la qualité des sessions sur 30 itérations de la boucle Ralph en janvier et février 2026. Les données révélaient un schéma constant :

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

La falaise de qualité apparaissait quel que soit le type de tâche. Les longues sessions de refactoring, la construction de suites de tests et les passes de documentation se dégradaient tous selon la même courbe. Ce qui variait, c’était la sévérité : les tâches nécessitant davantage d’état inter-fichiers atteignaient la falaise plus rapidement que le travail isolé sur un seul fichier.

J’ai attribué ce schéma à la pression sur la fenêtre de contexte et construit la boucle Ralph pour le contourner. Lancer une nouvelle instance de Claude par itération ; injecter l’état depuis le système de fichiers ; ne jamais compter sur la mémoire conversationnelle au-delà d’une seule itération. Le patron fonctionne. Toutefois, l’étude MSR/Salesforce publiée en mai 2025 a révélé que le problème est plus structurel que la simple taille de la fenêtre de contexte.

Trois mécanismes de l’effondrement multi-tours

Laban et al. ont décomposé la dégradation multi-tours en mécanismes indépendants, et cette distinction est importante car chacun nécessite une intervention structurellement différente.¹

Mécanisme 1 : Compression du contexte

Toute conversation IA opère dans un budget de tokens fini. À mesure que la conversation s’allonge, le système compresse les tours précédents pour faire de la place au nouveau contenu. La compression est avec perte. Les décisions architecturales documentées au tour 3 peuvent ne pas survivre jusqu’au tour 15.

J’ai constaté ce phénomène directement lors de la construction du système de délibération. L’agent avait établi un graphe de dépendances de modules dans les 20 premières minutes : deliberation_engine.py dépend de consensus_calculator.py, qui dépend de vote_aggregator.py. À la minute 75, l’agent avait compressé la chaîne de dépendances et écrit un cycle d’importation. Le code était syntaxiquement valide. L’importation circulaire provoquait un crash à l’exécution.

Détection : Suivez le ratio de références inter-fichiers dans la sortie de l’agent au fil du temps. Lorsque l’agent cesse de référencer des fichiers qu’il avait discutés précédemment, la compression a probablement éliminé le contexte pertinent.

# 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

Mécanisme 2 : Perte de cohérence du raisonnement

L’étude MSR/Salesforce a constaté que la dégradation multi-tours se décompose en deux composantes : une perte d’aptitude mineure et une augmentation significative de l’instabilité.¹ L’aptitude mesure si le modèle peut produire une réponse correcte. La fiabilité mesure s’il le fait de manière constante.

En mode mono-tour, les modèles atteignaient environ 90 % de performance moyenne sur six tâches de génération. En mode multi-tours, la performance chutait à environ 65 % : un déclin absolu de 25 points. Le constat crucial : « Lorsque les LLMs prennent un mauvais virage dans une conversation multi-tours, ils se perdent et ne récupèrent pas. »¹

La perte de cohérence du raisonnement se manifeste par l’agent qui contredit ses propres décisions antérieures. Non pas parce que le système a compressé le contexte (mécanisme 1), mais parce que la chaîne de raisonnement du modèle s’est fragmentée entre les tours. Chaque tour produit un raisonnement localement cohérent mais globalement incohérent.

Les travaux de Du et al. sur le routage cognitif des décisions abordent directement ce mécanisme.² Inspiré par la théorie du double processus de Kahneman (réponses intuitives rapides vs. raisonnement délibéré lent), leur système adapte la profondeur de raisonnement en fonction des exigences de la tâche. L’idée clé : chaque tour d’agent ne nécessite pas la même profondeur de raisonnement, et appliquer une profondeur uniforme gaspille du budget sur des étapes triviales tout en sous-investissant dans les décisions critiques.

Détection : Recherchez les contradictions entre les sorties de début et de fin de session. Si l’agent préconise l’approche A à la minute 15 et l’approche B à la minute 60 sans reconnaître le changement, la cohérence s’est dégradée.

Mécanisme 3 : Échec de coordination

Les systèmes multi-agents aggravent la dégradation multi-tours par l’échec de coordination. Lorsque deux agents ou plus collaborent sur une tâche, le contexte de chaque agent se dégrade indépendamment. Un agent qui a oublié une contrainte partagée ne peut pas coordonner autour d’elle.

Les Agent Context Protocols de Bhardwaj et al. répondent à ce problème en établissant des canaux de communication structurés entre agents.³ Leur framework a atteint 28,3 % de précision sur AssistantBench en définissant des protocoles explicites pour le partage de contexte, la propagation d’erreurs et la synchronisation d’état. Le Unified Agent Communication Protocol de Krishnan étend cette approche avec des frontières de sécurité zero-trust entre agents.⁴

J’ai rencontré l’échec de coordination lors d’une délibération à 10 agents où trois relecteurs évaluaient la même modification de code. Au quatrième tour de relecture, les agents avaient divergé sur l’apparence de la « version actuelle » du code. Le contexte de chaque agent contenait un instantané différent. Leurs relectures se contredisaient non pas parce qu’ils étaient en désaccord, mais parce qu’ils examinaient du code différent.

Détection : Dans les workflows multi-agents, comparez les hypothèses d’état que chaque agent détient. Si les agents référencent des versions différentes du même artefact, la coordination a échoué.

Pourquoi des fenêtres de contexte plus grandes ne résolvent rien

La réaction intuitive face à la dégradation multi-tours est « donnez au modèle plus de tokens ». L’étude MSR/Salesforce réfute cette intuition grâce à un protocole expérimental ingénieux.

Ils ont testé une condition « Concat » : présenter l’intégralité de la conversation multi-tours comme un seul prompt concaténé. La condition Concat a atteint 95,1 % de la performance mono-tour.¹ La longueur du contexte était identique à la condition multi-tours. Le contenu informationnel était identique. La seule différence résidait dans la structure d’interaction : un tour vs. plusieurs tours.

La dégradation de 39 % n’est pas un problème de longueur de contexte. Doubler la fenêtre de contexte de 200K à 400K tokens n’éliminerait pas la dégradation, car celle-ci provient des frontières entre les tours eux-mêmes, pas du manque d’espace.

Le résultat Concat correspond à mes données de production. Claude opère avec environ 200 000 tokens de contexte. Mes mesures de gestion de la fenêtre de contexte ont montré que les sessions les plus longues (3+ heures, utilisation intensive d’outils) consomment environ 180 000 tokens avant le déclenchement de la compaction. Or la qualité se dégrade bien avant que la fenêtre ne se remplisse. La falaise des 90 minutes survient à environ 60-70 % d’utilisation du contexte, pas à la limite. La dette cognitive résultante s’accumule à mesure que l’agent produit du code plus vite qu’un développeur ne peut le vérifier. C’est le même problème de contexte composé à une échelle différente : chaque tour ajoute de l’information qui interagit de manière non linéaire avec ce qui précède.

Les travaux de Du et al. sur le routage cognitif des décisions recadrent le problème : l’enjeu n’est pas le nombre de tokens que le modèle peut contenir, mais l’efficacité avec laquelle il alloue ses ressources de raisonnement à travers ces tokens.² Leur système a obtenu une réduction de 34 % des coûts computationnels avec une amélioration de 23 % de la cohérence en routant les décisions simples vers un raisonnement rapide et les décisions complexes vers un raisonnement délibéré.

La solution du contexte neuf (et ses coûts)

La boucle Ralph résout le mécanisme 1 (compression) et résout partiellement le mécanisme 2 (cohérence) en ne laissant jamais une conversation durer assez longtemps pour que l’un ou l’autre se manifeste. Chaque itération lance une nouvelle instance de Claude avec un contexte complet de 200K tokens. L’état persiste à travers le système de fichiers, pas à travers la mémoire conversationnelle.

# 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

Chaque itération bénéficie du budget de contexte complet. Pas d’artefacts de compression des tours précédents. Pas de fragments de cohérence issus de chaînes de raisonnement antérieures. Le système de fichiers sert de mémoire externe à l’agent : jiro.state.json suit la story en cours, jiro.progress.json enregistre le travail accompli entre les itérations, et git diff fournit la vérité terrain sur ce qui a réellement changé.

Les Recursive Language Models de Zhang, Kraska et Khattab adoptent une approche complémentaire : au lieu de lancer de nouvelles instances, le modèle externalise le contexte vers un environnement REPL Python et raisonne sur le contexte en code plutôt qu’en espace de tokens.⁵ RLM-Qwen3-8B a surpassé sa ligne de base de 28,3 % sur les tâches de contexte long en traitant les prompts longs comme des structures de données externes plutôt que comme de la mémoire interne. Là où la boucle Ralph externalise l’état vers des fichiers, les RLMs externalisent l’état vers du code. Les deux patrons résolvent le même problème de compression par des mécanismes différents.

Le système Wink de Nanda et al. aborde ce qui se passe lorsque la dégradation est déjà en cours.⁶ En analysant plus de 10 000 trajectoires d’agents en conditions réelles, ils ont constaté que les dysfonctionnements (dérive de spécification, boucles répétitives, échecs d’appels d’outils) surviennent dans environ 30 % de toutes les sessions. Wink observe la trajectoire de l’agent et fournit une correction de cap ciblée, résolvant 90 % des dysfonctionnements à intervention unique. La détection est en temps réel : Wink identifie les schémas de dégradation à mesure qu’ils émergent plutôt que d’attendre qu’une défaillance se propage dans la base de code.

Les coûts

L’itération en contexte neuf n’est pas gratuite. Trois coûts :

1. Surcoût d’orientation. Chaque itération dépense des tokens à relire un état que l’itération précédente avait déjà assimilé. Mes mesures montrent que 15 à 20 % du budget de tokens de chaque itération va à l’étape d’orientation : lecture des fichiers d’état, scan de l’historique Git récent, reconstruction de suffisamment de contexte pour continuer. Une itération de 200K tokens démarre avec environ 160 000 à 170 000 tokens de capacité utile.

2. Perte de connaissance implicite. Le contexte conversationnel porte une connaissance implicite que l’état du système de fichiers ne peut pas capturer : le raisonnement derrière un choix de conception, les alternatives envisagées et rejetées, la nuance de pourquoi l’approche A a été préférée à l’approche B. L’étape d’orientation injecte des faits (ce qui a changé, la suite). Le raisonnement (le pourquoi) s’évapore entre les itérations.

3. Coût de coordination. Si plusieurs boucles Ralph s’exécutent simultanément (implémentation parallèle de stories), chaque boucle maintient un état indépendant. Coordonner entre les boucles nécessite une logique explicite de fusion et de résolution de conflits qu’une seule longue session gère implicitement.

Le calcul coût-bénéfice est clair : pour les sessions de moins de 60 minutes, une seule conversation est plus efficace. Au-delà de 90 minutes, le patron de contexte neuf produit des résultats de meilleure qualité malgré le surcoût d’orientation. Le point de croisement dépend de la complexité de la tâche : un état inter-fichiers élevé avance le croisement ; un travail isolé sur un seul fichier le retarde.

Mesurer la dégradation avant qu’elle ne frappe

Nul besoin d’attendre une défaillance en production pour détecter la dégradation multi-tours. Trois méthodes, de la plus simple à la plus approfondie :

Méthode 1 : Surveillance de la pression contextuelle

Suivez l’utilisation du contexte en temps réel. Mon hook context-pressure.sh s’exécute après chaque appel d’outil et alerte lorsque l’utilisation dépasse 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éthode 2 : Suivi des références croisées

Surveillez le nombre de fichiers distincts que l’agent référence par sortie. Une tendance déclinante signale une perte par compression :

# 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éthode 3 : Détection des contradictions

Comparez les affirmations architecturales de l’agent au fil du temps. Si l’agent affirme « le module A dépend du module B » à la minute 20 et « le module A n’a aucune dépendance externe » à la minute 70, la cohérence s’est dégradée. La version automatisée : comparez les déclarations EXPLAIN de l’agent (ou ses commentaires de conception) entre les sorties de début et de fin de session.

Un protocole pour la résilience multi-tours

Trois niveaux, chacun ciblant un mécanisme différent. Commencez par le niveau 1 et ajoutez des couches selon les besoins.

Niveau 1 : Points de contrôle d’état

Toutes les 30 minutes, sérialisez la compréhension architecturale actuelle de l’agent dans un fichier. Pas la conversation complète, mais l’état structurel : quels modules existent, comment ils se connectent, quelles contraintes s’appliquent.

# 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 le comportement de l’agent se dégrade, restaurez depuis le point de contrôle plutôt que de continuer avec un contexte dégradé.

Niveau 2 : Itérations en contexte neuf

Pour les sessions dépassant 60 minutes, passez au patron de boucle Ralph. L’élément clé est l’étape d’orientation : injecter suffisamment d’état pour que le nouveau contexte puisse continuer de manière productive sans relire l’intégralité de l’historique de conversation.

État requis pour l’étape d’orientation : 1. Tâche en cours et critères d’acceptation 2. Fichiers modifiés lors de l’itération précédente (via git diff) 3. Décisions architecturales et leur raisonnement 4. Contraintes connues et modes de défaillance

Niveau 3 : Protocoles de coordination entre agents

Pour les workflows multi-agents, établissez un document d’état partagé que tous les agents lisent et écrivent. Ce document sert de vérité terrain, empêchant la divergence que j’ai observée lors des relectures de délibération.

{
  "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}
  ]
}

Chaque agent lit ce document au début de son tour et le met à jour à la fin. Les conflits déclenchent une pause de coordination plutôt qu’une divergence silencieuse. Les meilleurs agents fonctionnent ainsi de manière invisible — comme exploré dans The Invisible Agent, l’objectif est une infrastructure qui fonctionne sans que le développeur ne la remarque.

Points clés à retenir

• La dégradation multi-tours est structurelle, pas un problème de longueur de contexte. L’étude MSR/Salesforce a montré 39 % de dégradation même lorsque la longueur du contexte restait constante. Ce sont les frontières entre les tours, pas les limites de tokens, qui provoquent l’effondrement.¹
• Trois mécanismes indépendants nécessitent trois interventions différentes. La perte par compression nécessite des points de contrôle d’état. La perte de cohérence nécessite l’itération en contexte neuf. L’échec de coordination nécessite des protocoles d’état partagé.
• La falaise des 90 minutes est réelle et mesurable. Suivez l’utilisation du contexte, la diversité des références croisées et les contradictions architecturales pour détecter la dégradation avant que des défaillances en production ne surviennent.
• L’itération en contexte neuf fonctionne mais coûte 15 à 20 % de surcoût. Le patron de boucle Ralph échange le surcoût d’orientation contre des budgets de contexte complets par itération. Le compromis favorise le contexte neuf au-delà de 60 à 90 minutes.
• L’allocation adaptative du raisonnement surpasse la profondeur uniforme. Le routage cognitif des décisions de Du et al. a obtenu 34 % de réduction des coûts avec 23 % d’amélioration de la cohérence en adaptant la profondeur de raisonnement aux exigences de la tâche.²

FAQ

Références