Come monitorare piu agenti Claude Code che lavorano in parallelo

Hai avviato sei agenti Claude Code su diversi pannelli tmux. Ognuno ha preso in carico un task. Stanno tutti producendo output, scorrendo piu velocemente di quanto tu riesca a leggere. Uno ha appena fatto un commit. Un altro sta eseguendo i test. Un terzo e sospettosamente silenzioso da 20 minuti.

Non hai idea di cosa stia realmente succedendo.

Questo e il problema centrale dei workflow con agenti in parallelo. Gli agenti di per se sono produttivi. Claude Code sa prendere in carico il lavoro, scrivere codice, eseguire test e segnalare il completamento tramite comandi strutturati. Ma l'umano che supervisiona sei o dieci di questi agenti non ha una vista aggregata. Ti ritrovi a passare tra i pannelli tmux, scorrere la cronologia del terminale e ricostruire lo stato del progetto nella tua testa.

Funziona con due agenti. Crolla a cinque.

Come gli agenti registrano il lavoro tramite beads

La base e beads, un issue tracker open-source Git-native pensato esattamente per questo workflow. beads offre agli agenti un modo strutturato per registrare cosa stanno facendo e a te un modo strutturato per interrogarlo. Ogni azione dell'agente diventa un comando CLI che scrive su un database locale.

Quando un agente prende in carico il lavoro:

bd update bb-f8o --status in_progress --assignee agent-3

Quando scopre un prerequisito e crea una nuova issue:

BLOCKER=$(bd create \
  --title "Auth middleware needs rate limiting before deploy" \
  --type task --priority 1 --json | jq -r '.id')

bd dep add bb-f8o "$BLOCKER"

Quando finisce:

bd update bb-f8o --status closed
bd comments add bb-f8o --author agent-3 \
  "DONE: Implemented request throttling. Commit: a1c9e4f"

Ognuno di questi comandi richiede millisecondi. Ognuno scrive sullo stesso database locale. Gli agenti non hanno bisogno di token API, client HTTP o flussi di autenticazione. Eseguono comandi shell, allo stesso modo in cui eseguono git commit o npm test.

Dopo qualche ora di lavoro in parallelo, quel database contiene il quadro completo: chi sta lavorando su cosa, cosa e bloccato, cosa e appena terminato e cosa e disponibile. L'informazione esiste. Il problema e vederla.

Cosa bd list non puo mostrarti

Puoi interrogare il database dal terminale:

bd list --status=in_progress
bd blocked
bd ready

Ognuno di questi comandi restituisce dati utili. Ma li restituisce come testo piatto, un'istantanea alla volta. Per capire lo stato del tuo progetto, esegui bd list, poi bd show su alcune issue, poi bd dep list per vedere cosa blocca cosa, poi bd blocked per trovare agenti in stallo. Ricostruisci il quadro manualmente.

Quando gli agenti si muovono velocemente (chiudendo tre issue in 90 secondi, ognuna che sblocca lavoro downstream diverso), la CLI non riesce a stare al passo con il ritmo dei cambiamenti. Prima che tu finisca di leggere bd blocked, due di quei blocchi si sono gia risolti.

Cosa ti mostra Beadbox

Beadbox e un'app desktop nativa che monitora la tua directory .beads/ e renderizza l'intero stato del progetto in tempo reale. Quando un agente esegue bd update in un terminale, Beadbox intercetta la modifica del filesystem e la invia alla UI via WebSocket in pochi millisecondi. Nessun polling. Nessun pulsante di refresh. Nessuna necessita di passare tra i pannelli tmux per capire chi ha fatto cosa.

Ecco cosa ti offre concretamente:

Alberi di avanzamento delle epic. La tua feature di primo livello mostra 7 su 12 sotto-task completati. Espandila e vedi quali sotto-task sono in corso (e quale agente possiede ciascuno), quali sono bloccati e quali sono appena diventati disponibili. Un solo sguardo sostituisce una dozzina di comandi bd show.

Badge delle dipendenze su ogni issue. Vedi immediatamente che bb-q3l sta aspettando bb-f8o senza eseguire un singolo comando. Quando bb-f8o si chiude, bb-q3l si illumina come sbloccata. La cascata e visibile nel momento in cui accade.

