Vous avez branché un LLM sur votre processus métier. Au bout de quelques échanges, il déraille. Ce n'est pas un bug de modèle — c'est un bug d'architecture.
C'est l'un des patterns les plus frustrants en automatisation IA : votre agent fonctionne parfaitement sur les 5 premières étapes, puis commence à halluciner, à oublier des contraintes, ou à répéter des erreurs déjà commises. La tentation est de blâmer le modèle. La réalité, c'est souvent que vous lui faites porter un contexte de plus en plus lourd et de moins en moins pertinent.
Une recherche récente, publiée par l'Alaya Lab en collaboration avec l'université Shanghai Jiao Tong, illustre ce problème de façon saisissante — et propose une solution architecturale concrète.
Slay the Spire 2 comme banc d'essai : un jeu, mais un vrai problème d'ingénierie
Les chercheurs ont choisi le jeu de cartes roguelike Slay the Spire 2 pour tester leurs agents IA. Ce choix n'est pas anodin : une partie complète implique des centaines de décisions enchaînées (choix de cartes, gestion des combats, navigation sur la carte, achats en boutique). Les règles sont entièrement verbalisables en texte, le hasard est élevé, et les parties sont longues. C'est, en somme, un excellent proxy pour un workflow métier complexe.
Résultat des tests avec les meilleurs modèles frontier dans le cadre de l'évaluation AGI-Eval : zéro victoire sur cinq configurations testées. À titre de comparaison, les joueurs humains gagnent 16 % des parties sur le niveau de difficulté le plus bas.
Le problème identifié ? Ces modèles accumulent l'intégralité de l'historique de conversation à chaque décision. Au bout de quelques dizaines d'étapes, le contexte est saturé d'informations périmées, redondantes ou tout simplement inutiles pour la décision courante. Le modèle se noie.
L'approche AgenticSTS : remplacer le log par une mémoire structurée en couches
Le projet AgenticSTS renverse la logique habituelle : l'agent ne consulte jamais son propre historique de chat. À la place, chaque décision est reconstruite à partir d'un catalogue fixe d'informations organisées en cinq couches de mémoire :
- L'état courant du jeu : ce qui est observable maintenant (cartes en main, points de vie, ennemis présents)
- Les connaissances statiques : les règles du jeu, les effets des cartes — l'équivalent de votre documentation métier
- La mémoire épisodique : un résumé structuré des événements passés pertinents, pas un log brut
- Les stratégies apprises : des patterns extraits des runs précédents
- Les objectifs en cours : ce que l'agent cherche à accomplir à court et moyen terme
Chaque couche est maintenue et mise à jour indépendamment. Seul ce qui est utile à la décision courante est injecté dans le prompt. Le résultat : l'agent gagne des parties là où les modèles frontier échouaient.
Ce que cela change concrètement pour vos automatisations PHP/Symfony
Ce pattern de mémoire structurée est directement transposable dans vos projets d'automatisation. Voici comment le traduire en pratique :
Arrêtez de passer l'historique brut des messages
Si votre agent Symfony construit son contexte en concaténant tous les échanges précédents, vous reproduisez exactement l'erreur identifiée par les chercheurs. Remplacez ce log par des structures de données dédiées, mises à jour à chaque étape.
// ❌ Anti-pattern : historique brut croissant
$messages[] = ['role' => 'user', 'content' => $userInput];
$messages[] = ['role' => 'assistant', 'content' => $lastResponse];
// ... le contexte grossit indéfiniment
// ✅ Pattern AgenticSTS : contexte reconstruit à chaque étape
$context = $this->contextBuilder->build(
currentState: $workflowState->getCurrent(),
staticKnowledge: $this->knowledgeBase->getRelevant($task),
episodicSummary: $this->memoryStore->getSummary($sessionId),
activeGoals: $workflowState->getGoals()
);
Modélisez votre domaine métier comme connaissance statique
Vos règles métier, vos contraintes, vos SLA — tout ce qui ne change pas d'une exécution à l'autre — doivent vivre dans une couche de connaissance statique, chargée une fois et injectée de façon ciblée. En Symfony, un service dédié avec mise en cache Doctrine ou Redis est la bonne approche.
Maintenez un résumé structuré, pas un transcript
Après chaque étape significative, faites synthétiser par le LLM (ou par votre propre logique) les informations utiles à retenir. Stockez ce résumé dans une entité Doctrine avec les métadonnées nécessaires (timestamp, importance, type d'information). C'est votre mémoire épisodique.
Cette approche s'intègre naturellement avec des outils comme pgvector pour la recherche sémantique sur vos souvenirs, ou simplement avec des requêtes SQL filtrées si votre domaine est bien structuré.
Conclusion : la structure de données, premier levier de performance de votre agent
La recherche AgenticSTS confirme une intuition que tout développeur Symfony expérimenté devrait avoir : la qualité de l'entrée détermine la qualité de la sortie. Un LLM puissant avec un contexte mal structuré donnera de moins bons résultats qu'un modèle plus modeste avec un contexte rigoureusement organisé.
Avant d'upgrader votre modèle ou d'augmenter votre fenêtre de contexte, posez-vous la question : est-ce que je passe à mon agent l'information dont il a besoin, ou est-ce que je lui passe tout ce qui s'est passé ?
La réponse à cette question vaut souvent bien plus qu'un changement de modèle.
Source : The Decoder — AI agents win at Slay the Spire 2 after researchers replace growing chat logs with structured memory
