Gérer les tâches d’agents IA : la boucle de réservation comme contrat, pas comme prompt

La gestion des tâches d’agents IA fonctionne quand c’est le tableau, et non le prompt, qui détient la boucle : l’agent demande quoi faire, réserve une tâche avec un bail qui expire s’il se tait, ne sollicite la personne que pour les décisions qui lui reviennent, et termine avec un reçu vérifiable. Dans Weft, chacune de ces étapes est un outil MCP contrôlé par le serveur : un agent qui saute une étape est refusé ou perd la tâche, au lieu de se désynchroniser en silence.

C’est nous qui faisons Weft. Les informations sur les autres produits viennent de leurs pages officielles, vérifiées le 27 octobre 2026.

Pourquoi une liste de tâches collée dans la conversation cesse-t-elle de fonctionner ?

Coller ses tâches dans une conversation, c’est la première chose que tout le monde essaie, et ça marche le temps d’un après-midi. Puis la conversation se termine, et l’état disparaît avec elle. L’agent savait quel élément il avait fini, lequel il avait abandonné et ce dont il n’était pas sûr. Désormais, personne ne le sait.

La personne qui a collé la liste devient le relais : elle recopie les résultats dans le vrai tableau et refait le travail qu’une deuxième session a repris faute de savoir qu’il était déjà pris.

Donner accès au tableau règle le problème de l’instantané, pas le reste. Si les seuls outils sont « déplacer la carte » et « ajouter un commentaire », la boucle dépend toujours du fait que l’agent suive une convention écrite dans ses instructions. Or les conventions cassent justement quand les choses tournent mal : l’agent plante en pleine exécution, ou deux agents démarrent au même instant.

À quoi ressemble la boucle de réservation sous forme de contrat ?

Dans Weft, la boucle compte cinq étapes, et chacune est un outil distinct sur un seul point de terminaison MCP, https://letsweft.com/api/mcp. Le serveur garde l’état entre elles, si bien que la boucle survit à la fin de n’importe quelle conversation.

1. get_my_work : demander avant de choisir. La réponse couvre ce que ce client tient déjà, ce qui attend la personne, ce qui est en retard ou bientôt dû, et s’il y a de la place pour démarrer quoi que ce soit.
2. start_task : réserver avec un bail. La réservation dure 20 minutes et passe la tâche dans Doing. La réponse contient un runId, un leaseToken et renewEverySeconds: 300. Un second client qui tente la même tâche reçoit already_claimed et une consigne de ne pas faire le travail en double.
3. report_progress : le signal de vie. Chaque appel avec l’id d’exécution et le jeton de bail renouvelle le bail. Si l’agent meurt, les signaux s’arrêtent, et 20 minutes plus tard l’exécution est marquée comme périmée et la tâche redevient non assignée, libre pour quiconque. Un bail perdu répond lease_lost : l’agent sait qu’il ne possède plus le travail.
4. request_input : seulement pour les décisions qui reviennent à la personne. Une question de 500 caractères au plus, avec jusqu’à 10 options. La réservation est conservée pendant que l’agent attend.
5. complete_task : terminer avec un reçu. outcome, artifacts (des preuves comme une URL, un commit ou un hachage de fichier), notDone, unknowns et nextStep.

Pourquoi un bail plutôt qu’un statut ? Parce que le silence est le seul signal qu’un agent planté peut envoyer. Une carte dans Doing dit que quelqu’un y a travaillé un jour. Un bail dit que quelqu’un y travaille maintenant, et cesse de le dire tout seul quand ce n’est plus vrai.

La réservation elle-même est une seule insertion en base de données protégée par un index unique. Quand deux agents font la course, c’est la base qui décide qui gagne : les deux ne peuvent pas obtenir la tâche. À l’inverse, deux commentaires « Pris » postés à une seconde d’intervalle sont deux commentaires parfaitement valides.

Quand l’agent doit-il appeler request_input ?

Quand il arrive à quelque chose que seule la personne peut décider : tout ce qui est irréversible, comme l’argent, la publication, la production ou le juridique, ou un véritable embranchement sans choix par défaut raisonnable. Pas pour demander la permission de continuer.

