Un agent peut produire un résultat convaincant et se tromper sur l’état de son propre travail. Dans un processus à plusieurs agents, un résultat peut aussi être correct au moment du contrôle et ne plus correspondre au candidat livré. C’est une raison centrale de mon choix d’un moteur déterministe pour Swarm : rendre les préconditions et les transitions explicites pendant l’exécution.
Les travaux de Cursor sur les agents autonomes de longue durée ont nourri cette réflexion, notamment autour de la séparation entre planification et exécution et des difficultés de coordination. Les mécanismes retenus pour Swarm sont mes choix d’architecture.
Quand le vert ne concerne plus le bon candidat
Considérons une tâche de développement. Un premier agent produit V1 et les contrôles identifiés réussissent. Un second agent corrige ensuite un détail, créant V2. Si le système conserve seulement une étiquette « tests verts », il peut autoriser la suite sur la foi d’un résultat qui ne porte plus sur les fichiers actuels.
Cette confusion peut laisser entrer une régression ou une configuration incorrecte dans une livraison. Elle n’exige ni attaque sophistiquée ni mauvaise intention : une modification légitime suffit à rendre une preuve obsolète. Le problème est le lien entre le résultat observé et l’objet sur lequel on décide.
Une preuve de contrôle qualifie des entrées identifiées ; elle ne qualifie pas automatiquement leur prochaine version.
Le processus doit conserver la tentative, les commandes réellement exécutées, leurs résultats et les artefacts requis. Avant la transition suivante, il doit vérifier que ces éléments correspondent encore au candidat et à la politique applicables. Si le lien est rompu, il faut reprendre les contrôles concernés, sans réécrire l’historique de V1.
Ce que le moteur peut vérifier
Dans les sources Rust actuelles de Swarm, la vérification des preuves compare notamment la tentative courante, le contrôleur attendu et l’empreinte de la politique. Elle examine les contrôles configurés, leur exécution, leur réussite et les artefacts attendus. Une absence ou une incohérence ne devient pas un succès vide.
Ces vérifications portent sur un contrat défini. Elles ne prouvent pas que la liste des contrôles est suffisante, que les tests couvrent tous les défauts ou que toutes les dépendances non déclarées ont été observées. Un moteur déterministe peut appliquer avec constance une règle insuffisante.
En mode humain, la réussite des contrôles doit rester distincte de l’approbation : un état en attente d’un humain ne doit pas être présenté comme une acceptation. En mode automatique, les exigences de contrôle et de revue applicables restent à établir sur le même candidat.
Le graphe sert à comprendre ce qui bloque
Le graphe devient utile lorsqu’il relie les prérequis, la tâche, la preuve attendue et la cause d’un refus. L’opérateur doit pouvoir distinguer une tâche non lancée, un contrôle échoué, une preuve périmée et une décision encore attendue. Une reprise apporte alors une nouvelle condition ou une nouvelle preuve ; elle ne consiste pas à répéter la même action jusqu’à obtenir un état vert.
Cette visibilité ne fournit pas pour autant un accès complet à l’activité interne d’un fournisseur. Une consommation ou un coût non observé doit rester inconnu. Le moteur n’installe pas non plus, par sa seule présence, un confinement des processus ou du réseau.
Quelle preuve pour la livraison ?
Pour notre scénario, le résultat attendu est précis : conserver la réussite historique de V1, refuser sa réutilisation indue sur V2, puis réévaluer V2 avec les contrôles nécessaires. La preuve d’une vérification locale reste distincte de la preuve du binaire réellement déployé.
Dans Swarm, les agents analysent, proposent et réalisent ; le moteur vérifie les conditions prévues aux frontières qu’il contrôle ; l’humain conserve les décisions qui lui reviennent. La qualité dépend de ces trois responsabilités et des limites que l’on sait encore reconnaître.