Sette agenti IA gestiscono le nostre notti: agenti pianificati oltre il codice, con i prompt

Il 23 settembre, un utente di nome Rob ha scritto sul nostro backlog pubblico: «would love to get examples of how you guys are doing stuff beyond coding». Domanda giusta. Tutto questo sito parla di agenti di codice, e quello che facciamo davvero girare ogni sera, per la maggior parte, non è codice.

Dal 28 agosto, sette agenti partono su un Mac mini alle 20:00. Leggono i commit del giorno, la Search Console, le dashboard di amministrazione, il backlog, il feedback inviato dalle persone, i report della notte precedente. Correggono bug, correggono il sito web, scrivono e traducono un articolo del blog ogni tre giorni, pubblicano su tre social network, aggiornano una knowledge base del prodotto, e alle 22:00 il settimo legge quello che hanno lasciato gli altri sei e invia un'e-mail di 25 righe. Nessuno guarda. Il fondatore legge l'e-mail sul telefono la mattina dopo.

Questo articolo è la risposta a Rob. Cosa gira, come è collegato, come gli agenti si passano il lavoro senza mai parlarsi, quale modello fa quale mestiere e perché, le quattro regole che i loro prompt hanno dovuto imparare a proprie spese, e i prompt stessi, condensati in blocchi che puoi copiare. Ogni numero qui sotto viene dal repository: i report sono committati lì, notte dopo notte.

Cosa hanno prodotto 33 notti

La cartella dei report del repository ha 33 directory datate, dal 28 agosto al 30 settembre. Leggerle dà questo:

• 31 e-mail del mattino inviate dal relatore.
• 51 bug corretti dal correttore, ognuno con il link del commit nella sua riga di report. Diversi erano stati segnalati da utenti sul backlog pubblico e hanno ricevuto una risposta con la release successiva.
• 7 articoli del blog scritti dal team SEO dal 10 settembre, uno ogni tre giorni, ciascuno prima in inglese e in francese, poi in altre 18 lingue la stessa notte.
• 29 giorni di diario dei social: tre network e cinque gruppi Facebook per sera, più un commento di ringraziamento sotto ogni post in cui un utente ha condiviso AgentsRoom.
• Una knowledge base del prodotto di un centinaio di schede, tenuta allineata con i commit del giorno, che l'assistente integrato nell'app legge e che il sito serve come llms-full.txt.

Niente di tutto questo ha richiesto un umano dopo le 20:00. Una parte ha richiesto un umano alle 08:00, ed è proprio il senso dell'ultimo agente.

La formazione: chi parte alle 20:00

Ogni agente è un'Attività pianificata in AgentsRoom: un prompt, un agente (ruolo, CLI, modello), una macchina e un orario. Tutti e sette girano su Claude Code. Due di loro non sono agenti singoli ma team a due step, e torneremo sul perché.

I file .md dell'ultima colonna stanno tutti in reports/night/<date>/, committati e pushati. Quella cartella è l'intero sistema di coordinamento, e la sezione seguente spiega perché.

Come è collegato

Ognuno dei sette è un'Attività pianificata con la stessa forma:

• Parte ogni giorno alle 20:00 (alle 22:00 per il relatore). Nessuna espressione cron; la frequenza si sceglie nell'editor.
• Fissata su una sola macchina. Il progetto è aperto su più computer, e un trigger parte su ogni macchina che lo ha, a meno che tu non lo limiti. I nostri sono limitati al Mac mini, quindi un portatile aperto alle 20:05 non avvia un secondo CEO.
• Risveglia la macchina. Il Mac mini va in stop. L'attività ha un'opzione «risveglia la macchina», che programma un risveglio con lo strumento del sistema operativo stesso (pmset su macOS, l'Utilità di pianificazione con risveglio per l'esecuzione su Windows, rtcwake su Linux) qualche secondo prima dell'esecuzione. Senza, una macchina in stop salta semplicemente l'esecuzione.
• Recupero attivo o no, per attività. Se la macchina era spenta alle 20:00, un'attività con il recupero attivo parte all'avvio successivo. Il CEO, il PM e il relatore lo hanno attivo. Le attività SEO, correttore, social e documentazione lo hanno disattivato: un'esecuzione che partisse alle 11:00 della mattina dopo si scontrerebbe con il lavoro della giornata nello stesso checkout.
• La modalità dei permessi si imposta sull'attività, non sul provider. Un'esecuzione non presidiata non può fermarsi su una richiesta di approvazione alle 3 di notte, quindi l'attività gira senza, mentre gli agenti che il fondatore guida a mano sullo stesso CLI continuano a chiedere prima.
• La console si chiude dopo 60 minuti di inattività. Un agente che ha finito non resta nella barra laterale finché qualcuno non lo chiude.
• Il prompt è il primo messaggio. Il testo di ogni prompt è salvato nella Biblioteca Prompt ed è lo stesso testo del campo prompt del trigger, quindi modificarne uno significa modificarli entrambi. I prompt sono in francese, perché il fondatore legge i report in francese. Tutto il resto, dai messaggi di commit alla knowledge base, è in inglese.

