Voce tem cinco agentes de IA trabalhando em um epic de feature. O Agente 1 esta construindo a camada de API. O Agente 2 precisa dessa API para montar o frontend. O Agente 3 esta escrevendo testes de integracao que dependem dos dois. Os Agentes 4 e 5 cuidam de migrations e documentacao, cada um bloqueado por pecas diferentes.
Isso funciona por uns vinte minutos. Ai o Agente 2 trava porque o Agente 1 encontrou um problema inesperado no schema. O Agente 3 agora esta bloqueado pelo Agente 2, que esta bloqueado pelo Agente 1. Os Agentes 4 e 5 continuam trabalhando, mas o trabalho deles nao pode ser mergeado ate a cadeia ser resolvida. Voce so descobre quando se pergunta por que nada foi entregue em uma hora e comeca a rodar bd blocked em cada issue.
A informacao de dependencia existe. Ela esta no seu issue tracker. Mas quando voce a gerencia por um CLI, esta reconstruindo o grafo na sua cabeca a partir de saida de texto plano. Essa reconstrucao falha exatamente no momento em que mais importa: quando o grafo e complexo e as coisas estao quebrando.
Como beads rastreia dependencias
beads e um issue tracker versionado no Git, construido para coordenacao de agentes de IA. Ele armazena tudo em um banco de dados Dolt local dentro do diretorio .beads/ do seu repositorio. Sem servico na nuvem, sem contas, sem conflitos de sincronizacao.
Agentes declaram dependencias com um unico comando:
bd dep add ISSUE-42 ISSUE-37
Isso registra que ISSUE-42 depende de ISSUE-37. ISSUE-42 nao pode prosseguir ate ISSUE-37 ser fechado. A consulta inversa e igualmente simples:
bd blocked
Isso retorna todo issue no workspace atualmente bloqueado por uma dependencia nao resolvida. E para um issue especifico:
bd dep list ISSUE-42
Isso mostra de quem ISSUE-42 depende e o que depende de ISSUE-42.
O modelo de dados e limpo. O problema nao e registrar dependencias. O problema e ve-las. Quando voce tem 30 issues ativos em cinco agentes, rodar bd blocked retorna uma lista. Uma lista nao mostra que ISSUE-12 e um gargalo bloqueando sete tarefas a jusante em tres agentes. Uma lista nao mostra que o Agente 3 criou uma cadeia de dependencia circular entre ISSUE-18 e ISSUE-22. Voce precisa de uma visao espacial do grafo, nao sequencial.
O que o Beadbox mostra
Beadbox e um app desktop nativo que envolve o CLI beads com uma interface visual. Ele le o mesmo banco de dados .beads/ em que seus agentes escrevem e atualiza em tempo real conforme eles trabalham.
Na visualizacao de arvore de epics, todo issue com dependencias nao resolvidas mostra um badge de bloqueio inline. Voce ve a estrutura completa da arvore do seu epic, com issues bloqueados marcados de relance. Sem comando para rodar, sem saida para interpretar.
A cadeia de dependencia e visivel espacialmente. Se ISSUE-42 depende de ISSUE-37, e ISSUE-37 depende de ISSUE-15, e ISSUE-15 esta atribuido ao Agente 1 que esta travado, voce consegue rastrear essa cadeia percorrendo a arvore. Voce ve a forma do gargalo sem reconstrui-lo a partir de consultas CLI separadas.
A parte de tempo real importa. Quando o Agente 1 finalmente fecha ISSUE-15, a interface do Beadbox reflete isso em menos de um segundo. O badge de bloqueio em ISSUE-37 desaparece. Se ISSUE-37 era a unica coisa bloqueando ISSUE-42, esse badge tambem desaparece. Voce assiste a cadeia de dependencia colapsar conforme o trabalho e concluido, sem atualizar ou re-consultar.
Por baixo, isso funciona por um pipeline direto: um servidor WebSocket monitora o diretorio .beads/ com fs.watch(). Quando qualquer agente escreve no banco de dados (fechando um issue, adicionando uma dependencia, atualizando status), o evento de sistema de arquivos dispara um broadcast para todos os clientes conectados. A interface React re-renderiza com dados frescos. Latencia sub-segundo da acao do agente ate a atualizacao visual.
Um cenario concreto: identificando um gargalo
Cinco agentes trabalham em um epic de feature com 24 issues. Voce abre o Beadbox e olha a arvore do epic. Doze issues estao em andamento. Seis mostram badges de bloqueio.
Isso ja e informacao que voce nao tinha. bd list mostraria 12 issues em andamento, mas voce precisaria rodar bd blocked separadamente e cruzar referencias para entender quais issues em andamento estao realmente parados.
Voce examina os badges de bloqueio e nota algo: quatro dos seis issues bloqueados dependem de ISSUE-19, uma migration de schema de banco de dados atribuida ao Agente 4. O Agente 4 ainda esta trabalhando nisso, mas ISSUE-19 se tornou um gargalo unico. Quatro agentes estao efetivamente ociosos, esperando por uma tarefa.
Sem a visao visual, voce talvez nao percebesse isso por mais uma hora. Com ela, voce pode intervir imediatamente. Talvez reatribuir ISSUE-19 a um agente mais rapido. Talvez dividi-lo em pecas menores que podem desbloquear alguns dependentes mais cedo. Talvez perceber que duas daquelas quatro dependencias foram declaradas em excesso e podem ser removidas com bd dep remove.
O ponto nao e que a informacao era inacessivel antes. Ela sempre esteve no banco de dados. O ponto e que a representacao visual revela padroes que o texto plano obscurece.
Anti-padroes comuns de dependencia
Rodar multiplos agentes de IA em um repositorio produz alguns problemas recorrentes de dependencia. Todos sao mais faceis de identificar visualmente do que por consultas CLI.
Declaracao excessiva. Agentes tendem a ser conservadores. Na duvida, declaram uma dependencia. O resultado e um grafo de dependencias mais denso do que necessario, com issues bloqueados por trabalho que nao precisam de fato. No Beadbox, voce identifica isso quando um issue mostra um badge de bloqueio mas o issue bloqueante esta em uma parte completamente nao relacionada do codebase. Um rapido bd dep remove resolve.
Cadeias circulares. O Agente A declara uma dependencia no trabalho do Agente B. O Agente B, trabalhando independentemente, declara uma dependencia no trabalho do Agente A. Agora ambos estao bloqueados um pelo outro e nenhum consegue prosseguir. O CLI beads detecta dependencias circulares obvias no momento da criacao, mas ciclos indiretos atraves de tres ou mais issues sao mais dificeis de detectar. Na arvore de epics, voce nota isso como clusters de badges de bloqueio que nunca se resolvem, mesmo enquanto outro trabalho avanca ao redor.
Gargalos de ponto unico. Um issue acumula cinco, seis, sete dependentes a jusante. Isso acontece naturalmente quando agentes trabalhando em paralelo todos precisam da mesma peca fundamental. O cenario acima ilustra o padrao. Em uma visualizacao de lista, voce ve sete issues bloqueados. Em uma visualizacao de arvore, voce ve sete setas apontando para o mesmo no. O gargalo e obvio.
Comecando
Beadbox roda em macOS, Linux e Windows. Instale com Homebrew:
brew tap beadbox/cask && brew install --cask beadbox
Aponte para qualquer repositorio com um diretorio .beads/. Se voce ja esta rodando beads com sua frota de agentes, o Beadbox pega o banco de dados existente e comeca a renderizar imediatamente. Sem etapa de importacao, sem configuracao, sem criacao de conta.
Seus agentes continuam usando o CLI. Eles rodam bd dep add, bd update, bd close normalmente. O Beadbox monitora o banco de dados e reflete cada mudanca em tempo real. Voce ganha a camada visual sem alterar nenhum workflow dos agentes.
Beadbox e gratuito durante o beta.
Se voce esta coordenando multiplos agentes de IA em um unico codebase, o grafo de dependencias e a coisa que vai quebrar seu workflow primeiro. Voce pode gerencia-lo as cegas pelo CLI, ou pode ve-lo. Ver e mais rapido.