Cette retenue compte, car une question coûte à la personne la même attention qu’une tâche terminée, et dans Weft elle compte dans la même limite. La question arrive dans la boîte de réception, avec une notification push mobile et, pour les éléments qui attendent depuis 20 minutes ou plus, un rappel par e-mail. Weft ne rappelle jamais l’agent : la réponse lui parvient à son prochain start_task ou get_my_work. Tant que la question est ouverte, l’agent garde la tâche 60 minutes ; ensuite le bail tombe, mais la question reste.

Que met-on dans un appel complete_task ?

Un résultat court, des preuves, et un compte rendu honnête des zones grises. Voici une charge réaliste pour une correction de bug :

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

Les artefacts sont ce que la personne peut vérifier sans croire l’agent sur parole. notDone et unknowns ne sont pas des aveux ; ils font la différence entre un résultat fiable et un résultat qu’on reconstruit à partir du diff. L’appel n’échoue jamais faute de preuves, parce que perdre du travail terminé est pire que l’enregistrer sans vérification. Pour lire ces reçus, voir qu’a fait mon agent IA.

En quoi est-ce différent de déplacer une carte et poster un commentaire ?

Le guide d’Hypertask sur cette même boucle (réserver, mettre à jour, rendre compte, clore) décrit bien l’habitude. Sa version MCP de la réservation consiste à charger la tâche, la déplacer dans la section en cours et poster un commentaire de réservation, guidé par un prompt que l’équipe écrit dans les instructions de l’agent. Voici la même boucle, étape par étape :

Pour être juste envers Hypertask : il a de vrais baux. Sa documentation liste des points de terminaison pour réserver, signaler et libérer un bail, et son tableau Known limitations indique que les baux de tâche, les preuves et l’escalade sont uniquement des points de terminaison REST, par conception (présentation MCP d’Hypertask). Sa référence des outils ne contient aucun outil de bail parmi ses 21 outils MCP (référence des outils). Sa CLI peut aussi réserver, via une commande facultative (journal des modifications, référence CLI). Un agent scripté sur Hypertask peut donc tenir un bail ; un agent qui passe par MCP dans Claude Code ou Cursor obtient la version carte-et-commentaire, à moins que quelqu’un ne branche les appels REST.

Si vos agents tournent sous forme de scripts et de jobs de CI, la CLI et l’API REST d’Hypertask sont un vrai avantage, et Weft n’a ni l’une ni l’autre : pas de CLI, pas d’API REST publique, pas de webhooks. Weft s’adresse aux agents qui vivent dans un client MCP et ont besoin que la boucle tienne là.

Que voit la personne ?

La plupart du temps, une carte dans Done : par défaut, une tâche terminée y va directement, avec son résultat et ses preuves.

Une tâche s’arrête dans la boîte de réception de la personne quand elle a été marquée comme nécessitant une relecture, ou quand une vérification échoue. Là, la personne choisit l’une de quatre réponses :

• Accepter : le travail est validé. Si l’agent a fourni un nextStep, la personne le voit au-dessus du bouton (« Si vous acceptez, l’agent va … »), et accepter approuve exactement cette étape, rien de plus large. L’approbation vaut 72 heures et revient à l’agent via get_my_work ou start_task.
• À revoir : renvoyer le travail, avec une note qui dit ce qui ne va pas.
• Plus tard : pas maintenant. Abandonner : arrêter d’y travailler.

La boîte de réception est sur le web, et quand quelque chose y entre, la personne reçoit aussi une notification push sur l’appli mobile Weft. La poignée de main du nextStep empêche un agent de prendre « ça a l’air bien » pour une permission de fusionner, déployer et envoyer : il peut faire l’unique étape approuvée, puis terminer de nouveau la tâche.

Pourquoi l’agent est-il refusé au lieu de démarrer plus de travail ?

Parce que la ressource rare, c’est l’attention, pas le travail. Un agent peut démarrer dix choses dans le temps qu’il faut à une personne pour en relire une.

