Quatre choses qu’un harnais d’agent doit assurer

Quand un agent échoue sur une vraie tâche, la cause se trouve souvent hors du modèle. La machine était éteinte. Un outil a changé pendant la nuit. Un fichier est parti chez quelqu’un qui n’aurait jamais dû le voir.

Nous appelons harnais (harness, en anglais) tout ce qui entoure le modèle : l’ordinateur sur lequel l’agent tourne, les outils qui y sont installés, les fichiers et les comptes qu’il peut atteindre, ce qu’il a le droit de faire et l’endroit où partent ses résultats. Si vous voulez confier une partie de votre activité à des agents, le harnais compte autant que le modèle que vous choisissez.

Les quatre conditions en bref

1. Allumé quand il le faut, éteint le reste du temps. Vous payez les heures où l’agent travaille.
2. Le même environnement à chaque fois. L’exécution du lundi et celle du mardi partent du même point.
3. Des livrables partagés selon les droits. Les fichiers et les petites apps arrivent chez les bonnes personnes, et chez elles seules.
4. Des produits isolés. Tout ce qui sert des clients dispose de son propre environnement.

La suite de l’article les reprend une par une, puis les transforme en liste de vérification.

1. Allumé quand il le faut, éteint le reste du temps

Le travail d’un agent arrive par vagues. Un résumé des ventes à 9 h, un brouillon de rapport après le déjeuner, une série de tests le soir. Entre les deux, l’agent attend.

Si sa machine tourne toute la journée, vous payez 24 heures pour environ trois heures de travail. L’exemple ci-dessous montre une journée de ce genre.

Démarrer et arrêter, c’est la partie facile. La partie difficile, c’est ce qui survit à l’arrêt. Si la machine oublie ses fichiers à chaque fois, l’agent refait toute sa préparation à chaque tâche : il clone de nouveau le dépôt, réinstalle les paquets, se reconnecte. C’est là que le temps perdu et les erreurs s’accumulent.

Vérifiez donc trois choses :

• La machine démarre-t-elle d’elle-même quand une tâche arrive ?
• S’arrête-t-elle d’elle-même après un moment sans activité ?
• Quand elle redémarre, les fichiers sont-ils toujours là ?

2. Le même environnement à chaque fois

Un agent qui fonctionne le lundi et échoue le mardi, sans que vous ayez rien changé, est en général tombé sur une autre machine. Un paquet a été mis à jour. Un outil a été déplacé. Une permission a changé. Une personne le remarque et s’adapte. Un agent, la plupart du temps, ne sait pas ce qui a changé. Alors il devine.

La solution consiste à écrire l’environnement noir sur blanc : l’image système, les versions des outils, la taille de la machine, les fichiers conservés, ce que l’agent peut toucher, les comptes connectés. Chaque exécution part de cette description. Quand vous la modifiez, vous le faites exprès et vous lui donnez un nouveau numéro de version.

Les comptes et les clés font aussi partie du harnais, stockés hors du prompt. Une clé collée dans un prompt voyage avec chaque appel au modèle et finit dans les journaux.

3. Des livrables partagés selon les droits

Les agents fabriquent des choses pour des personnes : un rapport PDF, un tableur, une page d’inscription. Ces livrables doivent quitter la machine de l’agent pour arriver chez quelqu’un. Pas chez n’importe qui pour autant. Un rapport hebdomadaire va à l’équipe. Un brouillon reste chez vous tant que vous ne l’avez pas relu.

Un harnais qui gère bien les livrables fait trois choses :

• Chaque livrable commence en privé.
• Le partage est une étape volontaire, avec un niveau : des personnes que vous choisissez, toute personne ayant le lien, ou tout le monde.
• Chaque livrable garde la trace de l’agent qui l’a produit. Quand quelque chose cloche, vous savez à qui poser la question.

4. Des produits isolés

Certains travaux survivent à la conversation qui les a lancés. Un bot de prise de rendez-vous pour un cabinet médical. Un suivi des prix qui envoie des alertes à des boutiques chaque matin. Des clients en dépendent tous les jours : ce sont des produits.

Un produit doit tourner dans un environnement à lui : sa propre machine, ses propres données, ses propres clés et ses propres règles réseau, le tout fixé par son propre harnais. Ainsi, un bug ou une clé divulguée dans un produit reste dans ce produit, et vous pouvez en mettre un à jour sans toucher aux autres.

Alors, par où commencer ?

Prenez un agent que vous faites déjà tourner et passez ce tableau en revue.

Question	Si la réponse est non
Sa machine s’arrête-t-elle quand il n’y a rien à faire ?	Vous payez des heures d’inactivité.
Démarre-t-il avec les mêmes fichiers et les mêmes outils que la dernière fois ?	Attendez-vous à des échecs du type « ça marchait hier ».
L’environnement est-il écrit, avec une version ?	Quand une exécution casse, impossible de savoir ce qui a changé.
Les clés sont-elles stockées hors du prompt ?	Elles finissent dans les journaux et les appels au modèle.
Les livrables restent-ils privés jusqu’à ce que quelqu’un les partage ?	Des brouillons arrivent chez des gens avant votre relecture.
Chaque produit tourne-t-il dans son propre environnement ?	Le bug d’un produit peut atteindre les données d’un autre.

Commencez par les deux premières lignes. Elles coûtent peu à corriger, et elles font disparaître toute une famille d’échecs qui semblent aléatoires.

Où se situe endue

endue OS est notre réponse à ces quatre conditions. Il est en préversion. Voici ce que vous pouvez utiliser dans endue dès aujourd’hui :

• Chaque agent a son propre Workspace, une machine Linux ou Chrome. Il démarre quand l’agent en a besoin et s’arrête par défaut après 15 minutes sans utilisation. Dans la console endue OS, vous pouvez régler ce délai de 1 minute à 24 heures. Les fichiers restent en place : la tâche suivante reprend là où la précédente s’est arrêtée. Vous payez en crédits endue le temps de fonctionnement et le disque qui conserve ses fichiers.
• Les Workspaces démarrent à chaque fois depuis la même image, à la taille que vous choisissez, par exemple 1 CPU avec 1 Go de mémoire ou 2 CPU avec 4 Go.
• Les livrables (Outputs) sont privés par défaut. Vous en partagez un avec un lien en lecture seule.

Ce que nous préparons ensuite dans endue OS va plus loin. Il choisira le fournisseur cloud et la machine adaptés aux besoins de chaque agent, la moins chère ou la plus rapide. Il fera tourner les produits dans des environnements entièrement isolés, sous leur propre harnais. Et toutes vos données resteront à vous, prêtes à partir ailleurs quand vous le voudrez. Ces trois fonctions ne sont pas encore disponibles. Nous publierons un article sur chacune à sa sortie.

Le guide Workspace se trouve dans la documentation (en anglais), et le partage est expliqué dans Outputs. Pour un premier pas, prenez un agent, un Workspace et une tâche que vous répétez chaque semaine. Ouvrez ensuite Devices et regardez sa machine s’arrêter puis se réveiller.