Sur cette page
Considérez une tâche illustrative dans un navigateur, composée de cent étapes. Supposons que chacune réussisse dans 99 % des cas, indépendamment des autres. La probabilité que toutes réussissent est 0.99^100, soit environ 36,6 %.
Quatre-vingt-dix-neuf pour cent semblent excellents. Trente-six pour cent, beaucoup moins.
La discussion source sur les tâches transactionnelles dans le navigateur emploie ce calcul pour souligner un point précis : la personne obtient de la valeur lorsque la tâche se termine, tandis que le coût et le risque d’échec s’accumulent à chaque étape. C’est un calcul fondé sur une hypothèse, pas un taux de réussite publié pour un agent de navigateur ou une synchronisation Tajo. Les erreurs réelles peuvent dépendre les unes des autres. Une connexion expirée peut faire échouer plusieurs actions suivantes.
La question utile n’est donc pas « Quelle était la précision du dernier clic du modèle ? », mais « L’état demandé est-il apparu ? »
La transaction est la bonne unité de mesure
Imaginez un agent qui ouvre un portail d’assurance, trouve un document, le télécharge et vérifie qu’il appartient au bon compte. Il peut parcourir correctement 99 écrans, puis télécharger le mauvais fichier au centième. Un journal rempli de clics réussis ne répare pas le résultat.
La même distinction vaut pour une intégration. Un agent peut découvrir une API, proposer une correspondance de champs et enregistrer un brouillon. Rien de tout cela ne signifie qu’un contact de destination possède désormais le statut de consentement voulu. Le travail n’est terminé que lorsque l’opération approuvée a été exécutée et que sa condition finale pertinente a été vérifiée.
Il faut distinguer activité et achèvement. L’activité se compte facilement. L’achèvement exige une définition.
Pour un téléchargement, ce pourrait être un fichier dont le numéro de compte correspond à la demande. Pour une synchronisation de contacts, ce pourrait être un enregistrement de destination avec le bon identifiant, les bons champs et le bon statut d’autorisation pour les messages. Le contrôle doit examiner ce qui comptait pour la personne. Une réponse positive de l’appel précédent prouve que l’appel a répondu. Elle ne prouve pas nécessairement que la destination a changé comme prévu.
Le guide Tajo pour relier les outils d’entreprise commence par le workflow et la source de vérité de chaque objet de données. Ces choix donnent son sens au contrôle final. Si deux systèmes prétendent tous deux être propriétaires d’un champ, même une écriture parfaitement exécutée peut créer un état durablement incorrect.
Le coût d’une décision supplémentaire
Avec la même hypothèse de réussite à 99 %, dix décisions indépendantes donnent environ 90,4 % de réussite pour la chaîne entière. Cinquante donnent environ 60,5 %. Cent donnent environ 36,6 %.
Probabilité de réussite de la chaîne entière (%)
Nombre d’étapes indépendantes
- Réussite supposée de 99 % par étape
Lire les valeurs calculées
| Étapes | Réussite de la chaîne entière (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
La courbe descend vite parce que la multiplication ne tient pas compte d’une bonne moyenne. Chaque décision supplémentaire doit justifier sa place.
Cela ne veut pas dire qu’il faut fusionner tous les appels d’API en une seule opération géante. Certains appels sont déterministes : récupérer une page avec un curseur connu, comparer un identifiant ou écrire un champ selon une correspondance approuvée. Le modèle n’a pas besoin de reprendre ces décisions pour chaque enregistrement. D’autres appels comportent une vraie ambiguïté : un nouveau champ fournisseur, un message d’erreur modifié ou une demande dont la responsabilité est floue. Ceux-là peuvent nécessiter un jugement.
La répartition pratique consiste à laisser le jugement concevoir ou réparer une règle, puis à laisser du code ordinaire appliquer cette règle stable. Le reverse ETL illustre les déplacements répétés de données : le pipeline, et non une conversation, doit traiter chaque ligne courante. Un agent peut toujours aider à décider ce que le pipeline devrait faire.
C’est une frontière, pas un slogan. Si un fournisseur change le sens d’un champ, une règle déterministe peut répéter parfaitement la mauvaise action. Le système doit détecter que ses hypothèses ont changé et renvoyer ce cas à l’examen.
Pourquoi un seul grand outil ne suffit pas
Une objection raisonnable serait : « Si les longues chaînes échouent, plaçons toute la tâche derrière un seul appel d’outil. » Cela aide lorsque l’outil réalise une transaction bien définie, avec un résultat vérifiable. Cela échoue s’il masque simplement un long processus incertain.
Supposons que syncCustomer() renvoie success: true après avoir envoyé une mise à jour. Si la destination traite les mises à jour plus tard, l’appel ne peut pas encore prouver l’état final du contact. L’outil a réduit le nombre d’étapes visibles. Il n’a pas réduit l’incertitude.
Une meilleure interface expose les états utiles : accepté, appliqué, vérifié ou échoué. Ces mots doivent correspondre à des preuves. Une écriture acceptée peut suffire pour un aperçu à faible enjeu. Une audience de campagne ou un changement de consentement mérite un contrôle dans la destination avant d’être déclaré terminé.
Dans cette vue Tajo proposée, une demande acceptée et une mise à jour appliquée restent distinctes d’un état cible vérifié. La dernière vérification est en attente. Cette distinction donne un but à l’étape suivante : examiner ce que la cible a enregistré. Compter un appel d’outil réussi de plus laisserait la question initiale sans réponse.
Une écriture terminée demande encore des preuves
La synchronisation du client est-elle terminée ?
Écriture appliquée. Vérification en attente.
L'état de la cible n'a pas encore été vérifié.
Activité de synchronisation
- Demande acceptée
- Mise à jour appliquée
- Vérification de la cible en attente
Exécution d'exemple · 14:32 UTC
Ce que nous savons
- Réponse du fournisseur
- Acceptée
- Résultat de l'écriture
- Appliquée
- Relecture de la cible
- En attente
Un appel réussi ne prouve pas l'état final.
Présentation proposée d'après le journal d'activité de Tajo. Cette illustration ajoute un état de vérification sans prétendre que la relecture de la cible est déjà disponible.
Cela change aussi les mesures. Notez le nombre de tentatives s’il aide à comprendre le coût. Notez les erreurs intermédiaires si elles révèlent une étape cassée. Mais évaluez le workflow par les transactions terminées et vérifiées, en indiquant la méthode de vérification à côté du chiffre. Une équipe qui annonce « 99 % des appels ont réussi » n’a pas répondu à la question de savoir si les personnes ont obtenu le résultat demandé.
L’explication des serveurs MCP montre comment les outils permettent à un assistant d’appeler un autre système. L’accès aux outils n’est que le début. Le contrat porte sur l’état laissé derrière soi.
Cent bons clics peuvent encore ne rien produire. Comptez le résultat.
Questions fréquemment posées
Pourquoi un long workflow échoue-t-il alors que ses étapes réussissent généralement ?
Si chaque étape réussit indépendamment avec une probabilité p, la chaîne de n étapes réussit avec une probabilité p puissance n. Avec une réussite supposée de 99 % par étape, cent étapes aboutissent dans environ 36,6 % des cas. Les échecs réels peuvent être corrélés : ce calcul illustre un mécanisme, il ne mesure pas la fiabilité d’un agent.
Réduire le nombre d’appels d’outils garantit-il la fiabilité ?
Non. Moins d’appels n’aident que si l’opération regroupée conserve les bons contrôles et points de reprise. Un appel opaque peut masquer une écriture ratée aussi facilement qu’une longue chaîne peut perdre le fil.
Que doit mesurer une équipe pour un workflow d’agent ?
Mesurez l’achèvement vérifié de la transaction demandée, pas seulement les appels au modèle réussis. Définissez l’artefact ou l’état de destination qui prouve la fin du travail, puis relevez la fréquence de cet état après tout le workflow.