Più agenti di intelligenza artificiale sullo stesso progetto: quando conviene
Un rig è una squadra di agenti di coding dichiarata in un file YAML e avviata con un comando solo. Il nome arriva da OpenRig, il progetto open source che fa girare Claude Code e Codex dentro la stessa squadra invece di obbligarvi a sceglierne uno, e che ha pubblicato la versione 0.5.17 il 27 settembre 2026. Mettere più agenti di intelligenza artificiale sullo stesso progetto però non conviene sempre, e il criterio per decidere è più corto di quanto sembri.
Che cosa fa OpenRig con Claude Code e Codex
OpenRig prende sessioni di agenti che di solito vivono in terminali separati e le tiene insieme come una squadra persistente. Il README del progetto lo riassume in due righe: "A harness wraps a model. A rig wraps your harnesses. Define your agent team in YAML, boot it with one command". Oltre a Claude Code e Codex la topologia può contenere nodi di terminale semplice e un adattatore Pi, e si dichiara in un file YAML chiamato RigSpec, con i posti della squadra, i collegamenti fra loro e le politiche di continuità.
Il progetto si installa con npm install -g @openrig/cli, chiede Node.js 20, 22 o 24 e tmux come requisito obbligatorio, è distribuito con licenza Apache 2.0 e su GitHub ha raccolto circa 1.200 stelle. Fra le topologie già pronte ci sono first-project, da due posti chiamati dev-owner e dev-check, e conveyor, da quattro.
I comandi con cui si guida la squadra
I comandi di OpenRig coprono l'avvio, i messaggi e la modifica della squadra mentre gira.
| Comando | Cosa fa |
|---|---|
rig up | avvia la topologia dichiarata nel YAML e crea le sessioni tmux |
rig send | manda un messaggio a un singolo agente della squadra |
rig broadcast | manda lo stesso messaggio a tutti |
rig chatroom | apre una stanza condivisa fra più agenti |
rig grow e rig shrink | aggiungono o tolgono posti a squadra accesa |
rig ps | mostra lo stato dei nodi |
Quando conviene mettere più agenti di intelligenza artificiale sullo stesso progetto
Una squadra di agenti conviene quando il lavoro si divide in parti che non hanno bisogno di condividere il ragionamento, e non conviene quasi mai per accelerare un compito unico. È la stessa logica per cui un subagent di Claude Code si usa per togliere rumore dal contesto e non per fare le cose più in fretta: due agenti sullo stesso filo di pensiero passano il tempo a riallinearsi.
La forma che regge meglio è quella dove chi verifica non è chi ha scritto. Non a caso la topologia di ingresso di OpenRig si chiama first-project e ha due soli posti, dev-owner e dev-check: uno produce, l'altro controlla. Un secondo agente che rilegge con occhi puliti aggiunge qualcosa che un agente solo non può darvi, perché non ha modo di dimenticare quello che ha appena deciso.
Quattro situazioni, e cosa conviene in ciascuna
Le quattro situazioni qui sotto coprono quasi tutti i casi reali, e in due su quattro la risposta è di restare con un agente solo.
| Situazione | Conviene una squadra di agenti? |
|---|---|
| Un compito lungo ma con un solo filo di ragionamento | No, un agente solo e semmai un subagent per le ricerche |
| Chi scrive e chi verifica, separati | Sì, è la forma dev-owner e dev-check |
| Due parti del progetto che non si toccano mai | Sì, se il confine sta nel filesystem e non nelle intenzioni |
| Due agenti sullo stesso file | No, e non lo risolve nessun orchestratore |
Come coordino due agenti AI su questo sito senza nessun orchestratore
Su marcomasut.com due agenti scrivono ogni giorno sullo stesso repository, e non condividono né tmux né un runtime. Dentro automazione-blog/cloud-agent/ ci sono due prompt separati, prompt-articolo-notizie.md e prompt-articolo-business.md: sono due routine schedulate che partono a mezz'ora di distanza, una per chi costruisce prodotti con l'AI e una per gli imprenditori di PMI. Il coordinamento passa da git e da un campo di testo.
Il campo è sourceId nel frontmatter di ogni articolo, e contiene l'identificativo della riga Notion da cui quell'articolo è nato. La seconda routine, prima di scegliere, fa git fetch origin main e poi legge i sourceId già presenti in content/blog/: quello che trova, lo scarta. Sopra c'è un tetto dichiarato di due articoli al giorno sul sito intero, non per routine, che vale come freno comune.
Quel meccanismo non è elegante e le due routine girano così dal 3 agosto 2026, data che sta scritta dentro i prompt stessi. Il pezzo che fa il lavoro non è il trasporto dei messaggi, è la regola scritta su chi possiede cosa, la stessa che serve quando si decide chi controlla gli agenti AI in azienda.
Cosa cambia davvero per chi costruisce prodotti con l'AI
Il valore di OpenRig non sta nel far girare due agenti insieme, sta nel costringervi a scrivere la topologia prima di accenderla. Un file RigSpec con i posti, i collegamenti e le politiche di continuità è un documento che vi obbliga a dire chi fa cosa e chi parla con chi, e quel documento è esattamente la parte che manca quando una squadra di agenti va storta. La buona notizia è che quella parte potete scriverla oggi, senza installare niente.
I quattro passaggi da fare prima di installare un orchestratore
I quattro passaggi qui sotto valgono anche se non installerete mai OpenRig, perché riguardano la divisione del lavoro e non lo strumento.
- Scrivete chi possiede cosa in termini di percorsi, non di ruoli. "Il revisore" non è un confine,
content/blog/lo è. - Date a ogni agente un modo per vedere cosa ha già fatto l'altro. Sul mio sito è un campo nel frontmatter più un
git fetch, e costa due righe di prompt. - Mettete un tetto numerico all'output complessivo, non per agente. È il freno che vi salva quando due agenti sbagliano nello stesso momento.
- Solo se la regola scritta non basta più, provate
npm install -g @openrig/clierig setup --dry-run, e partite dafirst-projecta due posti. Una squadra da quattro comeconveyorsi guarda dopo, non prima.
La domanda da farsi prima di accendere due agenti
La domanda da farsi prima di accendere due agenti è una sola: avete davvero due lavori separati, o un lavoro solo che vorreste fosse più veloce. Nel secondo caso una squadra di agenti vi darà due versioni dello stesso errore, e con il doppio dei token: su come tenerli sotto controllo ho scritto in ridurre i token di un agente di coding. Un progetto come OpenRig su GitHub resta interessante anche per chi risponde così, perché mette un nome e una sintassi a una cosa che molti stanno già facendo a mano con due terminali aperti.
Chi sta valutando la stessa cosa dentro un processo aziendale invece che dentro un repository trova il ragionamento completo nella pagina sugli agenti AI su misura per le aziende, e la parte sul contesto condiviso in quanto conta la memoria di un agente AI.
Domande frequenti
Come funzionano gli agenti AI quando lavorano in squadra?
Gli agenti AI in squadra non condividono una memoria comune: ognuno ha la propria finestra di contesto e vede solo quello che gli viene passato. Il coordinamento si fa in due modi, con messaggi espliciti da un agente all'altro oppure con un artefatto condiviso che tutti leggono, tipicamente il repository. Il secondo modo è più lento e molto più affidabile, perché lascia una traccia che si può leggere anche il giorno dopo.
Che differenza c'è fra un subagent e un agente dentro un rig?
Un subagent nasce e muore dentro la sessione dell'agente che lo ha chiamato, e restituisce solo il risultato finale a chi lo ha lanciato. Un agente dentro un rig è un processo separato con una propria sessione, che resta acceso fra un compito e l'altro e può ricevere messaggi da chiunque nella topologia. Il subagent serve a non sporcare un contesto, il secondo serve a tenere in piedi un ruolo nel tempo.
Serve tmux per far girare più agenti di coding insieme?
Per OpenRig sì: il README elenca tmux fra i requisiti obbligatori, insieme a Node.js 20, 22 o 24, mentre Docker resta opzionale e serve solo ai rig che tirano su servizi. Il motivo è che ogni posto della squadra diventa una sessione tmux vera, che si può aprire e guardare. Far girare più agenti di coding insieme senza tmux è possibile, ma allora il coordinamento lo dovete scrivere voi da qualche altra parte.
Due agenti di coding sullo stesso repository si possono sovrascrivere a vicenda?
Sì, e va messo in conto prima di partire. Due agenti che scrivono sugli stessi file si sovrascrivono esattamente come farebbero due persone che lavorano senza branch, perché nessuno dei due vede la modifica dell'altro finché non è già sul disco. Le due difese pratiche sono dividere il lavoro per cartella oppure dare a ciascuno un ramo git suo, con un momento di unione dichiarato. Entrambe sono decisioni di progetto, non impostazioni da attivare.