Chercher sur X avec un navigateur, c'est le mauvais outil
gary est mon agent marketing sur Waggle. Son travail : trouver sur X des personnes qui posent des questions sur des problèmes que Waggle résout, et leur répondre utilement, en mon nom. Jusqu'à cet après-midi-là, il cherchait sur X à la manière lente : il pilotait Chrome dans son sandbox, page après page.
Je fais aussi tourner un agent appelé grokbot, sur une autre plateforme. Il accède directement à l'API de X : pour lui, une recherche est un appel, pas une session de navigation. Le même travail, avec un bien meilleur outil. Les deux ne s'étaient jamais rencontrés, et ils vivent sur des plateformes différentes.
Alors j'ai demandé à gary d'aller le rencontrer.
J'ai demandé, et gary a ouvert un webhook
À 17 h 03, heure des Rocheuses (UTC-6), j'ai dit à gary ce que je voulais. Procure-toi une adresse e-mail que tu contrôles. Parle à mon grokbot, qui accède directement aux API de X. Arrête les recherches par Chrome, mais continue de publier par Chrome. Écris-lui, présente-toi, et mettez au point par e-mail la façon dont il peut te réveiller avec des résultats de recherche.
À 17 h 04, gary a ouvert un webhook sur lui-même et l'a titré d'après ce qu'il fait : il se réveille quand grokbot envoie des résultats de recherche X. Dans Waggle, un agent peut ouvrir un webhook qui le réveille lui-même sans rien demander à personne. Un webhook qui route ailleurs, vers une personne, vers un autre agent ou vers un endpoint, attend sur une carte qu'une personne l'approuve. Celui-ci ne réveillait que gary : il a été actif aussitôt.
À 17 h 04 min 55 s, il m'avait répondu avec son adresse e-mail et avait envoyé une présentation à grokbot. Elle contenait ce dont grokbot avait besoin pour démarrer : l'adresse du webhook, la manière de signer un envoi, les champs que gary voulait pour chaque résultat (l'identifiant du post, le pseudo, la bio, le texte complet, l'heure et les compteurs), et un lot par créneau de recherche, en anglais à 14, 17, 20 et 23 h UTC, en japonais à 01 et 04 h UTC.
Le secret n'est jamais passé par l'agent
Il manquait quelque chose dans cet e-mail, volontairement. Un webhook a un secret de signature, et gary ne peut pas le voir. Il se trouve dans le panneau de l'espace de travail, où seule une personne peut le lire. gary m'a dit de le remettre à grokbot directement, et il a dit à grokbot qu'il n'arriverait jamais par e-mail.
C'est la règle du contrat, pas une politesse. Un agent peut ouvrir un webhook, mais seule la personne à qui l'agent appartient ou un administrateur de l'espace de travail peut en lire le secret.
Le premier envoi a été refusé
À 17 h 07, grokbot a envoyé son premier post. Waggle l'a refusé à cause de la signature. Il n'est jamais arrivé jusqu'à gary et ne l'a jamais réveillé. À 17 h 08, j'ai dit à gary que grokbot lui avait envoyé un message par le webhook.
gary a consulté le dernier refus du webhook et l'a expliqué en 13 secondes. La signature ne correspondait pas. Les causes probables : un mauvais secret, une signature calculée sur autre chose que le corps brut exact, ou un horodatage vieux de plus de cinq minutes. Il connaissait le format parce que c'est le contrat : l'expéditeur calcule un HMAC-SHA256 sur l'horodatage, un point et le corps brut, et l'envoie sous la forme X-Waggle-Signature: t=<unix seconds>,v1=<hex>. Un envoi de plus de cinq minutes est refusé, de même qu'une signature déjà utilisée.
À 17 h 08, j'ai dit : va négocier ça par e-mail. gary a envoyé à grokbot le format exact, un court exemple en Python et les erreurs habituelles : resérialiser le JSON avant de signer, envoyer des millisecondes au lieu de secondes, laisser des espaces à la fin du secret, réutiliser une signature. Il a demandé d'abord un tout petit envoi de test. À 17 h 13, le test, {"test": true}, a passé la vérification de signature et réveillé gary. Il a répondu par e-mail que la liaison était établie.
La façon dont un expéditeur signe un envoi, d'après le contrat du webhook. L'adresse et le secret sont des valeurs d'exemple ; les vraies viennent du webhook dans le builder, et le secret n'est jamais envoyé par e-mail.
Le premier lot, et trois réponses
À 17 h 14, j'ai dit à gary de tester avec sa recherche de 17 h. Il a demandé à grokbot, par e-mail, le lot anglais de 23 h UTC : dix à quinze posts, d'abord ceux sur la difficulté de la distribution, puis les agents pour la mise en marché, puis la mise en veille de l'ordinateur portable.
À 17 h 16, le lot est arrivé sur le webhook sous la forme d'un événement de type x_search_batch : dix posts des dernières 24 heures, avec une note de grokbot sur ce qu'il avait filtré. Marques, actualités, comptes crypto et comptes de copier-coller avaient été écartés. L'API de X rejette le filtre qui exclut les posts contenant des liens ; il les a donc retirés après la recherche. Une requête avait été élargie pour remplir le lot.
À 17 h 18, gary avait lu les dix. Il en a écarté sept : un avait déjà une réponse donnant le même conseil, un autre faisait la promotion de son propre outil, et les autres correspondaient moins bien. Il a publié trois réponses par Chrome, chacune confirmée par X, à des fondateurs bloqués sur la recherche de leurs premiers utilisateurs. Puis il a consigné sa progression sur son objectif, et noté que la requête sur les agents pour le marketing n'avait trouvé qu'un seul post, et qu'il demanderait à grokbot de l'élargir.
La recherche passe par une API. Le navigateur ne fait que publier.
Ce partage est le point central. La recherche est un gros volume et demande une API faite pour elle. Publier est une action unique et soignée qui a encore besoin d'un navigateur ; Chrome est donc gardé pour cela et rien d'autre. gary ne passe plus son sandbox à faire défiler des pages de résultats.
C'est aussi la façon dont Waggle doit s'entendre avec le reste. grokbot n'est pas sur Waggle et n'a pas besoin de l'être. Il est devenu une source de travail pour gary grâce à un simple webhook signé, que n'importe quel agent ou script sur n'importe quelle plateforme peut envoyer. Waggle relie les agents que vous faites déjà tourner. Il ne vous demande pas de les remplacer.
Une personne, deux agents de deux plateformes, quelques e-mails entre eux. J'ai donné l'objectif. Ils ont réglé le reste.
Ce qui a gardé le tout sûr
Un envoi est vérifié avant que quoi que ce soit ne réveille l'agent. S'il n'est pas signé, mal signé, vieux de plus de cinq minutes ou signé avec une signature déjà utilisée, il est refusé et ne réveille pas gary. C'est ce qui s'est passé à 17 h 07, et cela n'a coûté que quelques minutes.
Le refus n'est pas caché. L'expéditeur reçoit son accusé de réception avant que la preuve ne soit vérifiée ; un refus ne peut donc pas lui parvenir, et la raison reste sur le webhook : quand le dernier refus a eu lieu et pourquoi. gary l'a lue et me l'a expliquée en 13 secondes, et l'envoi signé suivant est passé à 17 h 13.
Chaque étape est dans la trace
Chaque heure de cet article vient de la trace de gary : ce qui l'a réveillé, ce qui est arrivé, ce qu'il a décidé et ce qu'il en a fait. La présentation, le refus, l'envoi de test, le lot et les trois réponses y sont, dans l'ordre.
C'est la même trace qui permet à une personne de demander ensuite ce qu'un agent a fait. Deux agents sur deux plateformes se perdent facilement de vue. La partie qui tourne sur Waggle, elle, est consignée.
Où cela nous mène
Un agent d'une autre plateforme peut devenir une source de travail pour un agent Waggle avec quelques e-mails et un webhook signé. Le secret reste aux personnes, chaque envoi est vérifié à la porte, et la trace montre ce qui s'est passé.