Et si le vrai problème des agents IA n'était pas leur intelligence, mais leur mémoire ?
On a longtemps pensé que pour obtenir de meilleurs agents IA, il fallait des modèles plus puissants. Cursor vient de démontrer le contraire : ce qui bride les agents sur des tâches complexes, ce n'est pas leur capacité de raisonnement, c'est la gestion du contexte. Une leçon directement applicable à vos projets Symfony d'envergure.
La dérive contextuelle : le talon d'Achille des agents solo
Un agent IA qui travaille seul sur une tâche longue souffre d'un problème structurel : il doit simultanément garder en tête l'objectif global, la tâche en cours, et l'historique de tout ce qu'il a déjà fait. Plus le projet grandit, plus la fenêtre de contexte se remplit, et plus l'agent perd de vue l'essentiel.
Concrètement, cela se traduit par des comportements erratiques : l'agent refactorise du code qu'il vient de créer, introduit des incohérences entre modules, ou simplement "oublie" des contraintes établies en début de session. Sur un projet Symfony avec plusieurs bundles, des entités Doctrine complexes et des services imbriqués, ce phénomène devient rapidement bloquant.
Cursor a mis en évidence ce problème de façon spectaculaire en demandant à son ancienne architecture d'agent de réécrire SQLite en Rust à partir de la seule documentation, sans accès au code source ni à internet. Résultat : l'agent s'est enlisé dans ses propres conflits de merge.
L'architecture Planner/Worker : diviser pour mieux régner
La réponse de Cursor avec sa version 3 repose sur une séparation stricte des responsabilités entre deux types d'agents :
Les agents Planner utilisent des modèles frontier (puissants, coûteux) et ont une seule mission : décomposer récursivement un objectif en sous-tâches. Ils ne touchent jamais au code.
Les agents Worker utilisent des modèles plus légers et moins coûteux, et exécutent les tâches feuilles de l'arbre généré par les Planners. Ils ne prennent aucune décision architecturale.
Ce découplage génère un arbre de tâches dynamique qui s'adapte à l'avancement du travail. Chaque Worker opère avec un contexte minimal et précis : il sait ce qu'il doit faire, mais n'a pas à se soucier du reste. Résultat avec la nouvelle architecture : 100 % de réussite sur la suite de tests du projet SQLite/Rust, dans toutes les configurations testées.
L'insight clé de Cursor est contre-intuitif : les essaims d'agents ne scalent pas principalement grâce au parallélisme, mais grâce à la séparation du contexte. C'est une distinction fondamentale pour quiconque envisage d'orchestrer des agents sur des bases de code réelles.
Application concrète à vos projets Symfony
Cette architecture n'est pas réservée aux labos de recherche. Elle dessine un pattern d'orchestration applicable dès aujourd'hui dans un contexte PHP/Symfony.
Identifier vos "Planner tasks" vs vos "Worker tasks"
Sur un projet Symfony typique, la frontière est naturelle :
- Planner : analyser un besoin métier, concevoir le schéma d'une nouvelle feature (entités, services, handlers), définir les contrats d'interface, planifier une migration
- Worker : générer une entité Doctrine à partir d'un schéma défini, écrire un test unitaire pour un service donné, implémenter une méthode dont la signature est fixée, créer une migration SQL
Les tâches Worker sont bornées, vérifiables et peu sensibles à la dérive contextuelle. Ce sont précisément celles que les modèles moins chers gèrent très bien.
L'implication sur les coûts
Le corollaire économique est significatif. Si les modèles frontier (GPT-4o, Claude Opus, Gemini Ultra) restent nécessaires pour la planification, la majeure partie du travail d'exécution peut être déléguée à des modèles bien moins onéreux. Sur un projet où 80 % des tokens consommés l'étaient en phase d'exécution, le gain peut être considérable.
Dans une architecture Symfony orientée agents, cela se traduit par une décision claire : investir votre budget de tokens frontier dans la conception, et utiliser des modèles économiques pour la génération de code répétitif (formulaires, CRUD, tests, migrations).
Vers un orchestrateur maison avec Symfony Messenger ?
L'architecture décrite par Cursor ressemble fort à un système de queues avec priorités et dépendances — terrain sur lequel Symfony Messenger excelle. Un Planner pourrait publier des messages typés dans un bus, que des Workers consommeraient de façon asynchrone, chacun avec son propre contexte minimal injecté dans le message.
Ce n'est pas de la science-fiction : des équipes commencent à construire des pipelines d'agents orchestrés via Messenger, avec des LLM légers en workers et des modèles frontier sollicités uniquement pour les décisions structurantes.
Conclusion : l'architecture avant la puissance
Le vrai enseignement de l'expérience Cursor n'est pas "les petits modèles peuvent tout faire". C'est que la qualité de l'architecture d'orchestration détermine la qualité du résultat, indépendamment de la puissance brute des modèles.
Pour les équipes Symfony qui évaluent l'intégration d'agents IA dans leur workflow, c'est une invitation à penser en termes de séparation des responsabilités — exactement comme on le ferait avec du code humain. Un agent qui planifie ne devrait pas coder. Un agent qui code ne devrait pas planifier.
La dérive contextuelle n'est pas une fatalité : c'est un problème de design.
Source : The Decoder, juillet 2026.
