Hai appena avviato un secondo agente Claude Code. Ora hai un problema.

Il primo agente e a meta di un refactoring. Il secondo deve costruire una funzionalita che tocca alcuni degli stessi file. Nessuno dei due sa che l'altro esiste. Tu sei il router, lo state store e il risolutore di conflitti, tutto contemporaneamente, e il tuo unico strumento e fare copia-incolla di contesto tra le finestre del terminale.

E qui che la maggior parte degli sviluppatori sbatte contro il muro con Claude Code. Non perche l'agente programma male. Perche non c'e un sistema che gli dica su cosa lavorare.

Il problema del copia-incolla

La maggior parte dei workflow Claude Code inizia allo stesso modo. Hai un task in testa (o in Jira, o in una issue GitHub), e incolli la descrizione nel prompt dell'agente. "Costruisci un flusso di autenticazione." "Correggi il bug della paginazione." "Aggiungi il supporto per la modalita scura."

Per un singolo agente, funziona bene. L'agente ha tutto il contesto, puoi osservare il suo output, e sai quando ha finito perche lo stai guardando.

Aggiungi un secondo agente e le crepe appaiono immediatamente.

L'Agente A sta refactorizzando il livello API. L'Agente B sta costruendo un nuovo endpoint. Entrambi toccano server/routes.ts. Nessuno sa delle modifiche dell'altro. Scopri il conflitto quando uno fa push e il lavoro dell'altro si rompe. O peggio: entrambi hanno successo localmente ma il risultato unito e rotto in modi che nessun diff rivela.

La causa radice non e che gli agenti sono sciatti. E l'assenza di stato condiviso. Non c'e un posto dove "l'Agente A e responsabile del refactoring API" sia registrato. Non c'e uno stato che dica "il file delle route e in fase di modifica, aspetta il tuo turno." Gli agenti operano su prompt individuali con zero consapevolezza del quadro generale.

Aggiungi un terzo agente e passi piu tempo a coordinare che a programmare.

Cosa serve davvero agli agenti da un sistema di task

Prima di cercare uno strumento, vale la pena chiedersi: di cosa ha realmente bisogno un agente Claude Code per fare un buon lavoro?

Di sorprendentemente poco.

Un identificatore unico. Qualcosa che possa referenziare nei commit e nei commenti. "Corretto il bug" e inutile in un log multi-agente. "Completato PROJ-47: la paginazione restituisce un conteggio sbagliato nelle viste filtrate" e tracciabile.

Un ambito chiaro. Titolo, descrizione e criteri di accettazione. Non un romanzo. Non una user story con personas. Una dichiarazione concreta di come appare "fatto." "L'endpoint /users restituisce risultati paginati. La dimensione della pagina e 25 per default. Il campo next_cursor e null nell'ultima pagina."

Uno stato che possa aggiornare. L'agente deve poter segnalare dove si trova: reclamato, in corso, fatto. Senza questo, torni a sbirciare nelle finestre del terminale e a tirare a indovinare.

Consapevolezza delle dipendenze. "Non iniziare questo finche PROJ-46 non e stato mergiato" previene il fallimento multi-agente piu comune: costruire su codice che non esiste ancora.

Nota cosa manca in questa lista. Pianificazione degli sprint. Tracciamento della velocity. Board Kanban. Story point. Epic con etichette colorate. Gli agenti non hanno bisogno di teatro di project management. Hanno bisogno di un task, uno stato e un modo per dire "ho finito."

Il contratto CLAUDE.md

Il sistema di task dice agli agenti su cosa lavorare. Il file CLAUDE.md dice loro come lavorare.

Se stai eseguendo piu agenti Claude Code, ciascuno dovrebbe avere un CLAUDE.md che definisce la sua identita e i suoi confini. Non e configurazione opzionale. E la differenza tra agenti che si coordinano e agenti che si pestano i piedi.

Ecco un esempio semplificato per un agente di ingegneria:

## Identity

Engineer for the project. You implement features, fix bugs,
and write tests. You own implementation quality.

## What You Own

- All files under `components/` and `lib/`
- Unit tests in `__tests__/`
- You may read but not modify files under `server/`

## What You Don't Own