Evidenziazione dei task bloccati. Ogni issue bloccata emerge con le sue dipendenze bloccanti elencate inline. Non vai a caccia di blocchi. Sono sullo schermo, ordinati per priorita, nel momento stesso in cui esistono.

Cambio multi-workspace. Se stai gestendo agenti su piu progetti, passa da un database beads all'altro con un menu a tendina. Ogni workspace ricorda i propri filtri e lo stato della visualizzazione.

Sincronizzazione in tempo reale. La pipeline di aggiornamento usa fs.watch sulla directory .beads/, inviata via WebSocket alla UI React. La propagazione in meno di un secondo significa che vedi l'attivita degli agenti nel momento in cui accade, non su un intervallo di polling di 30 secondi.

Il workflow di monitoraggio

Una volta che Beadbox e aperto accanto alla tua sessione tmux, il monitoraggio diventa riconoscimento di pattern invece di indagine attiva. Ecco cosa tenere d'occhio:

Task in-progress stantii. Un agente che ha preso in carico un task due ore fa e non l'ha aggiornato e probabilmente bloccato o crashato. In un workflow umano, due ore non significano nulla. Per un agente, un silenzio cosi lungo e un segnale d'allarme. Controlla il pannello tmux, stimola l'agente o riassegna il lavoro.

Accumulo di task bloccati. Se i task bloccati iniziano ad accumularsi e puntano tutti alla stessa dipendenza non risolta, quella dipendenza e il tuo percorso critico. Ripriorizzala, assegnala al tuo agente piu veloce o risolvila tu stesso.

False dipendenze. Gli agenti dichiarano troppe dipendenze durante la pianificazione. Modellano cio di cui pensano avranno bisogno basandosi sulla loro lettura iniziale del codebase. Una volta che il lavoro inizia, molte di quelle dipendenze risultano inutili. Quando noti un task bloccato la cui dipendenza sembra sbagliata, rimuovila:

bd dep remove bb-q3l bb-f8o

Quel singolo comando sblocca istantaneamente il task. In Beadbox, lo vedi passare da bloccato a disponibile in tempo reale.

Lavoro pronto senza assegnatario. Dopo una cascata di sblocchi, potresti avere cinque task improvvisamente disponibili senza nessun agente assegnato. Quello e il tuo momento di dispatch. Indirizza gli agenti liberi sul lavoro pronto a priorita piu alta.

Il ciclo di triage e semplice: scansiona i blocchi, risolvili o riassegna, scansiona il lavoro pronto, assegnalo. Beadbox rende ogni scansione un colpo d'occhio invece di una sequenza di comandi CLI.

Perche questo conta su larga scala

Due agenti, puoi supervisionarli guardando i terminali. Tre o quattro, inizi a perdere il filo. A sei o dieci, hai bisogno di strumentazione.

Gli agenti stessi non sono il collo di bottiglia. Claude Code e veloce. Scrive codice, esegue test e itera sui fallimenti senza aspettarti. Il collo di bottiglia e la capacita del supervisore di vedere l'intero quadro: quali agenti sono produttivi, quali sono bloccati, dove passa il percorso critico e cosa si e appena liberato.

Una dashboard visuale in tempo reale trasforma tutto questo da un'indagine (esegui cinque comandi, leggi l'output, tieni lo stato in testa) in una scansione (guarda lo schermo). Quella differenza si accumula nell'arco di un'intera giornata di lavoro con agenti coordinati in parallelo.

Per iniziare

Installa Beadbox con Homebrew:

brew tap beadbox/cask && brew install --cask beadbox

Se i tuoi agenti usano gia beads, Beadbox rileva automaticamente i workspace .beads/ esistenti. Apri l'app e le tue issue sono li. Nessun passaggio di importazione, nessuna creazione di account, nessuna sincronizzazione cloud. I tuoi dati restano sulla tua macchina.

Se sei nuovo a beads, installa la CLI (go install github.com/steveyegge/beads/cmd/bd@latest), esegui bd init nel tuo progetto e inizia ad assegnare lavoro ai tuoi agenti. Beadbox mostra tutto cio che fanno nel momento in cui lo fanno.

Beadbox funziona su macOS, Linux e Windows. E gratis durante la beta.