Weft compte ce qui attend les humains : les tâches en attente de relecture plus les questions ouvertes. Quand on atteint 5 éléments dans un espace d’une personne, 10 en équipe, ou environ 45 minutes de relecture estimée, selon ce qui arrive en premier, start_task refuse avec attention_queue_full. La limite dépend du nombre de personnes dans l’espace de travail, pas du forfait.

Le refus est une consigne, pas une impasse. Il indique la taille de la file, l’âge de l’élément le plus ancien et les appels encore permis : report_progress, get_my_work, get_board_state et search. Une étape que la personne a déjà approuvée sur cette carte est exemptée : un « merge PR #418 » accepté n’est pas bloqué par la file.

Comment mettre cela en place ?

Connectez votre client et identifiez-vous dans le navigateur ; aucune clé à copier. Weft émet des jetons de rafraîchissement : le client renouvelle la connexion tout seul. Dans Claude Code, c’est une seule commande, claude mcp add --transport http weft https://letsweft.com/api/mcp (page de configuration). Cursor s’installe en un clic (Cursor), Codex demande une entrée de configuration et codex mcp login weft (Codex), et ChatGPT a une appli Weft publiée sur tous les forfaits, y compris le gratuit (ChatGPT). Le serveur décrit lui-même la boucle à l’agent : aucun prompt de cycle de vie n’est nécessaire.

Pour un pas-à-pas avec Claude Code, voir un tableau de tâches pour Claude Code. Pour plusieurs agents sur un même tableau, là où les baux et already_claimed comptent le plus, voir plusieurs agents IA, un seul tableau. Le protocole lui-même est documenté sur modelcontextprotocol.io, et les autres tableaux MCP sont comparés sur gestionnaires de tâches MCP.

Ce que Weft ne fait pas ici

• Pas de CLI, d’API REST publique ni de webhooks : les tâches cron et les pipelines de CI ne peuvent pas piloter la boucle en dehors d’un client MCP.
• Pas d’intégration GitHub ou Slack. Les preuves, ce sont les liens que l’agent met dans artifacts.
• Pas d’IA intégrée. La réflexion se fait dans votre propre client IA, et c’est aussi pourquoi Weft n’a besoin d’aucun crédit d’IA.

Le gratuit couvre 50 tâches et 200 appels IA par mois. Pro coûte 7,80 € par place et par mois ou 66 € par place et par an (tarifs).

Un bon prompt ne suffit-il pas pour que les agents suivent la boucle ?

Un prompt décrit la boucle ; il ne peut pas la faire respecter. Il n’empêche pas deux agents de réserver la même tâche, et il ne peut pas libérer une tâche tenue par un agent qui a planté. Dans Weft, la réservation est un bail détenu par le serveur : ces cas sont gérés, que l’agent se souvienne ou non de ses instructions.

Que se passe-t-il si mon agent plante à mi-parcours ?

Ses signaux de vie s’arrêtent. Vingt minutes après le dernier report_progress, l’exécution est marquée comme périmée, le jeton de bail est effacé et la tâche redevient non assignée : un autre agent ou une personne peut la reprendre. La carte ne reste pas une semaine dans Doing.

Chaque tâche terminée attend-elle ma relecture ?

Non. Par défaut, une tâche terminée va directement dans Done avec son résultat et ses preuves. Elle s’arrête dans votre boîte de réception, pour Accepter, À revoir, Plus tard ou Abandonner, seulement quand elle demande une relecture ou qu’une vérification échoue.

Pourquoi voudrais-je que mon agent se voie refuser du travail ?

Parce que sinon, il continue de produire des choses que vous n’avez pas le temps de vérifier. Dès que 5 éléments (10 pour une équipe) ou environ 45 minutes de relecture attendent des humains, start_task renvoie attention_queue_full et oriente l’agent vers ce qu’il peut encore faire. Vider la file le débloque.

Hypertask a aussi des baux. Pourquoi MCP compte-t-il ?

Les baux d’Hypertask sont des points de terminaison REST, d’après sa propre documentation (présentation MCP), et sa CLI peut aussi réserver. Cela convient aux agents scriptés. Un agent qui passe par les outils MCP dans un éditeur ou une conversation n’y a pas accès ; dans Weft, si : start_task, report_progress et complete_task sont des outils MCP.