Pourquoi Kanban Hermes garde une trace là où une délégation ponctuelle disparaît
Tu délègues une tâche à un agent. Il bosse, il termine, il rend un résultat. Et puis plus rien. Le lendemain, tu te demandes ce qu’il a fait exactement, dans quel ordre, avec quel raisonnement. Tu n’as pas de réponse. La délégation ponctuelle, c’est un appel de fonction : appel, retour, fin de l’histoire.
Kanban Hermes fonctionne autrement. Chaque tâche, chaque passage de relais entre profils, chaque décision de blocage ou de reprise laisse une ligne durable. Pas un log temporaire. Une trace que tu peux relire dans six mois, et qu’un autre agent peut reprendre sans que tu aies à tout lui réexpliquer.
Ce n’est pas une source de vérité métier. Ce n’est pas un CRM, pas un outil de gestion de projet. C’est une mémoire de coordination entre agents. Et c’est ce qui change tout quand tu passes d’une tâche unique à une équipe d’agents qui se passent le relais.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Arbitrages utiles
Questions réelles
Accès gratuit
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Le problème : une tâche déléguée qui s’évapore
Quand tu utilises delegate_task, voici ce qui se passe. Tu confies une sous-tâche à un agent anonyme. Le parent attend. L’enfant travaille, retourne un résultat, et le parent reprend la main. Fin du cycle.
Ce qui n’existe pas dans ce modèle :
- Aucun enregistrement de ce que l’agent a fait étape par étape.
- Aucune possibilité de reprendre la tâche si elle est interrompue.
- Aucun moyen pour un humain de lire ce qui s’est passé.
- Aucune trace pour un autre agent qui arriverait après.
C’est un appel de fonction. Rapide, efficace, et complètement opaque une fois terminé. Pour un calcul simple ou une transformation de données, c’est parfait. Pour un travail où plusieurs profils doivent se coordonner, où un humain doit pouvoir vérifier, ou qu’on doit pouvoir reprendre plus tard, ça ne suffit pas.
Ce que Kanban garde, concrètement
Kanban Hermes est une file de messages durable avec une machine d’état. Chaque tâche créée devient une ligne dans une base SQLite. Cette ligne persiste. Elle ne disparaît pas quand la tâche est terminée.
Voici ce qui est enregistré pour chaque tâche :
- Qui l’a créée, quand, avec quel titre et quel corps.
- Quel profil l’a exécutée.
- Les commentaires échangés pendant l’exécution.
- Les handoffs : quand un profil passe le relais à un autre, le résumé et les métadonnées sont écrits dans la ligne.
- Les blocages et déblocages, avec la raison donnée.
- Le résultat final, avec les artefacts produits.
Tout ça dans une base SQLite. Pas de service externe, pas de cloud, pas de dépendance. Une trace locale, lisible, requêtable.
| Critère | delegate_task | Kanban Hermes |
|---|---|---|
| Nature | Appel de fonction RPC (fork → join) | File de messages durable + machine d’état |
| Agent | Sous-agent anonyme | Profil nommé avec mémoire persistante |
| Reprise | Impossible après retour | Block → unblock → re-run, humain dans la boucle |
| Trace | Aucune piste d’audit | Lignes durables dans SQLite, pour toujours |
| Multi-agent | 1 parent, 1 enfant | N agents sur la vie d’une tâche |
| Visibilité | Résultat seul, pas le chemin | Chaque handoff lisible par tout profil ou humain |
La différence tient en une phrase : delegate_task est un appel de fonction. Kanban est une file de travail où chaque handoff est une ligne que tout profil, ou tout humain, peut voir et éditer.
Reprendre un handoff sans repartir de zéro
Imagine ce scénario. Un premier agent analyse un jeu de données et passe le relais à un deuxième agent pour produire un rapport. Le deuxième agent a besoin de savoir ce que le premier a trouvé, quels fichiers il a produits, quelles décisions il a prises.
Avec delegate_task, le deuxième agent reçoit juste le résultat brut du premier. Pas de contexte, pas de raisonnement, pas d’historique. Il doit deviner ou tout refaire.
Avec Kanban, le deuxième agent lit la ligne de la tâche. Il voit le résumé du premier, les métadonnées structurées, les fichiers modifiés, les tests exécutés. Il reprend exactement là où le premier s’est arrêté, avec le contexte complet.
Et si le premier agent s’est bloqué sur une ambiguïté, le deuxième voit la raison du blocage. Il ne perd pas de temps à re-découvrir le problème.
C’est le passage d’une chaîne de transmission orale à un dossier écrit. La différence, c’est que le dossier s’écrit tout seul, sans effort supplémentaire.
Relire les décisions passées
La trace Kanban n’est pas seulement utile pour les agents qui se passent le relais. Elle est utile pour toi, l’humain, quand tu veux comprendre ce qui s’est passé.
Tu peux ouvrir la base SQLite et lire :
- Quelles tâches ont été créées, par qui, quand.
- Quels profils ont travaillé sur chaque tâche.
- Quelles décisions ont été prises en cours de route.
- Quels blocages sont survenus et comment ils ont été résolus.
- Quels artefacts ont été produits.
Ce n’est pas un tableau de bord de gestion de projet. C’est une trace brute, technique, de la coordination entre tes agents. Mais cette trace répond à une question que la délégation ponctuelle ne peut pas traiter : « qu’est-ce qui s’est passé pendant que je n’étais pas là ? »
Pour un solopreneur qui fait tourner plusieurs agents en parallèle, cette visibilité change la confiance qu’il peut accorder à son système. Il ne délègue pas dans le noir. Il peut vérifier, relire, corriger.
Ce que Kanban n’est pas
Cette distinction est importante. Si tu cherches un outil pour documenter tes processus métier, Kanban n’est pas la réponse. Si tu cherches un moyen de savoir quel agent a fait quoi, quand, et pourquoi, et de pouvoir reprendre un handoff six mois plus tard, Kanban est exactement ce qu’il te faut.
La trace Kanban est une mémoire de coordination. Elle ne dit pas « voici la stratégie de l’entreprise ». Elle dit « voici ce que l’agent A a passé à l’agent B le 15 juillet, avec les fichiers modifiés et les tests exécutés ». C’est une piste d’audit technique, pas un document de gouvernance.
Quand basculer de delegate_task vers Kanban
Le choix n’est pas dogmatique. Les deux outils ont leur place. Voici un critère simple pour décider.
Utilise delegate_task quand :
- La tâche est un calcul rapide ou une transformation simple.
- Tu n’as pas besoin de relire le chemin, seulement le résultat.
- Un seul agent suffit, et il n’y a pas de handoff.
- La tâche ne sera jamais reprise plus tard.
Utilise Kanban quand :
- Plusieurs profils doivent se passer le relais.
- Tu veux pouvoir relire ce qui s’est passé, même des semaines après.
- Un humain doit pouvoir intervenir, bloquer, débloquer.
- La tâche peut être interrompue et reprise.
- Tu construis une équipe d’agents qui travaillent ensemble sur la durée.
La question n’est pas « lequel est le meilleur ». La question est « est-ce que j’aurai besoin de cette trace plus tard ? » Si la réponse est oui, passe par Kanban.
Si tu veux aller plus loin, tu peux lire comment une équipe d’agents IA devient une source unique de vérité pour ton travail quotidien, ou comment piloter une équipe d’agents avec Kanban pour structurer tes workflows.
Le plus simple, si tes handoffs doivent être relus, c’est de créer un board. La trace s’écrit toute seule à partir de là. Tu peux faire une demande d’accès à Kavyro pour tester Kanban avec tes propres agents.
