Faire tourner une flotte d’agents IA sur un seul tableau de tâches

Dès que vous faites travailler plusieurs agents IA sur la même liste de tâches, un nouveau problème apparaît, qu’un agent seul ne rencontre jamais : deux agents peuvent voir la même tâche prête et tenter tous deux de la prendre en charge. Une application de tâches conçue pour une seule personne qui coche des cases n’a aucune raison de résoudre cela. Une application de tâches pour agents IA, si.

Le problème de la double prise en charge

Si « prendre une tâche en charge » n’est qu’une mise à jour de statut, deux agents qui interrogent la même file au même moment peuvent tous deux la lire comme disponible et commencer à y travailler : au mieux un effort gaspillé, au pire des résultats contradictoires. La solution n’est pas une convention que les agents seraient censés respecter. Elle consiste à rendre la prise en charge elle-même atomique, pour que la tentative du second agent ne trouve tout simplement rien.

Comment Done évite qu’une flotte se marche sur les pieds

• next_task : un retrait atomique de la file. Il prend en charge la tâche prête la plus prioritaire et la renvoie. Un second agent qui l’appelle un instant plus tard obtient la suivante, jamais la même tâche.
• release_task : remet dans la file une tâche prise en charge si un agent ne peut pas la terminer tout de suite, au lieu de la laisser coincée entre deux états.
• fleet_status : un instantané en direct de chaque tâche actuellement prise en charge par un agent, depuis combien de temps, et si la réservation a expiré.
• Budgets d’exécution : start_run, check_budget et end_run bornent ce qu’une session peut faire, pour qu’un seul agent ne puisse pas vider discrètement toute la file.

Ce que fleet_status montre réellement

Avant de saisir une tâche, un agent (ou vous) peut appeler fleet_status pour voir exactement ce qui est déjà pris en charge dans la flotte : quelle tâche, par quel agent, depuis combien de temps, et si la prise en charge a expiré (ce qui veut dire que celui qui la détenait ne donne plus signe de vie et que la tâche est de nouveau disponible). C’est la même visibilité que vous voudriez en entrant dans une pièce où plusieurs personnes travaillent déjà.

Concevoir le flux de travail d’une flotte

Il n’y a pas une seule bonne forme. Certaines configurations font tourner un agent généraliste en boucle, qui appelle next_task jusqu’à ce que la file soit vide. D’autres répartissent par projet ou par rôle (un agent pour le backlog d’un projet précis, un autre pour une file de maintenance récurrente), avec des jetons restreints pour limiter la vue de chacun à son couloir. Les équipes qui regroupent les agents de plusieurs personnes sur un même tableau sont celles qui s’appuient le plus sur fleet_status, puisque c’est exactement le problème de visibilité que créent les tableaux partagés.

Vérifier ce que la flotte a fait

Chaque session d’agent est une exécution, consignée avec son propre budget d’appels d’outils et de temps. start_run l’ouvre, end_run la referme avec un résumé et un résultat, et check_budget indique à un agent (ou à vous) ce qu’il reste de l’enveloppe de cette session avant qu’elle ne soit purement et simplement refusée. De son côté, list_claude_shipped vous donne un fil clair de tout ce qu’un agent a réellement marqué comme terminé, du plus récent au plus ancien. C’est utile pour un point d’équipe, une rétrospective, ou simplement pour répondre à la question « qu’ont abattu les agents cette semaine ? ».

Quand une flotte n’est pas la bonne forme

La plupart des gens n’en ont pas besoin. Un seul agent connecté qui parcourt une file par ordre de priorité couvre très bien le cas courant, et fleet_status comme l’atomicité de next_task ne vous coûtent rien si vous ne lancez jamais de second agent. Cette mécanique se justifie précisément quand vous faites tourner plusieurs agents en parallèle, ou quand le tableau d’une équipe en offre Teams voit les agents de plusieurs personnes travailler dans le même espace de travail partagé.