Agent Teams.
Una vera squadra tech, scriptata.

I subagents di Claude sono delegazioni inline da una singola sessione Claude genitore. Il genitore decide quando chiamare un subagent, il subagent gira in una context window isolata, restituisce un risultato e il genitore prosegue. AgentsRoom Teams e un livello sopra: ogni nodo e una sessione Claude Code top-level con il suo terminale, il suo stato e il suo scrollback. Vedi ogni agente girare live nella sua tab, puoi parlarci in qualsiasi momento, puoi mettere in pausa il team, cambiare il workflow e riprendere. Non e un rimpiazzo dei subagents Claude, puoi assolutamente usare entrambi. Un nodo del team puo usare subagents internamente.

Funziona con tutte le 14 CLI di agenti supportate da AgentsRoom (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor e altre 10). Ogni nodo del team sceglie il proprio provider e modello. I tool di coordinamento del team basati su MCP funzionano in modo identico tra provider perche sono esposti tramite il Model Context Protocol standard. Puoi eseguire un team con Codex sul nodo backend pesante e Haiku sul nodo QA se questo e cio che si adatta al tuo budget e alla tua latenza.

Un oggetto strutturato che viaggia da un agente al successivo. Campi: featureSummary (una breve descrizione di cio che e appena stato rilasciato), changedFiles (git diff name-status), touchedAreas (UI, API, DB, config), risks (qualsiasi cosa di cui il prossimo agente debba preoccuparsi), testHints (priorita per il QA), flags (boolean come qaPassed, usati dagli edge condizionali). L'agente chiama team_complete_step con questo payload, il runner lo valida server-side, l'agente successivo lo riceve come contesto iniziale.

Si. Quando un nodo viene rientrato (ciclo maggiore di 1), AgentsRoom non avvia un nuovo agente. Riutilizza l'agente originale del ciclo 1, scrive il nuovo payload di handoff direttamente nel suo terminale esistente, e l'agente mantiene la sua memoria completa della sessione Claude dei cicli precedenti. Questo e critico: un agente Dev che sa gia cosa il QA ha segnalato l'ultima volta corregge il bug. Un agente Dev fresco senza memoria ripeterebbe lo stesso errore.

La config del team ha un max-cycles guard, default 3. Quando si raggiunge il cap, il run si mette in pausa con stato 'blocked' e ti aspetta. Puoi finalizzare il run, fare manualmente un altro handoff, o cancellare tutto. Niente loop infiniti, niente fatture a sorpresa nottetempo.

Si. Il team gira in un singolo workspace e su un singolo branch (o worktree se usi la feature AgentsRoom Worktrees). Ogni agente vede il lavoro del precedente attraverso git. Il payload di handoff include un git diff rispetto alla baseline del run cosi il prossimo agente sa esattamente cosa e nuovo.

No. I Teams fanno parte di AgentsRoom. Porti le tue chiavi provider (Claude, Codex, GitHub Copilot CLI, Cursor e altre 10 CLI di agenti) e paghi solo i token che usi, come con un singolo agente. Eseguire un team Dev verso QA su un piccolo ticket costa tipicamente come eseguire un singolo agente Fullstack, perche Haiku/Sonnet sullo step QA e economico.

I team di progetto vivono con la room, sincronizzati con il tuo account e in cache in {project}/.agentsroom/teams-cache.json (gitignored). Anche i team globali sono sincronizzati con il tuo account: la tua libreria ti segue da una macchina all'altra, con ~/.agentsroom/teams/ come cache offline. I modelli inclusi restano locali: ogni macchina li installa nella propria lingua.

Lo stato dell'esecuzione e persistito su disco in {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), con scritture atomiche e note append-only. Un'esecuzione interrotta riprende al riavvio dell'app: l'orchestratore rientra nel passo attivo, riapre il terminale e l'agente recupera il contesto dalle note e dagli strumenti del team. Un'esecuzione il cui team e stato eliminato viene chiusa automaticamente invece di restare li per sempre.

Si. Ogni esecuzione e indipendente, identificata dal suo runId. Puoi avere tre team diversi attivi su tre ticket dello stesso progetto. Dentro una singola esecuzione, il flusso segue il tuo grafo: sequenziale di default, parallelo dove disegni rami paralleli (per esempio QA e Security che rivedono insieme), sempre con una giunzione deterministica.

