Un ingegnere del team di Grok Bot è passato dal gestire 15 agenti cloud contemporaneamente a più di 200 in una volta sola.
Non con 200 bot. Con sei.
Cinque bot ingegneri, ognuno responsabile di un dominio, e un bot operations che non scrive una singola riga di codice. Nello stesso team, Lauren Tan ha chiuso oltre 2.000 PR in un mese.
È questo il dettaglio che sfugge alla maggior parte delle persone. Il primo bot funziona, così ne aggiungono un secondo, poi un quinto, poi un decimo. E si ritrovano con dieci finestre di chat aperte e un nuovo lavoro a tempo pieno: leggerle tutte.
Un mucchio di bot è solo un organico. Un team è una struttura. Questa guida è la struttura, basata su come le persone di xAI gestiscono i propri.
La versione da 30 secondi
- Un bot è un'assunzione. Un team ha bisogno di cinque cose: una porta d'ingresso, degli specialisti, una bacheca, un orologio e un cancello.
- Parli con un solo bot. È lui a smistare il lavoro agli altri.
- Ogni specialista possiede un dominio e mantiene la propria memoria.
- Il lavoro vive su una bacheca, non in una chat.
- Le routine fanno avanzare il lavoro mentre dormi. Le approvazioni decidono cosa può uscire.
- I team interni di xAI usano circa sei bot per farlo. Non sessanta.
Parte 1. Quando assumere il secondo bot
Non quando il primo è occupato. I bot non si "occupano" come fai tu.
Kevin Niparko gestisce un intero team di bot come PM in SpaceXAI, e la sua guida elenca tre motivi per dividere il lavoro tra più bot: referenziabilità ("Sai chi fa cosa"), parallelismo e memoria circoscritta.
Il terzo è la vera risposta. Nelle sue parole:
Il Chief of Staff non dovrebbe fare il debugging delle eval di computer-use.
Assumi il secondo bot quando la memoria di un singolo bot inizia a sobbarcarsi due lavori diversi.
Te ne accorgerai prima ancora di riuscire a dargli un nome. Il bot della posta inizia a rispondere con il tono del tuo code reviewer. Le preferenze del calendario finiscono nei brief di ricerca. Apri ogni messaggio dovendo ricordare al bot quale cappello indossa oggi.
Lingxi Li, che sviluppa Grok Bot usando Grok Bot, dice la stessa cosa dal punto di vista dell'ingegneria: i bot "danno il meglio quando si concentrano su un singolo dominio".
Il test: skill o bot?
La documentazione definisce una skill come "un set riutilizzabile di istruzioni su come eseguire un task", e le tue skill private sono un'unica libreria condivisa da tutti i tuoi bot.
Quindi un nuovo task è una skill. Un nuovo dominio con la propria memoria è un bot. Se non riesci a definire il dominio in tre parole, non ti serve ancora un altro bot.
Parte 2. Le cinque parti di un team
1. La porta d'ingresso
L'unico bot con cui parli davvero. La guida di Josh Kim lo chiama Bot Boss, l'"unica porta d'ingresso". Niparko lo chiama Chief of Staff e lo descrive in due frasi: "L'unico generalista. Resta in silenzio se non è cambiato nulla."
La porta d'ingresso smista. Non costruisce. Il prompt di Kim lo dice chiaramente: "sei un EA hub and spoke, non un builder e non un auditor".
Un prompt che puoi copiare:
Sei il mio Chief of Staff e l'unico bot con cui parlo. Smista ogni richiesta allo specialista competente, raccogli il risultato, confrontalo con quello che ho chiesto e fammi un report in cinque righe. Resta in silenzio se non è cambiato nulla.
2. Gli specialisti
Il roster di Niparko: un Chief of Staff, un engineering manager di nome Emily, cinque bot ingegneri, un data analyst, un bot PM e un recruiter. Il roster di Li: cinque bot ingegneri divisi per superficie (iOS, desktop, infrastruttura, Android, l'harness) più Jenny, head of operations.
Guarda cosa hanno in comune i due team. Un manager che non esegue materialmente il lavoro. Emily scompone i task, delega e verifica che l'output rispetti l'obiettivo. Jenny fa l'onboarding dei nuovi bot e gestisce i postmortem. Nessuna delle due scrive codice.
Per un primo team, tre specialisti bastano. Eric Zakariasson fissa un tetto massimo di sei bot per ogni canale di progetto e definisce quel limite "solo un numero arbitrario". Arbitrario, ma corretto.
3. La bacheca
Le chat scorrono via. Un team ha bisogno di un unico posto in cui viva lo stato del lavoro.
Il team di Li usa un tracker condiviso su Notion. Ogni 30 minuti i bot controllano ogni PR per CI fallite, commenti di review e conflitti di merge. I problemi tornano in Working. Quelli puliti passano a Ready for Review.
Zakariasson gestisce due database, Projects e Tasks, con un canale per progetto. Un bot che si blocca segna il suo task come Blocked e notifica l'umano. Per il resto del tempo, l'umano si limita a guardare le card che si spostano.
La frase migliore di tutte le guide viene proprio da lì:
La cosa interessante è che più ci costruisco sopra, più assomiglia a un sistema originariamente pensato per gli umani.
4. L'orologio
Una routine, secondo la documentazione, "dice a un Bot quando eseguire un workflow". Ogni bot può contenerne fino a 50, possono attivarsi anche ogni cinque minuti e continuano a girare con il laptop chiuso.
L'orologio di Li funziona così. Alle 3 di notte partono gli audit notturni: dead code, tempo di caricamento, dimensione del bundle. Alle 5 del mattino Jenny fa un 1:1 con ogni bot del team, rivede il playbook e fa emergere i blocchi. Il risultato riportato: i bot "raramente dimenticano i miei workflow complessi, anche dopo molte settimane".
Quello standup delle 5 del mattino è l'idea più sottovalutata di tutta l'architettura. Il contesto di un bot è limitato. La ripetizione è il modo in cui un team mantiene i propri standard, e qui è un bot a ripetere, così non devi farlo tu.
5. Il cancello
Niparko, su ciò che richiede ancora un umano:
Continuo a riservarmi la review finale per qualsiasi invio di email esterne, acquisto o azione distruttiva come le eliminazioni.
Kim va oltre. Il bot della posta è in sola lettura e non invia mai nulla finché non digiti la parola "send" in quel preciso momento.
Due fatti tratti dalla documentazione che cambiano il modo in cui progetti il cancello:
- Le approvazioni in background scadono. Quando una routine o un altro bot innesca un'azione che richiede il tuo sì, la richiesta scade dopo circa 10 minuti e l'azione non viene eseguita. Un job delle 3 di notte che aspetta te morirà nell'attesa. Decidi in anticipo: scrivi una regola di allow per quell'azione, oppure fai in modo che la routine si fermi a una bozza.
- Tutti i tuoi bot condividono un unico computer cloud. File, sessioni del browser e login sono disponibili per tutto il roster. La documentazione lo dice esplicitamente: non trattare i bot separati come un confine di sicurezza.
Dividi i bot per focus e memoria. La sicurezza te la dà il cancello.
Parte 3. Costruiscilo in cinque giorni
Giorno 1. La porta d'ingresso. Promuovi il tuo primo bot a Chief of Staff con il prompt qui sopra. Da ora in poi sarà l'unica chat che aprirai.
Giorno 2. Dividi per memoria. Elenca tutto ciò che il bot uno fa oggi e raggruppa la lista per dominio. I due gruppi più grandi diventano i tuoi primi due specialisti. Le impostazioni di un bot sono tre campi: Name, Title, Description. Compilali come se fosse un annuncio di lavoro.
Giorno 3. La bacheca. Una tabella con Task, Owner e Status: Todo, Working, Blocked, Ready for Review, Done. Poi dì la stessa cosa a ogni bot: nulla è completato finché non lo dice la bacheca, e se sei bloccato imposta Blocked e avvisami.
Giorno 4. L'orologio. Tre routine per iniziare: una board mattutina dal Chief of Staff, una scansione della bacheca ogni 30 minuti e un audit notturno. Testa ciascuna prima su input sicuri. La documentazione avverte che un'esecuzione di test "svolge lavoro reale".
Giorno 5. Il cancello. Scrivi le regole "chiedi prima": invii, acquisti, eliminazioni, pubblicazioni, qualsiasi cosa in produzione. Aggiungi una regola di allow per quell'azione che hai già approvato cinque volte di fila.
Poi lascialo stare per una settimana prima di assumere il quarto bot.
Cinque errori che affossano un team di bot
L'esercito di cloni. Cinque copie dello stesso generalista. Nessuna memoria circoscritta, nessun dominio, nessun vantaggio. Hai solo moltiplicato i costi mantenendo la confusione.
La chat di gruppo senza bacheca. I bot possono scambiarsi messaggi e innescarsi a vicenda. Senza uno stato condiviso, quella è una riunione, non lavoro.
Il capo che fa tutto. Una porta d'ingresso che inizia a svolgere i task da sola. Nel momento in cui il tuo Chief of Staff scrive il codice, nessuno smista più nulla e nessuno controlla.
Il listener sempre aperto. Un trigger su ogni nuovo messaggio. La documentazione sconsiglia esattamente questo perché genera rumore e brucia utilizzo. Filtra in modo specifico.
L'illusione della sicurezza. Credere che il bot finance non possa vedere a cosa ha fatto accesso il bot research. Stesso computer, stesse sessioni.
L'organigramma è il prodotto
Chi sviluppa Grok Bot non ha inventato una nuova architettura per i propri team. Ha ricostruito la più antica che esista: un manager, degli specialisti, una bacheca, uno standup e un sign-off.
La differenza è che questo team fa il suo standup alle 5 del mattino e nessuno si lamenta.
Inizia dalla porta d'ingresso. Aggiungi uno specialista. Non aggiungerne un terzo finché non esiste la bacheca.
P.S. Se non hai ancora assunto il primo bot, parti dalla mia guida precedente, "Grok Bot: How to Hire Your First AI Employee". Tutto ciò che è citato qui proviene dalle guide e dalla documentazione pubbliche di Grok Bot di xAI.
