Qu’a fait mon agent IA ? Quatre questions auxquelles répondre preuves à l’appui

Pour savoir ce qu’a fait votre agent IA, ne commencez pas par son résumé. Vérifiez quatre choses : quelle connexion a fait le travail, ce qui a changé (montré par quelque chose que vous pouvez ouvrir vous-même), ce qui n’a pas été fait, et ce qui a été décidé et pourquoi. Si l’un de ces quatre points ne repose que sur la parole de l’agent, vous avez un récit, pas un enregistrement.

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 un commentaire « terminé » ne suffit-il pas ?

Un commentaire, c’est l’agent qui décrit son propre travail. Il est peut-être exact, mais le commentaire ne peut pas le démontrer, puisque son auteur est justement la partie que vous cherchez à vérifier. Savoir qu’un agent a touché une tâche répond à la question « qui ». Cela ne vous dit pas si le travail est bien ce que vous croyez.

L’article d’Hypertask sur l’attribution du travail IA fait une remarque juste : le travail des agents doit atterrir sur le même tableau que celui des humains, pas dans un journal de terminal que personne ne lit. Hypertask donne aussi aux agents leur propre identité comme comptes de service, si bien que les écritures sont attribuées à l’agent et non à vous, et il a des preuves et des baux de tâche, même si sa documentation précise que ce sont uniquement des points de terminaison REST, pas des outils MCP, par conception. Là où nous divergeons, c’est sur ce que l’enregistrement doit contenir. Un fil de commentaires avec la sortie de l’agent est un journal de ce que l’agent a dit. Nous voulons que l’enregistrement contienne des preuves.

Il n’y a aucun chiffre d’enquête dans ce guide. Vous pouvez tester les quatre questions sur votre propre tableau cet après-midi, et cela vous en dira plus qu’une moyenne du secteur.

Quelles sont les quatre questions ?

Prenez n’importe quelle tâche qu’un agent a terminée la semaine dernière. Vous devez pouvoir répondre à chacune de ces questions en moins d’une minute, sans interroger l’agent ni rouvrir sa conversation :

1. Qui l’a faite ? Quel client, sur quelle connexion, a réservé et terminé la tâche.
2. Qu’est-ce qui a changé ? Le résultat, plus des artefacts que vous pouvez vérifier sans faire confiance à l’agent : un hachage de commit, une URL, un fichier, un id de message.
3. Qu’est-ce qui n’a pas été fait ? Les parties laissées de côté, et ce dont l’agent n’était pas sûr.
4. Qu’est-ce qui a été décidé, et pourquoi ? Tout choix fait en cours de route, avec les options pesées, et chaque fois que vous avez renvoyé le travail.

Comment savoir quel agent l’a faite ?

Weft se connecte aux clients IA via le Model Context Protocol sur un seul point de terminaison, https://letsweft.com/api/mcp. Chaque client OAuth et chaque jeton d’accès personnel est un acteur distinct. Une tâche enregistre quel client l’a créée, et le tableau affiche le nom que ce client a déclaré à la connexion, avec une icône. Chaque événement du journal de la tâche indique s’il vient d’une personne ou de MCP, et quel client l’a envoyé.

Le journal complet (get_task_history en mode full) montre l’id brut du client pour chaque événement : un id de client OAuth, ou mcp-token suivi de l’id du jeton. Ce n’est pas un nom convivial, mais c’est exact, et cela distingue deux connexions même quand elles viennent du même produit.

La propriété pendant le travail est explicite elle aussi. Un agent appelle start_task, qui réserve la tâche avec un bail de 20 minutes et la passe dans Doing. report_progress renouvelle le bail. Un second agent qui tente la même tâche reçoit already_claimed, et un bail expiré libère la tâche pour quelqu’un d’autre. Le guide de la boucle de réservation détaille tout cela pas à pas, et plusieurs agents sur un même tableau couvre le cas multi-clients.

Une règle pratique : donnez à chaque outil sa propre connexion. Si deux clients partagent un même jeton d’accès, le tableau ne voit qu’un acteur, et la question « qui » perd sa réponse.

Qu’est-ce qui a changé, et puis-je le vérifier sans interroger l’agent ?

