Você iniciou seis agentes Claude Code em painéis tmux. Cada um reivindicou uma tarefa. Todos estão produzindo saída, scrollando mais rápido do que você consegue ler. Um acabou de fazer commit de algo. Outro está rodando testes. Um terceiro está suspeitosamente quieto há 20 minutos.

Você não faz ideia do que está realmente acontecendo.

Esse é o problema central dos workflows de agentes em paralelo. Os agentes em si são produtivos. Claude Code consegue reivindicar trabalho, escrever código, rodar testes e reportar conclusão por comandos estruturados. Mas o humano que supervisiona seis ou dez desses agentes não tem uma visão agregada. Você fica alternando entre painéis tmux, rolando o histórico do terminal e reconstruindo o estado do projeto na sua cabeça.

Isso funciona com dois agentes. Desmorona com cinco.

Como agentes reportam trabalho pelo beads

A base é o beads, um issue tracker open-source e Git-nativo construído exatamente para esse workflow. beads dá aos agentes uma forma estruturada de registrar o que estão fazendo, e dá a você uma forma estruturada de consultar. Cada ação 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 pré-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 não precisam de tokens de API, clientes HTTP ou fluxos de autenticação. Eles rodam comandos shell, da mesma forma que rodam git commit ou npm test.

Após algumas horas de trabalho paralelo, o banco de dados contém o quadro completo: quem está trabalhando em quê, o que está bloqueado, o que acabou de ser concluído e o que está disponível. A informação existe. O problema é visualizá-la.

O que `bd list` não consegue mostrar

Você pode consultar o banco de dados pelo terminal:

bd list --status=in_progress
bd blocked
bd ready

Cada um desses comandos retorna dados úteis. Mas eles retornam como texto plano, um snapshot por vez. Para entender o estado do seu projeto, você roda bd list, depois bd show em alguns issues, depois bd dep list para ver o que está bloqueando o quê, depois bd blocked para encontrar agentes parados. Você monta o quadro manualmente.

Quando agentes estão se movendo rápido (fechando três issues em 90 segundos, cada um desbloqueando trabalho diferente a jusante), a CLI não acompanha a velocidade das mudanças. Quando você termina de ler bd blocked, dois daqueles bloqueios já foram resolvidos.

O que o Beadbox mostra

Beadbox é um app desktop nativo que monitora seu diretório .beads/ e renderiza o estado completo do projeto em tempo real. Quando um agente roda bd update no terminal, o Beadbox capta a mudança no sistema de arquivos e a envia para a UI via WebSocket em milissegundos. Sem polling. Sem botão de refresh. Sem alternar entre painéis tmux para descobrir quem fez o quê.

Veja o que isso proporciona concretamente:

Árvores de progresso de épicos. Sua feature de nível superior mostra 7 de 12 subtarefas completas. Expanda e veja quais subtarefas estão em andamento (e qual agente é dono de cada uma), quais estão bloqueadas e quais acabaram de ficar disponíveis. Um olhar substitui uma dúzia de comandos bd show.

Badges de dependência em cada issue. Você vê instantaneamente que bb-q3l está esperando por bb-f8o sem rodar nenhum comando. Quando bb-f8o fecha, bb-q3l aparece como desbloqueado. A cascata é visível enquanto acontece.

Destaque de tarefas bloqueadas. Cada issue bloqueado aparece com suas dependências listadas inline. Você não caça bloqueadores. Eles estão na tela, ordenados por prioridade, no momento em que existem.

Troca de workspace com múltiplos projetos. Se você roda agentes em múltiplos projetos, troque entre bancos de dados beads por um dropdown. Cada workspace lembra seus próprios filtros e estado de visualização.

Sincronização em tempo real. O pipeline de atualização é fs.watch no diretório .beads/, enviado via WebSocket para a UI React. Propagação sub-segundo significa que você vê a atividade dos agentes enquanto acontece, não em intervalos de polling de 30 segundos.

O workflow de monitoramento

Quando o Beadbox está aberto ao lado da sua sessão tmux, o monitoramento se torna reconhecimento de padrões ao invés de investigação ativa. Veja o que observar:

Tarefas in-progress paradas. Um agente que reivindicou uma tarefa há duas horas e não a atualizou está travado ou crashou. Em um workflow humano, duas horas não significam nada. Para um agente, silêncio por tanto tempo é um sinal de alerta. Verifique o painel tmux, dê um nudge no agente ou reatribua o trabalho.

Acúmulo de tarefas bloqueadas. Se tarefas bloqueadas começam a se acumular e todas apontam para a mesma dependência não resolvida, essa dependência é seu caminho crítico. Repriorize-a, atribua ao seu agente mais rápido ou resolva você mesmo.

Dependências falsas. Agentes declaram dependências em excesso durante o planejamento. Eles modelam o que acham que vão precisar com base na leitura inicial do codebase. Quando o trabalho começa, muitas dessas dependências se mostram desnecessárias. Quando você identifica uma tarefa bloqueada cuja dependência parece errada, remova-a:

bd dep remove bb-q3l bb-f8o

Esse único comando desbloqueia a tarefa instantaneamente. No Beadbox, você vê a transição de bloqueado para disponível em tempo real.

Trabalho pronto sem responsável. Após uma cascata de desbloqueios, você pode ter cinco tarefas subitamente disponíveis sem agente atribuído. Esse é o momento de despacho. Direcione agentes ociosos para o trabalho pronto de maior prioridade.

O loop de triagem é simples: procure bloqueios, resolva ou reatribua, procure trabalho pronto, despache. O Beadbox transforma cada busca em um olhar ao invés de uma sequência de comandos CLI.

Por que isso importa em escala

Dois agentes, você supervisiona acompanhando terminais. Três ou quatro, você começa a perder o fio. Com seis ou dez, você precisa de instrumentação.

Os agentes não são o gargalo. Claude Code é rápido. Ele escreve código, roda testes e itera sobre falhas sem esperar por você. O gargalo é a capacidade do supervisor de ver o tabuleiro completo: quais agentes estão produtivos, quais estão travados, onde o caminho crítico passa e o que acabou de abrir.

Um dashboard visual em tempo real converte isso de uma investigação (rode cinco comandos, leia a saída, mantenha o estado na sua cabeça) em uma varredura (olhe para a tela). Essa diferença se acumula ao longo de um dia inteiro de coordenação de agentes em paralelo.

Começando

Instale o Beadbox com Homebrew:

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

Se seus agentes já usam beads, o Beadbox detecta workspaces .beads/ existentes automaticamente. Abra o app e seus issues estão lá. Sem etapa de importação, sem criação de conta, sem sincronização na nuvem. Seus dados ficam na sua máquina.

Se você é 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.