Voce iniciou seis agentes Claude Code em paineis tmux. Cada um reivindicou uma tarefa. Todos estao produzindo saida, scrollando mais rapido do que voce consegue ler. Um acabou de fazer commit de algo. Outro esta rodando testes. Um terceiro esta suspeitosamente quieto ha 20 minutos.

Voce nao faz ideia do que esta realmente acontecendo.

Esse e o problema central dos workflows de agentes em paralelo. Os agentes em si sao produtivos. Claude Code consegue reivindicar trabalho, escrever codigo, rodar testes e reportar conclusao por comandos estruturados. Mas o humano que supervisiona seis ou dez desses agentes nao tem uma visao agregada. Voce fica alternando entre paineis tmux, rolando o historico do terminal e reconstruindo o estado do projeto na sua cabeca.

Isso funciona com dois agentes. Desmorona com cinco.

Como agentes reportam trabalho pelo beads

A base e o beads, um issue tracker open-source e Git-native construido exatamente para esse workflow. beads da aos agentes uma forma estruturada de registrar o que estao fazendo, e da a voce uma forma estruturada de consultar. Cada acao do agente vira um comando CLI que escreve em um banco de dados local.

Quando um agente pega trabalho:

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

Quando descobre um pre-requisito e cria um novo 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 finaliza:

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

Cada um desses comandos leva milissegundos. Cada um escreve no mesmo banco de dados local. Os agentes nao precisam de tokens de API, clientes HTTP ou fluxos de autenticacao. Eles rodam comandos shell, da mesma forma que rodam git commit ou npm test.

Apos algumas horas de trabalho paralelo, o banco de dados contem o quadro completo: quem esta trabalhando em que, o que esta bloqueado, o que acabou de ser concluido e o que esta disponivel. A informacao existe. O problema e visualiza-la.

O que `bd list` nao consegue mostrar

Voce pode consultar o banco de dados pelo terminal:

bd list --status=in_progress
bd blocked
bd ready

Cada um desses comandos retorna dados uteis. Mas eles retornam como texto plano, um snapshot por vez. Para entender o estado do seu projeto, voce roda bd list, depois bd show em alguns issues, depois bd dep list para ver o que esta bloqueando o que, depois bd blocked para encontrar agentes parados. Voce monta o quadro manualmente.

Quando agentes estao se movendo rapido (fechando tres issues em 90 segundos, cada um desbloqueando trabalho diferente a jusante), a CLI nao acompanha a velocidade das mudancas. Quando voce termina de ler bd blocked, dois daqueles bloqueios ja foram resolvidos.

O que o Beadbox mostra

Beadbox e um app desktop nativo que monitora seu diretorio .beads/ e renderiza o estado completo do projeto em tempo real. Quando um agente roda bd update no terminal, o Beadbox capta a mudanca no sistema de arquivos e a envia para a UI via WebSocket em milissegundos. Sem polling. Sem botao de refresh. Sem alternar entre paineis tmux para descobrir quem fez o que.

Veja o que isso proporciona concretamente:

Arvores de progresso de epics. Sua feature de nivel superior mostra 7 de 12 subtarefas completas. Expanda e veja quais subtarefas estao em andamento (e qual agente e dono de cada uma), quais estao bloqueadas e quais acabaram de ficar disponiveis. Um olhar substitui uma duzia de comandos bd show.

Badges de dependencia em cada issue. Voce ve instantaneamente que bb-q3l esta esperando por bb-f8o sem rodar nenhum comando. Quando bb-f8o fecha, bb-q3l aparece como desbloqueado. A cascata e visivel enquanto acontece.

Destaque de tarefas bloqueadas. Cada issue bloqueado aparece com suas dependencias listadas inline. Voce nao caca bloqueadores. Eles estao na tela, ordenados por prioridade, no momento em que existem.

Troca de workspace com multiplos projetos. Se voce roda agentes em multiplos projetos, troque entre bancos de dados beads por um dropdown. Cada workspace lembra seus proprios filtros e estado de visualizacao.

Sincronizacao em tempo real. O pipeline de atualizacao e fs.watch no diretorio .beads/, enviado via WebSocket para a UI React. Propagacao sub-segundo significa que voce ve a atividade dos agentes enquanto acontece, nao em intervalos de polling de 30 segundos.

O workflow de monitoramento

Quando o Beadbox esta aberto ao lado da sua sessao tmux, o monitoramento se torna reconhecimento de padroes ao inves de investigacao ativa. Veja o que observar:

Tarefas in-progress paradas. Um agente que reivindicou uma tarefa ha duas horas e nao a atualizou esta travado ou crashou. Em um workflow humano, duas horas nao significam nada. Para um agente, silencio por tanto tempo e um sinal de alerta. Verifique o painel tmux, de um nudge no agente ou reatribua o trabalho.

Acumulo de tarefas bloqueadas. Se tarefas bloqueadas comecam a se acumular e todas apontam para a mesma dependencia nao resolvida, essa dependencia e seu caminho critico. Repriorize-a, atribua ao seu agente mais rapido ou resolva voce mesmo.

Dependencias falsas. Agentes declaram dependencias em excesso durante o planejamento. Eles modelam o que acham que vao precisar com base na leitura inicial do codebase. Quando o trabalho comeca, muitas dessas dependencias se mostram desnecessarias. Quando voce identifica uma tarefa bloqueada cuja dependencia parece errada, remova-a:

bd dep remove bb-q3l bb-f8o

Esse unico comando desbloqueia a tarefa instantaneamente. No Beadbox, voce ve a transicao de bloqueado para disponivel em tempo real.

Trabalho pronto sem responsavel. Apos uma cascata de desbloqueios, voce pode ter cinco tarefas subitamente disponiveis sem agente atribuido. Esse e o momento de despacho. Direcione agentes ociosos para o trabalho pronto de maior prioridade.

O loop de triagem e simples: procure bloqueios, resolva ou reatribua, procure trabalho pronto, despache. O Beadbox transforma cada busca em um olhar ao inves de uma sequencia de comandos CLI.

Por que isso importa em escala

Dois agentes, voce supervisiona acompanhando terminais. Tres ou quatro, voce comeca a perder o fio. Com seis ou dez, voce precisa de instrumentacao.

Os agentes nao sao o gargalo. Claude Code e rapido. Ele escreve codigo, roda testes e itera sobre falhas sem esperar por voce. O gargalo e a capacidade do supervisor de ver o tabuleiro completo: quais agentes estao produtivos, quais estao travados, onde o caminho critico passa e o que acabou de abrir.

Um dashboard visual em tempo real converte isso de uma investigacao (rode cinco comandos, leia a saida, mantenha o estado na sua cabeca) em uma varredura (olhe para a tela). Essa diferenca se acumula ao longo de um dia inteiro de coordenacao de agentes em paralelo.

Comecando

Instale o Beadbox com Homebrew:

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

Se seus agentes ja usam beads, o Beadbox detecta workspaces .beads/ existentes automaticamente. Abra o app e seus issues estao la. Sem etapa de importacao, sem criacao de conta, sem sincronizacao na nuvem. Seus dados ficam na sua maquina.

Se voce e novo no beads, instale o CLI (go install github.com/steveyegge/beads/cmd/bd@latest), rode bd init no seu projeto e comece a despachar trabalho para seus agentes. O Beadbox mostra tudo que eles fazem no momento em que fazem.

Beadbox roda em macOS, Linux e Windows. Gratuito durante o beta.