La configuration, c'est la partie que personne n'a envie de cliquer
Un nouveau workspace, c'est créer des agents, rédiger leurs instructions, connecter des outils et fixer des planifications. Une fois, ça va. Pour dix projets, ou pour chaque client qu'une agence accueille, c'est un après-midi de formulaires.
Nous avons donc rendu Waggle pilotable par l'assistant que vous avez déjà. Il y a deux portes. hachi est une CLI pensée pour les agents : du JSON sur stdout à chaque appel, des erreurs typées, des codes de sortie stables, --dry-run, et un garde-fou --yes sur tout ce qui est destructif. Et il y a un endpoint MCP, qui expose les mêmes outils à n'importe quel client MCP.
Les deux sont disponibles aujourd'hui. Installez la CLI avec brew install hachiflow/tap/hachi, puis lancez hachi mcp serve pour un serveur stdio local. Ou évitez l'installation et utilisez l'endpoint hébergé à l'adresse https://api.hachiflow.com/mcp. Les outils sont les mêmes dans les deux cas.
Comment nous l'avons utilisé nous-mêmes
Nous avons connecté un assistant de code IA à l'endpoint hébergé et décrit une dizaine de projets dans un seul fichier : un workspace pour chacun, avec ses agents, ses connecteurs et ses planifications. Nous lui avons demandé de lancer hachi_plan, de lire le diff, puis de lancer hachi_apply.
Un appel plus tard, dix workspaces existaient, avec leurs agents, leurs connecteurs et leurs planifications en place. Personne n'a cliqué dans dix assistants de création.
Il restait les identifiants propres à chaque workspace, c'est-à-dire la partie qu'il vaut mieux laisser à une personne. Nous y revenons plus bas.
Une agence, deux clients, un fichier
Imaginons une agence qui accueille deux clients et veut un agent de boîte de réception et un agent de reporting pour chacun. Ajoutez d'abord l'endpoint hébergé à Claude Code, puis connectez-vous dans le navigateur avec votre identifiant hachiflow habituel. C'est de l'OAuth via WorkOS AuthKit, donc aucune clé d'API à coller.
Décrivez ensuite le travail. La spécification ci-dessous donne toute la forme : deux workspaces, deux agents chacun, et une planification en semaine sur chaque agent de boîte de réception. Chaque agent porte le nom de son client, pour que l'on s'y retrouve facilement dans une liste.
Lancez d'abord le plan. Il ne change rien et affiche ce que l'application ferait. Appliquez ensuite. L'application est déclarative et convergente : relancez-la et elle indique qu'il n'y a rien à faire, modifiez une instruction et cela devient une seule mise à jour.
L'exemple complet. Aucun secret dans le fichier : les connexions aux connecteurs et l'identifiant du modèle de chaque workspace reviennent sous forme de relais humains qu'une personne termine.
L'assistant s'occupe de la configuration, une personne des secrets
L'application ne prétend pas tout faire. Elle renvoie une liste de relais humains, les étapes que seule une personne peut accomplir : identifiants des connecteurs, identifiant du modèle pour chaque workspace, et invitations. Relancez le plan une fois ces étapes faites, il ne devrait plus contenir que des no-ops.
Les secrets ne vont jamais dans le fichier de spécification et ne passent jamais par le modèle. Les identifiants sont conservés sous séquestre, et les agents reçoivent des baux, jamais les valeurs. Ils sont aussi séparés par workspace, par conception. Les clients d'une agence ont chacun leurs clés et leurs accès, et une clé unique pour tout le compte brouillerait justement cette frontière.
L'assistant peut donc faire la saisie, et la personne fait la partie qui demande de la confiance : se connecter une fois aux outils de chaque client.
Pourquoi cela convient à une agence
La configuration d'une agence est répétitive par nature. Chaque client reçoit un workspace, quelques agents nommés d'après lui, les mêmes connecteurs et une planification du matin. C'est un modèle où l'on change un nom, ce que fait bien un agent.
Avec le fichier sous gestion de versions, ajouter un client revient à quelques lignes et à un plan pour les vérifier. L'assistant de l'agence fait la configuration et ses équipes s'occupent des relais humains. Rien ne change dans l'exécution des agents : ils tournent toujours sur la machine de la personne à qui ils appartiennent.
La configuration est gratuite, l'exécution des agents ne l'est pas
Un compte peut créer des workspaces et configurer des agents sans abonnement et sans machine. Un agent créé ainsi attend d'avoir un endroit où tourner. Seule l'exécution des agents coûte de l'argent, parce qu'elle consomme du calcul.
C'est volontaire. Un assistant doit pouvoir tout construire pour vous et vous le montrer avant qu'on vous demande une carte. Vous payez quand le travail commence, pas pour la préparation.
Ensuite : des agents qui achètent le service eux-mêmes
Cette partie est planifiée, pas construite. Nous travaillons à ce qu'un agent puisse payer le service lui-même via HTTP 402, avec les paiements machine de Stripe : le Machine Payments Protocol et les Shared Payment Tokens. Nous avons candidaté pour devenir fournisseur Stripe Projects et pour une inscription au Stripe Directory. Aucune des deux n'est approuvée pour l'instant, donc rien de tout cela ne fonctionne aujourd'hui.
La seconde moitié est un parcours de prise en charge par un humain, lui aussi planifié. Un agent configure tout, envoie un lien de prise en charge, et la personne arrive dans un workspace qui correspond exactement à sa demande. Il ne lui reste que les secrets.
Aujourd'hui, un agent peut faire la configuration, mais une personne doit encore créer le compte et, pour exécuter des agents, choisir un abonnement. L'objectif est de combler cet écart sans écarter la personne des décisions qui comptent.
Disponible aujourd'hui, et la suite
Disponible : la CLI hachi, le MCP local et hébergé, plan et application depuis un seul fichier, relais humains pour les identifiants, et configuration gratuite. Planifié : des agents qui paient via HTTP 402, et le parcours de prise en charge. Si vous dirigez une agence et voulez essayer la moitié disponible, l'endpoint et l'exemple ci-dessus suffisent pour commencer.