- Deployment configuration (that's ops)
- Issue triage and prioritization (that's the coordinator)
- QA validation (QA tests your work independently)

## Completion Protocol

Before marking any task done:
1. Run the full test suite: `pnpm test`
2. Verify your change works manually
3. Comment what you did with the commit hash
4. Push before reporting completion

La sezione dei confini e la parte portante. Senza ownership esplicita dei file, gli agenti vagano. Un agente di ingegneria refactorizza "gentilmente" la configurazione di deployment. Un agente QA "corregge" un test cambiando il codice sotto test invece del test stesso. I confini espliciti prevengono queste modalita di fallimento.

Il protocollo di completamento conta altrettanto. Previene il fallimento d'agente piu comune: dichiarare qualcosa come fatto quando semplicemente compila. "Esegui la suite di test completa" e "verifica manualmente" sono gate concreti. Un agente che segue questo protocollo produce lavoro di cui un umano puo fidarsi. Un agente senza produce lavoro che devi ricontrollare riga per riga.

Scala questo su piu agenti e ottieni una flotta dove ogni membro conosce la sua corsia, il suo protocollo di passaggio e cosa significa "fatto."

Gestione dei task CLI-first

Ecco un'osservazione sul workflow che mi ha richiesto piu tempo del dovuto per interiorizzare: gli agenti Claude Code lavorano drasticamente meglio con strumenti CLI che con interfacce GUI.

Ha senso pensandoci. Un agente Claude Code vive nel terminale. Puo eseguire comandi, leggere output e intraprendere azioni basate sui risultati. Chiedergli di navigare una UI web, cliccare bottoni e interpretare pagine renderizzate e combattere l'interfaccia naturale dell'agente.

Un sistema di task basato su CLI significa che l'agente puo fare tutto questo in un singolo flusso:

# Read the task
task show PROJ-47

# Claim it
task update PROJ-47 --status in_progress --assignee agent-1

# Do the work...

# Report completion
task comment PROJ-47 "DONE: Fixed pagination. Commit: abc1234"
task update PROJ-47 --status done

Niente cambio di contesto. Niente finestre del browser. Niente screenshot di un board Kanban. L'agente legge un task, fa il lavoro e aggiorna lo stato, tutto senza lasciare l'ambiente in cui opera.

L'output e anche leggibile dalle macchine. Quando devi controllare cosa sta succedendo tra gli agenti, puoi interrogare:

task list --status in_progress    # What's being worked on?
task list --assignee agent-2      # What is agent-2 doing?
task list --blocked               # What's stuck?

Questa e la forma del tooling che funziona. Un CLI che parla la lingua dell'agente.

Beads: issue tracking local-first per agenti

Il workflow che ho descritto sopra non e ipotetico. E quello che uso ogni giorno con beads, un issue tracker open-source e local-first costruito esattamente per questo tipo di sviluppo guidato da agenti.

beads memorizza le issue (chiamate "beads") in un database Dolt locale accanto alla tua codebase. Ogni bead ha un ID, titolo, descrizione, stato, priorita, dipendenze e un thread di commenti. Il CLI si chiama bd, ed e l'interfaccia che gli agenti usano per leggere task, aggiornare stati e lasciare commenti strutturati.

Ecco un workflow reale. Creo un task:

bd create --title "Fix pagination on filtered views" \
  --description "The /users endpoint returns wrong count when filters are applied. Page size defaults to 25. next_cursor should be null on the last page." \
  --priority p2

Un agente lo reclama:

bd update bb-r3k2 --claim --actor eng1
bd update bb-r3k2 --status in_progress

Prima di scrivere qualsiasi codice, l'agente commenta il suo piano:

bd comments add bb-r3k2 --author eng1 "PLAN:
1. Fix count query in /users to apply filters before COUNT()
2. Add cursor boundary check for last page
3. Add test cases for filtered pagination

Files:
- server/routes/users.ts - fix count query
- server/routes/users.test.ts - add filtered pagination tests"

Questo e un checkpoint. Se il piano e sbagliato, lo individui in 30 secondi invece di scoprire una cattiva implementazione 45 minuti dopo.

L'agente fa il lavoro, esegue i test, poi commenta il completamento:

bd comments add bb-r3k2 --author eng1 "DONE: Fixed filtered pagination count.

- COUNT() now applies the same WHERE clause as the data query
- next_cursor returns null when offset + page_size >= total_count
- Added 4 test cases covering filtered + unfiltered pagination

Commit: a1b2c3d"

bd update bb-r3k2 --status ready_for_qa

Il task ora ha una pista di audit completa: cosa e stato richiesto, cosa ha pianificato l'agente, cosa ha effettivamente fatto, e l'hash del commit da revisionare. Un secondo agente che esegue QA puo prenderlo e verificare indipendentemente.

Funziona perche beads parla la stessa lingua degli agenti. Tutto e un comando CLI. Tutto produce output strutturato. Non c'e impedance mismatch tra lo strumento e l'agente.

Vedere il quadro generale

Il workflow CLI scala fino a 3 o 4 agenti prima di raggiungere un nuovo tetto. Non un tetto di strumenti. Uno cognitivo.

A 5 agenti, eseguire bd list e assemblare mentalmente lo stato del progetto e come leggere un foglio di calcolo e cercare di tenere un grafo delle dipendenze nella testa. Quali task sono bloccati? Quale agente non ha aggiornato il suo stato da 20 minuti? L'epic della funzionalita e al 60% o all'80%? L'informazione e tutta li nell'output CLI, ma metterla insieme richiede uno sforzo che si accumula con ogni agente aggiuntivo.

Qui si inserisce Beadbox. E una dashboard in tempo reale che si appoggia su beads e ti mostra lo stato dell'intera flotta di agenti. Alberi di dipendenze renderizzati visivamente. Barre di progresso degli epic. Thread di commenti degli agenti che puoi scansionare senza eseguire cinque comandi bd show.

Beadbox non sostituisce il CLI. Gli agenti continuano a usare bd per tutto. Beadbox e il livello che apri quando hai bisogno del quadro generale: quali flussi di lavoro si muovono, quali sono bloccati e dove sono i colli di bottiglia. Monitora il database beads per i cambiamenti e si aggiorna in tempo reale, quindi non guardi mai dati obsoleti.

E gratuito durante la beta e gira interamente sulla tua macchina. Nessun account, nessun cloud, i tuoi dati restano locali.

Per iniziare

Non servono 13 agenti per ottenere valore dalla gestione strutturata dei task. Inizia con due agenti Claude Code e una regola: ogni task ottiene un bead, ogni agente commenta il suo piano prima di programmare, ogni completamento include passi di verifica.

Il pattern si compone. Una volta che gli agenti hanno un sistema di task condiviso, puoi aggiungere agenti QA che verificano il lavoro indipendentemente. Puoi aggiungere un coordinatore che assegna task da una coda di priorita. Puoi scalare a 5, 10, 15 agenti senza che l'overhead di coordinamento cresca linearmente, perche i protocolli gestiscono cio che prima era cambio di contesto manuale.

Gli strumenti:

beads per la gestione task local-first. Open source.
Claude Code come runtime per agenti.
Beadbox per la supervisione visiva quando la flotta cresce.

Se stai costruendo workflow come questo, metti una stella a Beadbox su GitHub.

Come gestire i task per gli agenti Claude Code