Confier du travail à un agent depuis Slack et Teams

Un fil dans #payments, en milieu de matinée. Quelqu'un demande à @Archyl ce qui appelle le webhook sender, et le bot répond : les containers Checkout et Billing, tous deux via la Payments API. Deux messages plus loin arrive la phrase sur laquelle se terminent tous ces fils : « il faudrait ajouter des retries là-dessus, quelqu'un peut s'en charger ? »

Puis le fil se tait. Quelqu'un doit ouvrir Archyl, trouver le projet, choisir un profil d'agent et retaper une tâche qui existe déjà, mot pour mot, trois messages plus haut.

Depuis juin, le bot Archyl répond aux questions dans Slack et Microsoft Teams. À partir d'aujourd'hui, il peut aussi agir. Le même fil peut confier le travail à un agent géré :

@Archyl run [Payments API] add retries with backoff to the webhook sender

L'agent s'exécute au nom de la personne qui a tapé cette commande, et le bot suit l'exécution dans le fil jusqu'à ce qu'il y ait une pull request.

Un fil, du début à la fin

Voici la suite de cet échange. Les messages d'Archyl sont les formats que le bot publie réellement. Les noms, la question et la pull request sont des exemples.

Marie:   @Archyl run [Payments API] add retries with backoff to the webhook sender

Archyl:  🚀 Agent `backend-fixer` started on Payments API. Follow it in Archyl
         — I'll post here when it needs you or when it's done.

« Follow it in Archyl » renvoie vers la page de l'exécution, où le plan se remplit sous forme de checklist et où chaque appel d'outil apparaît dans le fil d'activité. Personne n'a besoin de la garder ouverte.

Vingt minutes plus tard, l'agent tombe sur une décision qu'il ne devrait pas prendre seul :

Archyl:  @Marie ❓ The agent has a question:
         > Should retries also cover 4xx responses from receivers, or only
         > 5xx and timeouts?
         Answer in Archyl.

Marie clique sur le lien, choisit « only 5xx and timeouts » parmi les réponses suggérées, et retourne à ce qu'elle faisait. Quand l'exécution se termine :

Archyl:  @Marie ✅ The agent finished and opened a pull request:
         https://github.com/acme/payments-api/pull/412
         See the run.

Si le profil a Relire le plan d'abord activé, il y a une étape de plus avant toute modification du code : « 📋 The agent proposed a plan and is waiting for your review », avec un lien. Si l'exécution échoue ou atteint sa limite de temps ou de coût, le dernier message dit pourquoi, et renvoie vers la pull request en brouillon qui contient le travail fait jusque-là.

Dans Slack, chacune de ces mises à jour @mentionne la personne qui a lancé l'exécution, pour qu'elle arrive dans ses notifications. Dans Teams, les mises à jour arrivent comme des réponses dans le même fil, sans mention.

Ce qui s'est passé entre ces messages

Le fil montre trois messages. L'exécution en a fait bien davantage, et c'est cette partie qui fait l'intérêt de cette release.

Avant de toucher un fichier, l'exécution a ouvert une session de travail sur les éléments d'architecture concernés par la tâche, ici le component webhook sender dans la Payments API. Elle a pris des réservations dessus, si bien qu'un développeur qui lance plus tard Claude Code sur le même component est prévenu que quelqu'un y travaille déjà. Son briefing contenait les ADR, les règles de conformité et les contrats d'API rattachés à ces éléments, ainsi que tout ce que des sessions précédentes en avaient retenu. Chaque fichier qu'elle a écrit est passé par le Guard, qui refuse une écriture qui enfreint une règle de conformité critique. À la fin, son résumé est devenu de la mémoire sur les éléments auxquels les fichiers modifiés appartiennent réellement, et chaque décision qu'elle a enregistrée a ouvert un Architecture Change Request en brouillon, que quelqu'un doit relire.

Rien de tout cela n'est propre au chat. C'est ce que fait chaque exécution Archyl. Ce qui change, c'est l'endroit d'où vient la demande.

C'est le pari derrière cette fonctionnalité. Un endroit hébergé où faire tourner un agent devient quelque chose qu'on choisit dans une liste : comme nous l'avons noté il y a deux semaines, Anthropic, OpenAI et Cursor en proposent chacun un aujourd'hui. Ce qu'un runtime ne connaît pas, c'est votre système : à quel container appartient le webhook sender, qui en est responsable, quelle règle impose que le HTTP sortant passe par le client partagé, et quel autre agent y travaille en ce moment. Cette connaissance vit dans le modèle d'architecture. Le chat, c'est là que le travail est demandé. Cette release relie les deux, pour qu'une demande faite dans un fil arrive avec le contexte dont un agent a besoin pour bien la traiter.

Pourquoi l'exécution est créée en votre nom

Quand le bot répond à une question, il utilise les permissions de l'administrateur qui a connecté l'espace de travail. Pour la lecture, ça fonctionne. Tout le monde dans le canal a la même vue de l'architecture, restreinte par canal si vous l'avez limitée.

Agir, c'est autre chose. Une exécution écrit du code et ouvre une pull request. Si @Archyl run empruntait les permissions de la personne qui a installé le bot, n'importe qui dans un canal Slack pourrait faire modifier par un agent un projet qu'il ne peut pas modifier lui-même, et l'historique des exécutions désignerait l'administrateur pour chacune d'elles.

