Hai lanciato sei agenti Claude Code su diversi pannelli tmux. Ognuno ha preso in carico un task. Stanno tutti producendo output, scrollando più velocemente di quanto tu riesca a leggere. Uno ha appena fatto un commit. Un altro sta eseguendo i test. Un terzo è sospettosamente silenzioso da 20 minuti.
Non hai idea di cosa stia realmente succedendo.
Questo è il problema centrale dei workflow con agenti in parallelo. Gli agenti di per sé 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 agenti non ha una vista aggregata. Ti ritrovi a saltare tra pannelli tmux, scrollare la cronologia del terminale e ricostruire lo stato del progetto a mente.
Con due agenti funziona. A cinque crolla tutto.
Come gli agenti registrano il lavoro tramite beads
La base è beads, un issue tracker open-source Git-native pensato esattamente per questo workflow. beads offre agli agenti un modo strutturato per registrare quello che 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, esattamente come 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 è bloccato, cosa è appena finito, cosa è disponibile. L'informazione esiste. Il problema è vederla.
Cosa bd list non può 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 progetto, esegui bd list, poi bd show su qualche issue, poi bd dep list per capire cosa blocca cosa, poi bd blocked per trovare agenti in stallo. Ricostruisci il quadro a mano.
Quando gli agenti si muovono velocemente (tre issue chiuse in 90 secondi, ognuna che sblocca lavoro downstream diverso), la CLI non tiene il passo col ritmo dei cambiamenti. Prima che tu finisca di leggere bd blocked, due di quei blocchi si sono già risolti.
Cosa ti mostra Beadbox
Beadbox è un'app desktop nativa che monitora la directory .beads/ e renderizza l'intero stato del progetto in tempo reale. Quando un agente esegue bd update in un terminale, Beadbox rileva la modifica sul filesystem e la invia alla UI via WebSocket in pochi millisecondi. Nessun polling. Nessun pulsante di refresh. Niente più salti tra pannelli tmux per capire chi ha fatto cosa.
Ecco cosa ti dà concretamente:
Alberi di avanzamento delle epic. La tua feature di primo livello mostra 7 su 12 sotto-task completati. Espandila e vedi quali sono in corso (e quale agente li ha in carico), quali sono bloccati, quali sono appena diventati disponibili. Un colpo d'occhio sostituisce una dozzina di comandi bd show.
Badge delle dipendenze su ogni issue. Vedi subito che bb-q3l è in attesa di bb-f8o senza eseguire un singolo comando. Quando bb-f8o si chiude, bb-q3l si illumina come sbloccata. La cascata è visibile nel momento in cui accade.
Evidenziazione dei task bloccati. Ogni issue bloccata emerge con le dipendenze bloccanti elencate inline. Non devi andare a caccia di blocchi: sono sullo schermo, ordinati per priorità, nel momento stesso in cui compaiono.
Cambio multi-workspace. Se gestisci agenti su più progetti, passi 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. Propagazione sotto il secondo: vedi l'attività degli agenti nel momento in cui accade, non con un intervallo di polling di 30 secondi.
Il workflow di monitoraggio
Con Beadbox aperto accanto alla sessione tmux, il monitoraggio diventa riconoscimento di pattern invece che indagine attiva. Ecco cosa tenere d'occhio:
Task in-progress stagnanti. Un agente che ha preso in carico un task due ore fa senza aggiornarlo è probabilmente bloccato o crashato. In un workflow umano, due ore non significano nulla. Per un agente, un silenzio così lungo è un segnale d'allarme. Controlla il pannello tmux, dai un nudge all'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 è il tuo percorso critico. Ripriorizzala, assegnala all'agente più veloce o risolvila tu stesso.
False dipendenze. Gli agenti dichiarano troppe dipendenze durante la pianificazione. Modellano ciò di cui pensano di avere bisogno basandosi sulla lettura iniziale del codebase. Una volta che il lavoro parte, molte di quelle dipendenze si rivelano superflue. Quando noti un task bloccato la cui dipendenza sembra sbagliata, rimuovila:
bd dep remove bb-q3l bb-f8o
Quel singolo comando sblocca il task all'istante. In Beadbox, lo vedi passare da bloccato a disponibile in tempo reale.
Lavoro pronto senza assegnatario. Dopo una cascata di sblocchi, potresti ritrovarti cinque task improvvisamente disponibili senza nessun agente assegnato. Quello è il tuo momento di dispatch. Indirizza gli agenti liberi verso il lavoro pronto a priorità più alta.
Il ciclo di triage è semplice: cerca i blocchi, risolvili o riassegna, cerca il lavoro pronto, assegnalo. Beadbox rende ogni passaggio un colpo d'occhio invece di una sequenza di comandi CLI.
Perché conta su larga scala
Due agenti, puoi supervisionarli guardando i terminali. Tre o quattro, inizi a perdere il filo. A sei o dieci, ti serve strumentazione.
Gli agenti non sono il collo di bottiglia. Claude Code è veloce. Scrive codice, esegue test e itera sugli errori senza aspettare te. Il collo di bottiglia è la capacità del supervisore di vedere l'intero quadro: quali agenti sono produttivi, quali sono bloccati, dove corre il percorso critico, cosa si è appena liberato.
Una dashboard visuale in tempo reale trasforma tutto da un'indagine (esegui cinque comandi, leggi l'output, tieni lo stato a mente) in una scansione (guarda lo schermo). Quella differenza si accumula nell'arco di un'intera giornata di coordinamento parallelo.
Per iniziare
Installa Beadbox con Homebrew:
brew tap beadbox/cask && brew install --cask beadbox
Se i tuoi agenti usano già beads, Beadbox rileva automaticamente i workspace .beads/ esistenti. Apri l'app e le tue issue sono lì. Nessuna importazione, nessun 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 ciò che fanno nel momento in cui lo fanno.
Beadbox funziona su macOS, Linux e Windows. È gratis durante la beta.