Quand un agent termine, il appelle complete_task. Seul l’id de la tâche est obligatoire ; tout le reste est facultatif, et l’appel n’échoue jamais faute de preuves. C’est voulu : perdre du travail terminé est pire que l’enregistrer sans vérification. Ce qu’un reçu peut contenir :

• outcome : jusqu’à 1 000 caractères sur ce qui a été fait et où se trouve le résultat.
• artifacts : jusqu’à 20 entrées, chacune avec un type (url, file, message, commit, etc.), un emplacement et, en option, une empreinte sha256.
• claims : ce que l’agent affirme avoir fait, enregistré comme affirmations et non comme faits vérifiés.
• notDone et unknowns : voir la section suivante.
• nextStep : ce que l’agent ferait ensuite si vous acceptez.

complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

La ligne outcome reste un récit. Les artefacts sont la partie vérifiable. Un hachage de commit existe dans votre dépôt ou n’existe pas. Une URL se charge ou ne se charge pas. Le sha256 d’un fichier correspond ou ne correspond pas. Si un reçu a un résultat mais aucun artefact, traitez-le comme un travail déclaré par l’agent, car c’est exactement ce qu’il est. Sur le web, les cartes Done indiquent si une tâche est « Vérifiée » ou « Selon l’agent ».

Qu’est-ce que l’agent n’a pas fait ?

C’est la question que la plupart des enregistrements oublient, et celle qui vous mord deux semaines plus tard. complete_task a deux listes pour cela, chacune de 20 entrées de 500 caractères au plus : notDone pour ce que l’agent a délibérément laissé de côté, et unknowns pour ce dont il n’est pas sûr. La description même de l’outil demande aux agents de dire tout haut ce qu’ils n’ont pas fait. C’est ce qui distingue un résultat fiable d’un résultat qu’il faut reconstituer.

Lisez ces listes en premier. « Tests non lancés sur la base de staging » change ce que vous faites ensuite. Un reçu sans aucune entrée notDone sur une grosse tâche mérite lui-même une question.

Qu’est-ce qui a été décidé, et pourquoi ?

Les décisions prises dans une conversation disparaissent quand la conversation défile. record_decision les conserve de deux façons :

• Un enregistrement de décision autonome : un titre, le résultat, le contexte, les options réellement pesées, les conséquences et la condition à laquelle y revenir. Les enregistrements sont immuables ; en changer un, c’est enregistrer une nouvelle décision qui le remplace, et l’ancien reste, marqué comme remplacé.
• Le relais d’un verdict : quand vous dites à un agent en conversation « accepté », « refais-le avec X », « abandonne » ou « pas maintenant », il enregistre ce verdict sur la tâche, avec votre note.

get_task_history le relit selon trois modes : summary (la carte, son dernier reçu et des compteurs), decisions (chaque décision concernant la tâche, y compris pourquoi elle a été renvoyée, ce qui subsiste même après une acceptation ultérieure) et full (le journal brut, plafonné à 100 événements). get_context transmet les décisions en vigueur à l’agent suivant dans un budget de jetons : l’exécution suivante part de ce qui a été décidé plutôt que de zéro. Plus de détails dans pourquoi les décisions prises dans un chat IA se perdent.

Où le relire, et sur quoi cliquer ?

Par défaut, une tâche terminée va directement dans Done. Elle s’arrête dans votre boîte de réception quand elle demande une relecture ou qu’une vérification échoue. Vous y voyez le reçu et quatre boutons : Accepter, À revoir, Plus tard et Abandonner. À revoir demande une note, et cette note repart à l’agent.

Si l’agent a fourni un nextStep, il s’affiche au-dessus du bouton Accepter, et accepter approuve exactement cette étape. L’approbation vaut 72 heures et revient à l’agent via get_my_work ou start_task comme l’unique étape à faire ensuite. Les questions qu’un agent pose avec request_input arrivent dans la même boîte de réception, sur le web et dans les applis iOS et Android, avec une notification push.

La boîte de réception a une limite, et c’est voulu : 5 éléments en attente pour un espace d’une personne, 10 pour une équipe, ou 45 minutes de relecture estimée, selon ce qui arrive en premier. Quand elle est pleine, start_task refuse avec attention_queue_full : les agents terminent ou clarifient le travail au lieu d’en empiler davantage à vérifier.

Quelles preuves demander selon le type de tâche ?