Les exécutions sont donc créées au nom de la personne qui a tapé la commande, dans la limite de ses droits de modification sur le projet. Le bot ne peut pas savoir qui est un utilisateur de chat dans Archyl tant que celui-ci ne le lui a pas dit, ce qui implique une étape par personne, une seule fois :

Dans Archyl, allez dans Profil → Comptes de chat et cliquez sur Lier mon compte Slack ou Lier mon compte Microsoft Teams.
Envoyez la commande affichée, @Archyl connect <code>, n'importe où le bot est présent sur cette plateforme.

Le code est à usage unique et valable 15 minutes, et c'est vous qui l'avez généré en étant connecté, ce qui prouve que le compte de chat vous appartient. Slack et Teams se lient séparément. @Archyl disconnect supprime la liaison ; le bot continue de répondre à vos questions, et arrête de lancer des agents pour vous.

Si vous sautez cette étape et tapez run quand même, le bot vous dit ce qui manque au lieu de deviner :

I don't know who you are on Archyl yet, and agents run as the person who asks.
Generate a code in Profile → Chat accounts, then send @Archyl connect <code>.

Comment la commande est lue

@Archyl run [Project name] <task>, avec deux éléments facultatifs.

Le projet va entre crochets. Pour l'instant, les crochets sont obligatoires, pour que le bot n'ait jamais à deviner où finit le nom de votre projet et où commence la tâche. Dans un canal restreint à un seul projet, vous pouvez omettre le projet : @Archyl run fix the flaky login test. Un canal restreint à plusieurs projets n'accepte que les projets de sa portée. Demandez-en un autre, et le bot répond qu'il ne trouve pas ce projet dans la portée de ce canal.

Le profil va avant la tâche. Sans profil, l'exécution utilise le profil par défaut de votre organisation. Pour en choisir un autre, placez profile:<name> en premier :

@Archyl run [Web] profile:frontend-fixer align the pricing cards

Un nom de profil qui n'existe pas obtient une réponse listant ceux qui existent.

Tout le reste se comporte comme dans l'application. Il vous faut un accès en modification au projet. L'exécution est décomptée des exécutions d'agents mensuelles de votre organisation, comme une exécution lancée depuis Hub Agent → Exécutions (et, comme dans l'application, les organisations qui utilisent leur propre fournisseur d'IA ne sont pas décomptées). Si le profil a Respecter le travail des autres agents activé et qu'un autre agent détient une réservation sur les mêmes éléments, le bot répond que le gate de preflight a refusé l'exécution. Si le gate se contente d'avertir, l'exécution est mise en attente d'approbation et le bot vous donne le lien.

Deux petites choses auxquelles nous avons fait attention

Un texte non fiable ne peut pas notifier tout le canal. La tâche, le nom du projet et les questions de l'agent finissent tous cités dans le canal. Chacun est échappé pour sa plateforme avant d'être publié, si bien qu'une tâche ou une question contenant <!channel> dans Slack, ou une mention <at> dans Teams, arrive en texte brut au lieu de notifier tout le monde.

Le fil dans lequel une exécution publie ne peut pas être modifié par un client. Le canal et le fil dans lesquels une exécution publie sont enregistrés côté serveur à la création de l'exécution, et non dans ses métadonnées, que les clients de l'API peuvent écrire. Les mises à jour ne vont en outre qu'à un espace de travail connecté à l'organisation propriétaire de l'exécution.

Ce que ça ne fait pas encore

La relecture du plan et les réponses se font dans Archyl, pas dans le fil. Le bot vous dit que l'agent attend et renvoie vers la page de l'exécution. Vous ne pouvez pas approuver un plan ni répondre à une question depuis Slack ou Teams. C'est plus important qu'il n'y paraît : une question à laquelle personne ne répond dans l'heure laisse l'agent continuer selon son propre jugement, et un plan que personne ne relit dans l'heure fait échouer l'exécution. La @mention est là pour que cette heure ne passe pas inaperçue.

Un nom de projet doit correspondre à exactement un projet. Il n'y a pas de correspondance approximative, et si deux projets portent le même nom, le bot vous demande d'en renommer un ou de lancer depuis l'application.

Les mises à jour Teams ne vous mentionnent pas. Ce sont des réponses dans le fil, donc leur visibilité dépend de la façon dont vous suivez ce fil.

Une pull request nécessite un hébergeur pris en charge. Les exécutions ouvrent des pull requests sur github.com, gitlab.com et bitbucket.org. Bitbucket n'a pas de pull requests en brouillon, donc une exécution qui y échoue pousse sa branche sans en ouvrir. Un dépôt sur un serveur Git auto-hébergé n'obtient pas de pull request : le dernier message indique alors que l'agent a terminé et renvoie vers l'exécution.

Essayez

Lancer des exécutions depuis le chat nécessite les agents gérés, disponibles sur les plans Scale et Custom, ainsi qu'un espace de travail Slack ou Teams connecté. Liez votre compte de chat dans Profil → Comptes de chat, puis choisissez un fil où quelqu'un vient de demander quelque chose de petit et bien défini, et tapez @Archyl run.

La référence complète, y compris la façon dont s'appliquent les permissions et les portées de canal, se trouve dans la documentation, à la section Lancer des exécutions d'agent depuis Slack ou Teams.