Si. Traccia due collegamenti senza condizione da un nodo e le due destinazioni girano come rami paralleli, ciascuno nel proprio agente e terminale. I rami sono profondi un nodo e devono convergere su un nodo di giunzione comune, che l'editor valida prima di lasciarti lanciare. Quando ogni ramo ha finito, la giunzione riceve un payload fuso: riepiloghi etichettati per ruolo, rischi e suggerimenti di test deduplicati, e flag fusi con una regola fail-safe (un conflitto booleano si risolve a false).

Scrivi un comando shell sul nodo, per esempio npm test, e se vuoi un nome di flag (checkPassed di default). Quando l'agente segnala la fine del passo, AgentsRoom esegue il comando nel workspace con un tetto di cinque minuti. Exit code 0 scrive true nel flag, qualsiasi altro scrive false, sovrascrivendo cio che l'agente ha dichiarato su di se. In caso di fallimento, gli ultimi kilobyte di output viaggiano verso l'agente successivo: il ritorno indietro atterra con il vero stack trace, e il risultato compare nella timeline dell'esecuzione.

Si. Ogni nodo puo fissare skill della tua Skills Library, di progetto o globali. L'agente riceve l'istruzione di caricarle prima di iniziare il passo: una checklist di review, un runbook di deploy o una procedura di test viene applicata a ogni singola esecuzione, invece di dipendere dalla memoria dell'agente.

Sì. L'editor esegue una serie di controlli sul grafo e separa gli errori bloccanti dagli avvisi. Gli errori fermano l'esecuzione: un nodo Start o End mancante, connessioni duplicate, due connessioni con le stesse condizioni, una connessione le cui condizioni si contraddicono, un fan-out non valido. Gli avvisi no: un nome di flag con spazi all'inizio o alla fine, una condizione su una connessione che esce da Start, un nodo le cui connessioni uscenti sono tutte condizionali, dove l'esecuzione può fermarsi. Entrambi sono elencati in un pannello di controlli e le connessioni colpevoli vengono ricolorate sul canvas, così correggi il grafo prima di perderci un'esecuzione.

No, ed è voluto. Finché un'esecuzione è attiva, la definizione del team è congelata rispetto alle scritture che arrivano dagli strumenti MCP: nodi, collegamenti, numero massimo di cicli, istruzioni di passo, skill, comando di controllo, ruolo, provider e modello sono in sola lettura per gli agenti, nemmeno una skill caricata dall'esecuzione può essere riscritta, e il blocco non si aggira eliminando e ricreando il team. Un agente non deve riscrivere la regola che lo governa. Tu continui a modificare tutto dall'interfaccia in qualsiasi momento.

Sì. L'app mobile può avviare un team su un progetto, mostra un banner di esecuzione con l'avanzamento di ogni passo e dà accesso al terminale dell'agente che sta lavorando in quel momento. L'esecuzione vera e propria gira comunque sul tuo desktop, con le CLI reali, esattamente come se l'avessi lanciata da lì.

Chiediti su cosa fallirebbe il run. Se fallirebbe perdendo il filo, scegli la staffetta: una sola sessione interpreta ogni ruolo e non si rispiega mai una decisione. Se fallirebbe dandosi ragione da sola, scegli il team: i ruoli girano come agenti separati, quindi chi rivede il codice non è chi l'ha scritto. La staffetta è l'impostazione predefinita perché è già ciò che fa ogni team costruito prima che l'opzione esistesse, non perché sia migliore.

No. Un compagno parte la prima volta che serve, perché il grafo raggiunge il suo passo o perché un altro agente gli scrive, e da lì resta vivo per il resto del run. Così un team di quattro ruoli non brucia quattro sessioni per rispondere a una domanda che ne riguarda solo due, e un ruolo interpellato al terzo ciclo è ancora lo stesso agente che ha risposto al primo.

Solo quello che può leggere. Un compagno che entra a run avviato ha la sua sessione e nessun ricordo del lavoro, ed è esattamente per questo che il suo parere vale qualcosa. Si mette in pari con le note condivise, la timeline del run e il diff git dall'inizio del run, e legge tutto con i suoi strumenti. Quella lettura è il costo della modalità, ed è il motivo per cui la modalità staffetta esiste ancora.

Sì, ed è il comportamento predefinito. Con la conversazione libera disattivata, un compagno può scrivere solo ai ruoli verso cui punta il suo nodo nel grafo, quindi un quality gate non si aggira chiedendo a qualcun altro. Attivala quando vuoi una squadra vera: chiunque scrive a chiunque, in qualsiasi direzione e a più ruoli insieme. In entrambi i casi il grafo continua ad avviare il run e a chiuderlo.