Un ingénieur de l'équipe Grok Bot est passé de 15 agents cloud exécutés simultanément à plus de 200 d'un coup.
Pas avec 200 bots. Avec six.
Cinq bots ingénieurs, chacun responsable d'un domaine, et un bot ops qui n'écrit pas une seule ligne de code. Dans la même équipe, Lauren Tan a livré plus de 2 000 PR en un mois.
C'est ce que la plupart des gens ne voient pas. Leur premier bot fonctionne, alors ils en ajoutent un deuxième, puis un cinquième, puis un dixième. Résultat : dix fenêtres de chat et un nouveau travail à temps plein, les lire.
Une pile de bots, c'est juste du headcount. Une équipe, c'est une structure. Ce guide est cette structure, tirée directement de la façon dont les équipes de xAI gèrent les leurs.
La version en 30 secondes
- Un bot, c'est une embauche. Une équipe a besoin de cinq choses : une porte d'entrée, des spécialistes, un tableau, une horloge et une barrière.
- Vous ne parlez qu'à un seul bot. C'est lui qui distribue le travail aux autres.
- Chaque spécialiste possède un domaine et conserve sa propre mémoire.
- Le travail vit sur un tableau, pas dans un chat.
- Les routines font avancer le travail pendant que vous dormez. Les validations décident de ce qui a le droit de sortir.
- Les équipes de xAI elles-mêmes font tourner tout ça avec environ six bots. Pas soixante.
Partie 1. Quand embaucher le deuxième bot
Pas quand le premier est débordé. Les bots ne saturent pas comme vous.
Kevin Niparko dirige une équipe complète de bots en tant que PM chez SpaceXAI, et son guide donne trois raisons de répartir le travail entre plusieurs bots : la traçabilité (« on sait qui fait quoi »), le parallélisme et la mémoire cloisonnée.
La troisième est la vraie réponse. Selon ses mots :
Le Chief of Staff ne devrait pas être en train de debugger des evals computer-use.
Embauchez le deuxième bot quand la mémoire du premier commence à porter deux casquettes.
Vous le verrez avant même de pouvoir le nommer. Le bot de messagerie se met à répondre avec la voix de votre reviewer de code. Vos préférences d'agenda fuient dans vos briefs de recherche. Vous ouvrez chaque message en rappelant au bot quel rôle il joue aujourd'hui.
Lingxi Li, qui construit Grok Bot avec Grok Bot, dit exactement la même chose côté ingénierie : les bots « performent mieux lorsqu'ils sont concentrés sur un seul domaine ».
Le test : compétence ou bot ?
La documentation définit une compétence (skill) comme « un ensemble réutilisable d'instructions expliquant comment réaliser une tâche », et vos compétences privées forment une bibliothèque unique partagée par tous vos bots.
Donc une nouvelle tâche est une compétence. Un nouveau domaine avec sa propre mémoire est un bot. Si vous ne pouvez pas nommer le domaine en trois mots, vous n'avez pas encore besoin d'un autre bot.
Partie 2. Les cinq éléments d'une équipe
1. La porte d'entrée
Le seul bot auquel vous parlez vraiment. Le guide de Josh Kim l'appelle Bot Boss, la « porte d'entrée unique ». Niparko l'appelle Chief of Staff et le décrit en deux phrases : « Le seul généraliste. Reste silencieux si rien n'a changé. »
La porte d'entrée aiguille. Elle ne construit pas. Le prompt de Kim le dit sans détour : « tu es un EA hub and spoke, pas un builder et pas un auditeur ».
Un prompt que vous pouvez copier :
Tu es mon Chief of Staff et le seul bot auquel je parle. Transmets chaque demande au spécialiste qui en est responsable, collecte le résultat, vérifie-le par rapport à ma demande initiale, et fais-moi un retour en cinq lignes. Reste silencieux si rien n'a changé.
2. Les spécialistes
L'équipe de Niparko : un Chief of Staff, une engineering manager appelée Emily, cinq bots ingénieurs, un data analyst, un bot PM et un recruteur. Celle de Li : cinq bots ingénieurs répartis par surface (iOS, desktop, infrastructure, Android, le harness) plus Jenny, responsable des opérations.
Regardez ce que ces deux équipes ont en commun. Un manager qui ne fait pas le travail. Emily découpe les tâches, délègue et vérifie que le livrable correspond à l'objectif. Jenny intègre les nouveaux bots et anime les postmortems. Aucune des deux n'écrit de code.
Pour une première équipe, trois spécialistes suffisent. Eric Zakariasson plafonne chaque canal de projet à six bots et qualifie cette limite de « simple nombre arbitraire ». Arbitraire, mais juste.
3. Le tableau
Les chats défilent et disparaissent. Une équipe a besoin d'un endroit unique où vit l'état du travail.
L'équipe de Li utilise un tracker partagé dans Notion. Toutes les 30 minutes, les bots vérifient chaque PR à la recherche de CI en échec, de commentaires de review et de conflits de merge. Les problèmes retournent dans Working. Ce qui est propre passe en Ready for Review.
Zakariasson gère deux bases de données, Projects et Tasks, avec un canal par projet. Un bot bloqué marque sa tâche Blocked et notifie l'humain. Le reste du temps, l'humain regarde simplement les cartes avancer.
La meilleure phrase de tous ces guides vient de celui-là :
Le plus intéressant, c'est que plus je construis dessus, plus cela ressemble à un système initialement conçu pour des humains.
4. L'horloge
Une routine, selon la documentation, « indique à un Bot quand exécuter un workflow ». Chaque bot peut en contenir jusqu'à 50, elles peuvent se déclencher toutes les cinq minutes, et elles continuent de tourner même quand votre ordinateur portable est fermé.
Voici à quoi ressemble l'horloge de Li. À 3 h du matin, les audits nocturnes tournent : code mort, temps de chargement, taille du bundle. À 5 h, Jenny fait un point individuel avec chaque bot de l'équipe, passe le playbook en revue et fait remonter les blocages. Le résultat constaté : les bots « oublient rarement mes workflows complexes, même après plusieurs semaines ».
Ce standup de 5 h est l'idée la plus sous-estimée de tout le dispositif. Le contexte d'un bot est limité. La répétition est le moyen pour une équipe de maintenir ses standards, et ici, c'est un bot qui répète pour que vous n'ayez pas à le faire.
5. La barrière
Niparko, sur ce qui nécessite encore un humain :
Je garde toujours la validation finale pour tout envoi d'e-mail externe, tout achat, ou toute action destructive comme les suppressions.
Kim va plus loin. Son bot de messagerie est en lecture seule et n'envoie jamais rien tant que le mot « send » n'a pas été tapé à l'instant T.
Deux faits tirés de la documentation qui changent la façon de concevoir cette barrière :
- Les validations en arrière-plan expirent. Lorsqu'une routine ou un autre bot déclenche une action nécessitant votre accord, la demande expire au bout d'environ 10 minutes et l'action ne s'exécute pas. Une tâche de 3 h du matin qui vous attend mourra d'attendre. Décidez à l'avance : soit vous écrivez une règle d'autorisation pour elle, soit vous faites en sorte que la routine s'arrête à l'étape de brouillon.
- Tous vos bots partagent le même ordinateur cloud. Les fichiers, les sessions de navigateur et les identifiants sont accessibles à toute l'équipe. La doc le dit explicitement : ne considérez pas des bots séparés comme une frontière de sécurité.
Vous séparez les bots pour la concentration et la mémoire. La sécurité, c'est la barrière qui vous l'apporte.
Partie 3. Construisez-la en cinq jours
Jour 1. La porte d'entrée. Promouvez votre premier bot au poste de Chief of Staff avec le prompt ci-dessus. Désormais, c'est le seul chat que vous ouvrez.
Jour 2. Séparez par mémoire. Listez tout ce que le bot numéro un fait aujourd'hui et regroupez la liste par domaine. Les deux groupes les plus importants deviennent vos deux premiers spécialistes. Les paramètres d'un bot tiennent en trois champs : Name, Title, Description. Remplissez-les comme une offre d'emploi.
Jour 3. Le tableau. Un seul tableau avec Task, Owner et Status : Todo, Working, Blocked, Ready for Review, Done. Ensuite, dites la même chose à chaque bot : rien n'est terminé tant que le tableau ne le dit pas, et si tu es bloqué, passe en Blocked et notifie-moi.
Jour 4. L'horloge. Trois routines pour commencer : un briefing matinal du tableau par le Chief of Staff, un balayage du tableau toutes les 30 minutes, et un audit nocturne. Testez d'abord chacune sur des données inoffensives. La documentation prévient qu'un test « exécute un vrai travail ».
Jour 5. La barrière. Écrivez les règles de validation préalable : envois, achats, suppressions, publications, tout ce qui touche la production. Ajoutez une règle d'autorisation pour l'action que vous avez déjà approuvée cinq fois de suite.
Puis laissez tourner une semaine avant d'embaucher le quatrième bot.
Cinq erreurs qui tuent une équipe de bots
L'armée de clones. Cinq copies du même généraliste. Pas de mémoire cloisonnée, pas de domaine, aucun gain. Vous avez multiplié les coûts et conservé la confusion.
Le groupe de discussion sans tableau. Les bots peuvent s'envoyer des messages et se déclencher mutuellement. Sans état partagé, c'est une réunion, pas du travail.
Le boss qui met les mains dans le cambouis. Une porte d'entrée qui se met à exécuter les tâches elle-même. Dès l'instant où votre Chief of Staff écrit le code, plus personne n'aiguille et plus personne ne contrôle.
L'écouteur trop large. Un déclencheur sur chaque nouveau message. La documentation met précisément en garde contre cela, car ça génère du bruit et brûle votre quota. Ciblez étroitement.
L'illusion de sécurité. Croire que le bot finance ne peut pas voir sur quoi le bot recherche s'est connecté. Même ordinateur, mêmes sessions.
L'organigramme est le produit
Les personnes qui construisent Grok Bot n'ont pas inventé une nouvelle architecture pour leurs propres équipes. Elles ont reconstruit la plus ancienne qui existe : un manager, des spécialistes, un tableau, un standup et une validation.
La différence, c'est que cette équipe tient son standup à 5 h du matin et que personne ne s'en plaint.
Commencez par la porte d'entrée. Ajoutez un spécialiste. N'en ajoutez pas un troisième tant que le tableau n'existe pas.
P.-S. Si vous n'avez pas encore embauché votre premier bot, commencez par mon guide précédent, « Grok Bot: How to Hire Your First AI Employee ». Tout ce qui est cité ici provient des guides et de la documentation publics de Grok Bot de xAI.