Écrivez-les dans la description de la tâche pour que l’agent sache quelle preuve vous attendez :

• Code : le hachage du commit et l’URL de la PR comme artefacts. notDone doit nommer les tests non lancés, les migrations non appliquées et les fichiers volontairement laissés de côté.
• Contenu : l’URL publiée, ou le fichier de brouillon avec son sha256 s’il n’est pas encore en ligne. unknowns doit lister les faits que l’agent n’a pas pu confirmer.
• Recherche : une URL source pour chaque affirmation clé, et le fichier de notes. unknowns doit séparer ce que dit une source de ce que l’agent en a déduit.
• Prospection : l’id de chaque message envoyé, et la liste des destinataires en fichier. notDone doit lister qui n’a pas été contacté et pourquoi.

Comment contrôler dès le départ ce qu’un agent peut faire ?

L’attribution après coup fonctionne mieux avec des limites en amont. Dans Weft, chaque connexion OAuth a l’un de trois niveaux de droits, réglé sur l’écran de consentement ou plus tard dans Paramètres → Clients IA connectés :

• full (par défaut) : les 32 outils.
• write : tout sauf les trois outils destructifs (trash_task, archive_done_tasks, complete_sprint).
• read : seulement les 11 outils en lecture seule.

Le contrôle a lieu à chaque appel. Déconnecter révoque les jetons de rafraîchissement de la connexion et refuse, dès son appel suivant, tout jeton émis avant la coupure. Les jetons d’accès personnels, pour les clients sans OAuth, n’ont pas de portée : un jeton atteint les 32 outils, et sa révocation prend effet à l’appel suivant. Les agents peuvent mettre des tâches dans une corbeille de 30 jours, mais pas les supprimer définitivement ; la restauration depuis la corbeille est une fonction Pro.

Ce que Weft ne fait pas ici

• Il n’a pas d’intégration GitHub ou Slack : Weft ne va pas chercher vos commits ou vos messages à votre place. C’est vous qui ouvrez l’artefact.
• Il n’a ni API REST publique, ni webhooks, ni CLI pour pousser les reçus vers d’autres systèmes. Il existe un export JSON et Markdown.
• Il ne trace pas les étapes du modèle. Les outils qui journalisent prompts, jetons et latence au niveau du modèle font un autre travail, et vous voudrez peut-être en avoir un aussi.
• Les agents rédigent leurs propres reçus. Weft rend visible l’écart entre affirmation et preuve ; il ne peut pas rendre un agent honnête.

Si vous voulez des agents gérés comme comptes de service via une API REST, une CLI pour vos scripts de CI, ou des fonctions d’IA intégrées comme la rédaction et le tri des tâches, Hypertask convient mieux. Notre page alternative à Hypertask compare les deux côte à côte.

L’historique git ne suffit-il pas pour savoir ce qu’a fait mon agent ?

Git montre ce qui a changé dans le code. Il ne montre pas ce que l’agent a sauté, ce dont il n’était pas sûr, ni quel choix il a fait entre deux options. Utilisez le hachage du commit comme artefact sur la tâche, et gardez le reste dans le reçu et l’enregistrement de décision.

Un agent ne peut-il pas simplement inventer un artefact ?

Il peut envoyer n’importe quelle chaîne. L’intérêt d’un artefact, c’est que vous pouvez l’ouvrir : un hachage à rechercher, une URL à charger, un id de message à retrouver. Un artefact inventé échoue dès que vous vérifiez, ce qu’un commentaire ne fait jamais. Quand une tâche porte une vérification et qu’un contrôle bloquant échoue, la tâche reste hors de Done.

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

Non. Par défaut, une tâche terminée va dans Done. Elle attend 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.

Quels clients IA peuvent écrire des reçus dans Weft ?

N’importe quel client MCP. Dans ChatGPT, Weft est un plugin publié sur tous les forfaits, y compris le gratuit. Claude Code se connecte avec claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai et Claude Desktop passent par un connecteur personnalisé. Il existe des pages de configuration pour 33 clients, comme Claude Code, ChatGPT, Cursor et Codex.

Combien cela coûte-t-il ?

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. Weft n’a pas de crédits d’IA : la réflexion se fait dans votre propre client IA. Voir les tarifs.