Les coding harnesses convergent : Cursor Projects, Codex Worktrees, /skill-doctor — persistance + sous-agents + état partagé

TL;DR : En l'espace de cinq jours, trois grands coding harnesses et un nouveau venu ont publié des choix d'architecture presque identiques : un fil de coordinateur persistant, des sous-agents délégués et un état partagé. Ceux qui se limitent aujourd'hui à l'approche « un chat par tâche » sont à la traîne face à cette ligne de convergence. Cet article fournit un tableau de correspondance et une checklist en 3 points pour évaluer votre propre stack.

Le modèle : trois caractéristiques, quatre produits

Les quatre systèmes compressent le travail agentique sous la même forme de base : persistant (le contexte survit au chat individuel), sous-agents (le coordinateur délègue au lieu de taper du code lui-même), état partagé (les plans, démos et fichiers de contexte évoluent de concert).

Ce qui a concrètement changé

Cursor Projects remplace le principe « un chat par tâche ». Le coordinateur n'écrit pas de code lui-même — il planifie, délègue à des sous-agents parallèles et consolide les résultats. Les agents au sein d'un projet partagent la mémoire et les artefacts tels que les plans et les démos ; ces fichiers se synchronisent automatiquement entre les appareils et les ordinateurs des agents. Les watchers (PR, Slack, planification) continuent de tourner sans nécessiter de nouveau prompt.

Codex CLI 0.154.0 introduit les worktrees sous forme de checkouts isolés pour les sessions nouvelles ou forkées, avec possibilité de recherche et de reprise. Sous Windows, le serveur en arrière-plan partage désormais une instance entre les sessions. C'est l'aboutissement de cette même évolution : les agents parallèles ne se battent plus pour un seul et même checkout.

Claude Code fait du pruning (élagage) une opération de premier ordre avec /skill-doctor : les skills sont nettoyés automatiquement pour éviter que le contexte partagé ne gonfle inutilement.

Pion transpose cette grammaire au niveau de l'entreprise : l'agent manager Andonos délègue à des agents commerciaux qui gèrent de manière autonome des distributeurs automatiques, des marchés et des stations de radio. L'architecture ne diffère pas structurellement de Cursor Projects — seule l'échelle change.

La checklist en 3 points pour votre stack

1. Persistance : Existe-t-il un contexte qui survit aux sessions individuelles (thread de projet, AGENTS.md, couche de fichiers partagée) ?
2. Sous-agents : Votre coordinateur délègue-t-il à des workers parallèles ou écrit-il tout de A à Z dans un seul fil de discussion ?
3. État partagé (Shared State) : Les agents écrivent-ils leurs plans et leurs découvertes dans une couche de sources commune et évolutive ?

Plus vous remplissez de critères, plus votre stack se rapproche de la ligne de convergence de septembre 2026. Si vous avez un score de zéro, la migration représentera un véritable gain opérationnel, et pas seulement une simple mise à jour de fonctionnalités.

Pourquoi cette convergence est importante en pratique

Ces trois caractéristiques ne sont pas indépendantes : la persistance rend l'état partagé pertinent, l'état partagé rend la délégation viable, et la délégation exige la persistance. L'ordre d'implémentation est donc tout tracé : d'abord la couche de contexte, ensuite le coordinateur, puis les workers.

Le prochain point fort des notes de mise à jour (changelogs) est déjà prévisible : la performance des harnesses. Pour les vérifications de worktree, des gains de vitesse d'environ 80 % sont annoncés grâce aux clones de dossiers sur APFS, Btrfs, XFS et ReFS. Ceux qui mesurent leurs performances seront les premiers à disposer de valeurs de référence fiables.

FAQ

Quel est l'avantage d'un projet persistant par rapport à des chats individuels ? Le coordinateur n'a pas besoin de reconstruire le contexte à chaque nouvelle tâche. Les plans, démos et découvertes sont conservés sous forme de fichiers partagés et s'enrichissent au fil de l'eau. Pour les travaux récurrents, les rituels de prompts répétitifs disparaissent, ce qui réduit le taux d'erreur par tâche.

Pourquoi ai-je besoin de worktrees dans une session d'agent ? Un worktree donne à chaque session (nouvelle ou forkée) son propre checkout isolé. Ainsi, les agents parallèles ne se gênent plus mutuellement dans le même répertoire de travail. Les checkouts peuvent être parcourus et repris ultérieurement, rendant les forks et les reviews beaucoup plus pragmatiques.

Que fait /skill-doctor dans Claude Code ? La commande nettoie automatiquement les fichiers de skills du projet (suppression/élagage des instructions obsolètes ou en double). Cela permet de conserver un contexte partagé léger, et donc plus rapide et moins coûteux. Pour les grands ensembles de skills, c'est l'opération de maintenance la plus évidente.

Pion est-il un énième chatbot ou un modèle à part entière ? Pion est un agent conçu sur mesure (purpose-built) qui gère des entreprises de manière autonome : Andonos, en tant qu'agent manager, délègue aux agents commerciaux. Le projet repose sur des expérimentations observées en continu (distributeurs automatiques, marché, café et stations de radio). La différence avec un simple modèle réside dans la logique opérationnelle continue, et non dans le nombre de paramètres.

Dans quel ordre dois-je adapter ma stack à ce modèle ? Créez d'abord la couche de contexte partagé — un niveau de fichiers que tous les agents peuvent lire et modifier. Établissez ensuite le coordinateur, qui planifie et délègue au lieu de coder lui-même. Enfin, ajoutez les sous-agents et les déclencheurs (triggers) pour les tâches liées aux PR, à Slack et aux plannings.

Sources

• https://x.com/cursor_ai/status/2098162488013455784
• https://x.com/CodexReleases/status/2097817395930735015
• https://updatify.io/releases/codex-cli
• https://flaviocopes.com/cursor-projects
• https://andonlabs.com/pion
• https://andonlabs.com/blog/why-we-built-pion
• https://x.com/andonlabs/status/2099547565759062090
• https://x.com/steipete/status/2099207638994690181