Un ultimo pezzo è condiviso da tutti e sette: una skill chiamata «agenti notturni, regole comuni». Ogni prompt inizia con «carica questa skill e applicala», e la skill contiene tutto ciò che vale per tutti: chi si occupa di cosa, la guardia «una notte, un'esecuzione», i diritti git, il formato del report, le regole del backlog e il formato dell'e-mail per il relatore. Quando una regola cambia, cambia in un solo posto.

Come si passano il lavoro senza parlarsi

I sette agenti non si scambiano mai messaggi. Potrebbero, AgentsRoom ha una messaggistica tra agenti, ma un messaggio è invisibile la mattina dopo e non ci si può fare grep. Tutto passa da tre cose che sopravvivono alla notte:

Il repository. Ogni agente scrive reports/night/<date>/<agent>.md, lo apre nel primo minuto della sua esecuzione, lo riscrive dopo ogni lavoro finito, ne fa commit e push. Il report ha quattro sezioni fisse: «In due parole» (un elenco puntato, un punto per ogni cosa fatta), «Da decidere» (solo ciò che il prompt riserva all'umano), «Da verificare» (un URL locale o una schermata da aprire), «Dettagli» (lungo quanto serve). Termina con un marcatore di esecuzione: l'ultimo commit che l'agente ha visto.

Il backlog. Un agente che trova lavoro per un altro non fa quel lavoro. Apre un ticket con un tag: ceo-fix per un bug verificato e piccolo che prenderà il correttore; ceo-seo per un lavoro di contenuto con la sua query target; ceo-decision per tutto ciò che richiede l'umano (database, fatturazione, auth, crittografia, prezzi, un URL indicizzato, un comportamento predefinito). Il documentalista, leggendo i commit, trova una feature senza pagina sul sito: apre un ticket ceo-seo, e il SEO lo prende la notte seguente. Il CEO, leggendo i log degli errori, trova un bug con la sua causa nel codice: ceo-fix, e il correttore lo prende la notte seguente.

Il report di ieri. Prima di aprire qualsiasi lavoro, ogni agente legge il proprio report della notte precedente, più la lista dei ticket chiusi durante la giornata. Ciò che ha segnalato ieri spesso è stato corretto durante la giornata. Un argomento già trattato non viene sollevato di nuovo; un ticket già aperto non viene ricreato.

Il ciclo si chiude con l'umano. L'e-mail del relatore termina con una riga: per rispondere al product manager, aggiungi una sezione «## Decisioni» alla fine di rapport.md (P1 OK / P2 NO: motivo / P3 PIÙ TARDI), commit, push. Il PM legge la versione pushata la sera dopo ed esegue ciò che è stato approvato: crea il ticket, unisce i duplicati, parcheggia il resto con il motivo. Una decisione che resta senza risposta per tre notti è una decisione: la proposta esce dall'e-mail e resta come ticket.

Quale modello fa quale mestiere, e perché

La tabella qui sopra mostra due modelli. È la configurazione attuale, non un benchmark, e cambia. Ma la divisione è voluta.

Fable dove il mestiere è il giudizio. Il CEO decide se un pollice in giù su un oracolo è un errore reale o una preferenza. Il correttore decide se una segnalazione di bug è un bug o una configurazione specifica di una macchina, poi trova la causa nel codice. Lo step 1 del SEO decide quale frase del sito è diventata falsa con il commit di oggi, quale articolo scrivere e quale pagina lasciare in pace. Lo step 1 del Social sceglie l'argomento della sera e scrive per un pubblico che riconosce un testo generato in tre righe. Questi prompt sono lunghi (quello del SEO è di circa 4.000 parole) e pieni di regole «decidi tu, non chiedere» con brevi liste di eccezioni. È lì che il modello più forte si guadagna il suo costo.

Opus con un contesto da 1M dove il mestiere è il volume. Tradurre un articolo in 18 lingue con dei subagent, tre locale ciascuno, e poi controllare l'unione rispetto al riferimento francese, è leggere e scrivere, tanto, con le stesse regole applicate 18 volte. Il documentalista legge una giornata di diff contro un centinaio di schede. Il PM legge un export di 8 MB di conversazioni di uscita. Il relatore legge cinque report e copia, non pensa. Lì, un contesto ampio e un costo per token più basso contano più del giudizio.

Due dei sette sono quindi team di due step, ogni step un agente con il proprio modello. Lo step 1 su Fable finisce scrivendo una sezione «Handoff» nel report condiviso: la lista esatta di file e chiavi che il traduttore deve consegnare, o i post esatti che chi pubblica deve pubblicare. Lo step 2 su Opus legge quella sezione e fa solo ciò che elenca. Il grafo del team è lineare, un solo ciclo, e il report mantiene la sua riga «esecuzione in corso» finché lo step 2 non la toglie. Da fuori, alle 22:00, un report ancora segnato «in corso» significa o un'esecuzione interrotta o un team tra i suoi due step, e il relatore dice quale dei due.

Le quattro regole che i prompt hanno dovuto imparare

I primi prompt erano descrizioni di un ruolo. Quelli attuali sono soprattutto regole, e ogni regola ha una data, perché ognuna è stata scritta dopo una notte andata storta.

1. Un marcatore di esecuzione, letto nel report di ieri. La prima versione dell'agente SEO leggeva «i commit delle ultime 24 ore». Due problemi: un'esecuzione alle 20:00 e una alle 20:10 del giorno dopo non vedono le stesse 24 ore, e una notte in cui l'agente non è partito è una giornata di commit che nessuno guarda. Ora ogni report termina con Ultimo commit visto: <sha>, e l'esecuzione successiva parte da quel commit, qualunque cosa dica l'orologio. Nessun marcatore (prima notte, report mancante): due giorni indietro, e il report lo dice.

2. Lo storico è sul disco, quindi fai grep prima di sollevare qualsiasi cosa. La lamentela tornata più spesso nelle prime due settimane: «me l'hai già detto, l'ho corretto ieri». La soluzione è una regola con dentro un comando: prima di segnalare un argomento o aprire un lavoro, grep -ril "<l'argomento>" reports/night/ e git log --since="30 days ago" -- <il file>. Una corrispondenza significa leggere prima quel report. Tre casi, e solo tre, permettono di riparlare di un argomento trattato: la correzione non ha funzionato e l'hai appena verificato; la correzione è parziale e nomini ciò che resta; l'argomento ha cambiato natura. Con essa sono arrivati due corollari. Una notte, un'esecuzione: se il report di stanotte esiste, contiene «In due parole» e non dice più «esecuzione in corso», l'agente si ferma. E una proposta senza risposta per tre notti esce dal report; il ticket resta.

3. Il report si apre prima che il lavoro cominci. Un'esecuzione interrotta alle 21:30 non lasciava niente. Ora la prima cosa che fa un agente dopo aver caricato la skill è mkdir -p reports/night/$(date +%F) e scrivere lo scheletro del report con i suoi quattro titoli di sezione e una riga esecuzione in corso, avviata alle 20:01. Riscrive l'intero file dopo ogni lavoro finito. Un'esecuzione interrotta lascia un report parziale che il relatore può copiare, il che è molto meglio di un agente che «non è partito».

4. Commit man mano, mai alla fine. Misurato il 9 settembre: due agenti sono stati fermati nello stesso minuto. Quello che faceva commit dopo ogni lavoro non ha perso niente. L'altro ha lasciato 45 file modificati, non pushati e non attribuibili, che il fondatore ha raccolto a mano la mattina dopo, e il suo report non esisteva. Da allora la regola è un commit per lavoro finito, file nominati uno per uno, un ultimo commit per il report, e almeno un push durante l'esecuzione. Un commit è anche una traccia datata, ed è su questo che la regola 2 fa grep.

Una quinta regola non riguarda la memoria ma il coraggio, ed è quella che ha cambiato di più i risultati. Il prompt del SEO dice: «Non sei un auditor che riporta constatazioni: di notte, il sito è tuo. Un'esecuzione che termina con sei piste da validare è un'esecuzione fallita.» Poi elenca i sei casi, e solo sei, in cui l'agente deve chiedere invece di agire: eliminare o rinominare un URL, cambiare il titolo di una pagina che si posiziona, un testo legale, un prezzo o una quota, un'affermazione su privacy o crittografia, una modifica che tocchi più di cinque pagine. Tutto il resto lo fa, e il fondatore toglie ciò che non gli piace la mattina dopo. Il correttore ha la stessa regola con tre casi. Prima di quella regola, i report erano liste di suggerimenti. Dopo, sono liste di commit.

I prompt

Gli originali sono in francese e lunghi. Quello che segue è la parte che si può riportare altrove, senza i nostri percorsi e i nomi propri del progetto. Tre blocchi: le regole comuni che ogni agente carica, il relatore, e le due sezioni «decidi tu, non chiedere».

Blocco 1: le regole comuni (caricate da tutti e sette come skill)

# Agenti notturni: regole comuni
Prevalgono sul tuo prompt se i due si contraddicono.

## Una notte, un'esecuzione
DAY=$(date +%F); F=reports/night/$DAY/<tu>.md
Se F esiste, contiene «In due parole» e non contiene più «esecuzione in corso»:
fermati. Non scrivere niente, non inviare niente, termina con un messaggio di una riga.
Se dice ancora «esecuzione in corso»: è la tua stessa esecuzione, interrotta qualche minuto fa.
Riprendi da dove si è fermata, non ricominciare da capo.

## Cosa puoi fare
- Git: add <file nominati>, commit, push del TUO lavoro, man mano.
  Mai: add -A, commit -a, push --force, stash, reset, checkout, clean, nuovo branch.
- Build: typecheck, lint, script di controllo, una build locale per verificare.
  Mai: uno script che fa deploy o pubblica.
- Backlog: creare un ticket, aggiungere a un ticket, chiudere un ticket che hai corretto.
  Mai: rispondere a un utente (invia un'e-mail), eliminare un ticket, sovrascrivere una descrizione.
- Mai un numero inventato. Fonte non disponibile: dillo e vai avanti.
- Prima di qualsiasi scrittura git: git status --short. L'albero è condiviso con altri agenti.

## Mettersi in pari, e sapere cosa è GIÀ stato fatto
git fetch && git status -sb
Indietro e pulito: git pull --ff-only. Indietro e sporco: non fare pull, dillo in cima al tuo report.
Il tuo marcatore di esecuzione: la riga «Ultimo commit visto: <sha>» alla fine del report di ieri.
Nessun marcatore: --since="2 days ago", e dillo.
Tre letture obbligatorie prima di qualsiasi analisi:
1. git log --no-merges --format='%h %s' <sha>..HEAD e git diff --stat <sha>..HEAD
2. i ticket chiusi da ieri, e i ticket che un umano ha messo in attesa
3. il tuo report di ieri: «In due parole» e «Da decidere»

## La cartella dei report È il tuo storico
Prima di sollevare una constatazione o aprire un lavoro:
grep -ril "<argomento>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <il file>
Una corrispondenza: leggi quel report prima di decidere qualsiasi cosa.
Due notti di fila sullo stesso argomento: la seconda è sprecata.
Una pagina o un testo che hai toccato non si ritocca per tre settimane,
tranne per correggere qualcosa che è diventato falso.

## Mai sollevare due volte la stessa cosa
Una constatazione già trattata che torna il giorno dopo è un errore.
Solo tre casi lo permettono:
1. la correzione non ha funzionato, e l'hai appena verificato: «corretto il <data> con <commit>, ancora rotto: <prova>»
2. la correzione è parziale: nomina esattamente ciò che resta
3. l'argomento ha cambiato natura: nuova causa, nuova misura, nuovo perimetro
Non ricontare uno stock. Riporta la variazione, mai lo stock.

## Una proposta senza risposta muore dopo tre notti
Notti da 1 a 3: la riga porta il suo contatore e la prima data («2ª notte, sollevata il 07/09»).
Dalla 4ª: esce da «Da decidere». Il ticket resta; al massimo una riga in «Dettagli».
Se la decisione è di tua competenza, decidi la 3ª notte e dillo.

## Commit e push man mano
Primo commit appena il primo lavoro è finito e verificato. Poi uno per lavoro.
Ultimo commit per il tuo report. Fai push almeno una volta durante l'esecuzione e una volta alla fine.
Push rifiutato (il remoto è andato avanti): git pull --ff-only, poi push. Ancora rifiutato: non forzare,
non fare rebase, scrivilo nel report.

## Il tuo report: aperto all'inizio, mai scritto solo alla fine
reports/night/<YYYY-MM-DD>/<tu>.md, creato PRIMA del lavoro, con:
  # <Agente> - <data>
  _esecuzione in corso - avviata alle <HH:MM>_   (tolta alla fine)
  ## In due parole     (da 3 a 5 righe, o un elenco puntato: un punto per ogni cosa fatta)
  ## Da decidere       (solo ciò che il tuo prompt riserva all'umano; altrimenti «Niente»)
  ## Da verificare     (- [ ] cosa : dove : cosa si deve vedere; altrimenti «Niente»)
  ## Dettagli          (lungo quanto serve: prove, file, comandi)
  ## Marcatore di esecuzione
  Ultimo commit visto: <git rev-parse HEAD dopo il tuo ultimo commit>
Riscrivi l'intero file dopo ogni lavoro finito.
Chi legge è su un telefono, per due minuti: frasi brevi, niente percorsi di file,
niente SHA, niente nomi di funzione nella prima sezione. Un numero solo se cambia una decisione.

Blocco 2: il relatore (22:00)

Sei il relatore. Parti due ore dopo gli altri.
Il tuo unico lavoro: leggere ciò che hanno lasciato e inviare UNA e-mail che il fondatore legge
in un minuto su un telefono, e che capisce senza aprire nient'altro.
Non analizzi niente, non correggi niente, non proponi niente. Raccogli e chiarisci.

La notte di cui fai il resoconto si legge sul disco, non sull'orologio:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only se l'albero è pulito: i report sono committati.
2. ls reports/night/$DAY: aspetta i cinque file (ceo, seo, pm, fixer, social).
   Ne manca qualcuno: sleep 9 minuti e riconta, al massimo 6 giri. Poi invia comunque, nominando chi manca.
3. Un report che dice ancora «esecuzione in corso» è un'esecuzione interrotta, non assente.
   Copia ciò che contiene e scrivi in «Cosa non ha funzionato» che quell'agente è stato interrotto.
4. Da ogni report prendi solo tre sezioni: «In due parole», «Da decidere», «Da verificare».
   Non citare mai «Dettagli».
5. I bug corretti dal correttore sono punti in tre parti separate da " > ":
   cosa subiva l'utente > la causa in una frase > l'URL del commit.
   Copiali carattere per carattere, link compreso, in «Bug corretti».
6. git status -sb e git log --oneline --since="4 hours ago": un report che dichiara
   lavoro senza commit, file modificati che nessuno rivendica, o commit non pushati: prima riga dell'e-mail.

Scrivi reports/night/$DAY/rapport.md. Al massimo 25 righe di testo
(i titoli di sezione e le righe di «Bug corretti» non contano).
Sei regole, applicate riga per riga:
1. Un punto = una frase completa che si capisce da sola. Mai «come segnalato ieri».
2. Un argomento compare in UNA sola sezione.
3. Zero gergo: niente percorsi, niente SHA, niente nomi di chiavi, niente abbreviazioni interne.
   Un'eccezione: l'URL GitHub completo di un commit, obbligatorio su ogni riga di «Bug corretti».
4. Un numero solo se cambia una decisione, ed è una variazione, mai uno stock.
5. Al massimo due righe per punto. Il dettaglio è nel report dell'agente.
6. Le cattive notizie prima delle buone, e la prima riga dice se qualcosa è rotto.

Sezioni, in ordine: Da decidere / Da verificare / Bug corretti / Cosa è stato fatto /
Social network (3 righe max, link compresi) / CLI e modelli (1 riga) /
Cosa non ha funzionato. Una sezione vuota è una parola: «Niente».
Non tagliare mai: «Da decidere», «Bug corretti» con i link, i link dei post, l'articolo SEO.
Invia. Controlla il codice HTTP. Aggiungi «Inviato a ... - HTTP <code>» in fondo.
Commit e push di rapport.md. Non inviare mai due volte: se il rapport.md di oggi ha già
una riga «Inviato a», fermati.

Blocco 3: le sezioni «decidi tu, non chiedere»

L'agente SEO, sezione 0 del suo prompt:

# 0. Decidi tu, non chiedere
È la regola più importante di questo prompt e prevale sul tuo riflesso di prudenza.
Non sei un auditor che riporta constatazioni: di notte, il sito è tuo.
Un'esecuzione che termina con «ecco 6 piste, da validare» è un'esecuzione fallita.
Quando esiti, mettiti al posto del fondatore e decidi con quattro riferimenti:
- ciò che il prodotto fa davvero, letto nel repository e nella versione pubblicata, mai nel copy esistente;
- ciò che il sito dice già: il suo taglio, il suo tono, le sue promesse. Prolunghi, non reinventi;
- ciò che dice la Search Console: quali pagine vivono, quali intenti esistono davvero;
- il pubblico: sviluppatori che cercano su Google, e gli assistenti IA che consigliano strumenti.
  Ciò che conta per loro: un'affermazione verificabile e databile; una pagina che risponde a una domanda precisa;
  un llms.txt aggiornato e coerente con le pagine; confronti onesti.
Il fondatore legge il tuo report la mattina dopo e ti dirà di togliere ciò che non gli piace.
Una correzione di troppo costa cinque minuti; una notte senza risultati è persa per sempre.

Chiedi il suo parere solo in questi sei casi:
1. eliminare o rinominare un URL esistente;
2. cambiare il titolo o la meta description di una pagina che si posiziona, quando non è falso;
3. un testo legale (termini, privacy, licenza);
4. un prezzo, una quota commerciale, un'offerta;
5. un'affermazione su privacy, crittografia o su dove girano i dati;
6. una modifica che toccherebbe più di cinque pagine in una volta.
In questi sei casi: un ticket con tag per una decisione, una riga in «Da decidere», e vai avanti.
Tutto il resto lo fai stanotte. Se «Da decidere» contiene altro,
hai delegato una decisione che era tua.

Il correttore, sezione 0 del suo prompt:

# 0. Correggi tu, non classificare
Un bug segnalato da un utente è una promessa. Qualcuno si è preso il tempo di scrivere, sta aspettando,
e nessun altro se ne occuperà stanotte. Un'esecuzione che restituisce «5 bug analizzati, 1 corretto,
4 documentati» è un'esecuzione fallita. Il tuo obiettivo è la coda vuota: prima i bug degli utenti,
dal più vecchio al più recente, poi il resto, finché non ne restano più.
Quando esiti su una correzione, decidi con tre riferimenti:
- ciò che il codice fa oggi, letto, non supposto;
- ciò che l'utente si aspettava chiaramente quando ha scritto la segnalazione;
- il rischio minore: la correzione più circoscritta che risolve la causa, non la più elegante.
Una correzione discutibile costa cinque minuti da annullare; un bug lasciato un altro mese costa un utente.

Puoi lasciare un bug segnalato senza correzione solo in tre casi, dimostrati nel ticket:
1. non hai trovato la causa dopo un'indagine vera: scrivi cosa hai escluso,
   non solo «non riproducibile»;
2. non è un bug, è una decisione: database, fatturazione, auth, crittografia, privacy,
   un URL indicizzato, un comportamento predefinito. Ticket per una decisione, con la tua raccomandazione;
3. un gate rifiuta la tua correzione e non sai ripararlo.
«È grosso», «tocca diversi file», «preferisco chiedere» non sono motivi.
Un bug = un commit. Poi il ticket passa a completato, e se l'ha segnalato un utente,
un messaggio di due frasi viene messo in coda per la release successiva. Mai «in attesa»: quella colonna
appartiene agli umani.
La tua riga di report per ogni bug corretto, copiata alla lettera nell'e-mail del mattino:
- <cosa subiva l'utente> > <la causa, in una frase semplice> > <URL del commit>

Gli altri quattro prompt (CEO, PM, documentalista, step 2 del SEO) seguono lo stesso scheletro: carica la skill, nomina i file che puoi scrivere, elenca le letture in ordine, di' cosa va nel ticket e cosa va nel report, termina con il marcatore di esecuzione.

Cosa non ha funzionato, e ancora non funziona

Alcune notti compaiono nella sezione «Cosa non ha funzionato» dell'e-mail, e vale la pena elencarle perché sono quello in cui ti imbatterai.

• Cinque agenti che fanno push sullo stesso branch nello stesso minuto. Un push viene rifiutato perché il remoto è andato avanti. La regola è git pull --ff-only e poi push, mai forzare, e se fallisce due volte il report lo dice e l'umano fa push al mattino. Succede più o meno una volta a settimana.
• Un commit che si è portato dietro un file in staging di un altro agente. Il 29 settembre il primo commit del SEO ha incluso un'eliminazione che il documentalista aveva messo in staging nel checkout condiviso. Non si è perso niente (l'eliminazione era voluta), ma il commit è attribuito all'agente sbagliato. Da allora ogni commit usa percorsi espliciti, e la regola «file nominati uno per uno» non è una preferenza di stile.
• Un disco arrivato a zero byte liberi alle 20:10, due sere di fila. Esterno agli agenti, si è ripreso da solo alle 20:25, nessun file perso. Ma i report lo dicono, perché una notte con il disco pieno sembra esattamente una notte in cui un agente non ha fatto niente.
• Il relatore che aspetta 54 minuti un report che non arriverà. Sei giri da nove minuti è il limite. Un team tra i suoi due step alle 22:00 sembra un'esecuzione interrotta, e l'e-mail dice «non aveva finito», il che è onesto e un po' allarmante da leggere.
• Le prime settimane di constatazioni ripetute. La regola 2 qui sopra non esisteva finché il fondatore non ha scritto «me l'hai detto tre giorni fa» per la quarta volta.

Come impostarlo da te

Non ti servono sette agenti. Te ne serve uno che scriva un report che leggerai, e un relatore è utile solo dal terzo agente in poi. In AgentsRoom:

1. Scrivi il prompt nella Biblioteca Prompt. Parti dal blocco 1 qui sopra come skill, e da un prompt breve che dica di cosa si occupa questo agente e quali file può scrivere.
2. Crea un'Attività pianificata sul progetto: giornaliera all'ora che vuoi, il ruolo, il CLI e il modello dell'agente, il prompt, e nel blocco avanzato la modalità dei permessi per un'esecuzione non presidiata. Fissala sulla macchina che la eseguirà, e attiva «risveglia la macchina» se quella macchina va in stop.
3. Crea la cartella reports/night/ nel repository e fanne commit. È l'intero livello di coordinamento.
4. Aggiungi un secondo agente il giorno in cui il primo comincia a produrre ticket per qualcun altro: un tag ceo-fix significa qualcosa solo quando un correttore lo legge la notte seguente.
5. Quando un mestiere si divide in giudizio e volume, trasformalo in un team di due step con due modelli, e fai scrivere allo step 1 una sezione di handoff che lo step 2 legge.

La pagina Attività pianificate descrive i campi, e l'articolo su mettere gli agenti di codice nel turno di notte è il ragionamento che è venuto prima della formazione. Se i tuoi agenti condividono una macchina, leggi prima cosa succede quando dieci di loro lanciano lo stesso comando: è successo qui, di notte, e la soluzione è un piccolo lock condiviso.

Rob, ecco cosa facciamo oltre il codice. I prompt sono il prodotto.

Domande frequenti

Serve AgentsRoom per far partire agenti a orario fisso in questo modo?

No. Una riga di cron e claude -p avviano una sessione di Claude Code alle 20:00 su qualsiasi macchina. Quello che scrivi tu dopo è il resto: risvegliare un computer in stop, recuperare un'esecuzione che la macchina ha saltato, tenere una sola esecuzione per notte quando il progetto è aperto su due computer, passare un report da un agente a un secondo agente con un altro modello, e vedere sul telefono che l'esecuzione è bloccata su una domanda. Le Attività pianificate di AgentsRoom coprono questi pezzi, e i sette agenti di questo articolo li usano tutti. I prompt e le regole si riportano così come sono, qualunque cosa avvii la sessione.

Quanto costa una notte di sette agenti?

Girano come sessioni di Claude Code su un abbonamento Claude, come qualsiasi agente che avvii in AgentsRoom, quindi non c'è una fattura a token per loro, e non abbiamo pubblicato un costo per notte. La regola che lo tiene sotto controllo è la guardia «una notte, un'esecuzione»: un trigger che parte due volte, o un'esecuzione interrotta e rilanciata, non rifà il lavoro, perché la prima cosa che fa ogni agente è controllare se il report di stanotte esiste già ed è chiuso.

È sicuro lasciare che gli agenti facciano commit e push senza nessuno davanti?

È sicuro per quello che non hanno il permesso di fare, non per quello che gli si chiede di volere. Le regole comuni vietano git add -A, commit -a, il push forzato, stash, reset, checkout, clean, la creazione di un branch e qualsiasi script che faccia deploy. Ogni commit nomina i suoi file uno per uno, l'albero viene ispezionato con git status prima di qualsiasi scrittura, e un push rifiutato perché il remoto è andato avanti si risolve con un pull in fast-forward o si lascia all'umano. La revisione del mattino è la lista dei commit della notte, e ciò che non va è un revert di cinque minuti.

Perché gli agenti scrivono report in Markdown nel repository invece di una dashboard?

Perché il report è anche la memoria. Ogni agente inizia leggendo il proprio report della notte precedente, ci trova il suo marcatore di esecuzione (l'ultimo commit che ha visto), e fa grep su tutta la cartella dei report prima di sollevare qualsiasi cosa, così un argomento trattato la settimana scorsa non viene sollevato di nuovo. Una dashboard mostrerebbe gli stessi numeri e non ricorderebbe niente. Fare commit del report lo data anche, ed è questo che permette alla notte successiva di sapere esattamente cosa ha toccato quella precedente.

Perché due dei sette agenti sono team di due step con due modelli diversi?

Perché le due metà del lavoro non sono lo stesso lavoro. Lo step SEO che legge la Search Console, decide cosa è falso sul sito e scrive l'articolo in inglese e in francese richiede giudizio, e gira su Fable. Tradurre quell'articolo in altre 18 lingue, far passare i gate i18n e la build è volume, e gira su Opus con un contesto da 1M. Il primo step scrive una sezione di handoff esplicita nel report condiviso, il secondo fa solo ciò che quella sezione elenca. Stessa divisione per il team Social: scrittura e visual su Fable, pubblicazione in Chrome e ringraziamenti su Opus.

Cosa succede quando un'esecuzione viene interrotta a metà?

Il report esiste dal primo minuto dell'esecuzione, con una riga che dice «esecuzione in corso», e ogni lavoro finito viene committato subito. Quindi un'esecuzione interrotta alle 21:40 lascia un report parziale, i suoi commit e nessun file non tracciato. Il relatore copia il report parziale e scrive che l'agente è stato interrotto. L'abbiamo imparato a nostre spese il 9 settembre: due agenti si sono fermati nello stesso minuto, quello che faceva commit man mano non ha perso niente, l'altro ha lasciato 45 file modificati che nessuno riusciva ad attribuire.