Visualizando dependências entre agentes de IA em tempo real

Você tem cinco agentes de IA trabalhando em um épico de feature. O Agente 1 está construindo a camada de API. O Agente 2 precisa dessa API para conectar o frontend. O Agente 3 está escrevendo testes de integração que dependem de ambos. Os Agentes 4 e 5 cuidam de migrações e documentação, cada um bloqueado por peças diferentes.

Isso funciona por uns vinte minutos. Então o Agente 2 trava porque o Agente 1 encontrou um problema inesperado de schema. O Agente 3 agora está bloqueado pelo Agente 2, que está bloqueado pelo Agente 1. Os Agentes 4 e 5 continuam avançando, mas o trabalho deles não pode ser mergeado até que a cadeia se resolva. Você só descobre quando se pergunta por que nada foi entregue na última hora e começa a rodar bd blocked em cada issue.

A informação de dependência existe. Vive no seu issue tracker. Mas quando você a gerencia por um CLI, está reconstruindo o grafo na sua cabeça a partir de texto plano. Essa reconstrução falha exatamente no momento que mais importa: quando o grafo é complexo e as coisas estão quebrando.

Como o beads rastreia dependências

beads é um issue tracker respaldado por git construído para coordenação de agentes de IA. Armazena tudo em um banco de dados Dolt local dentro do diretório .beads/ do seu repo. Sem serviço cloud, sem contas, sem conflitos de sincronização.

Agentes declaram dependências com um único comando:

bd dep add ISSUE-42 ISSUE-37

Isso registra que ISSUE-42 depende de ISSUE-37. ISSUE-42 não pode avançar até que ISSUE-37 feche. A consulta inversa é igualmente simples:

bd blocked

Retorna cada issue no workspace atualmente bloqueado por uma dependência não resolvida. E para um issue específico:

bd dep list ISSUE-42

Mostra do que ISSUE-42 depende e o que depende de ISSUE-42.

O modelo de dados é limpo. O problema não é registrar dependências. O problema é vê-las. Quando você tem 30 issues ativos em cinco agentes, rodar bd blocked te dá uma lista. Uma lista não mostra que ISSUE-12 é um gargalo bloqueando sete tarefas a jusante em três agentes. Uma lista não mostra que o Agente 3 criou uma cadeia de dependência circular entre ISSUE-18 e ISSUE-22. Você precisa de uma visão espacial do grafo, não sequencial.

O que o Beadbox mostra

Beadbox é um app desktop nativo que envolve o CLI do beads com uma interface visual. Lê do mesmo banco de dados .beads/ em que seus agentes escrevem, e se atualiza em tempo real enquanto eles trabalham.

Na view de árvore de épico, cada issue que tem dependências não resolvidas mostra um badge de bloqueado inline. Você vê a estrutura completa da árvore do seu épico, com issues bloqueados marcados de relance. Sem comando para rodar, sem output para parsear.

A cadeia de dependência é visível espacialmente. Se ISSUE-42 depende de ISSUE-37, e ISSUE-37 depende de ISSUE-15, e ISSUE-15 está atribuído ao Agente 1 que está travado, você pode traçar essa cadeia escaneando a árvore. Vê a forma do gargalo sem reconstruí-lo de queries CLI separadas.

A parte de tempo real importa. Quando o Agente 1 finalmente fecha ISSUE-15, a UI do Beadbox reflete em um segundo. O badge de bloqueado em ISSUE-37 some. Se ISSUE-37 era a única coisa bloqueando ISSUE-42, esse badge também some. Você observa a cadeia de dependências colapsar conforme o trabalho se completa, sem refresh ou re-query.

Por baixo dos panos, funciona por um pipeline direto: um servidor WebSocket observa o diretório .beads/ com fs.watch(). Quando qualquer agente escreve no banco de dados (fechando um issue, adicionando uma dependência, atualizando status), o evento do sistema de arquivos dispara uma difusão para todos os clientes conectados. A UI React re-renderiza com dados frescos. Latência sub-segundo da ação do agente até a atualização visual.

Um cenário concreto: detectando um gargalo

Cinco agentes trabalham em um épico de feature com 24 issues. Você abre o Beadbox e olha a árvore de épico. Doze issues estão em andamento. Seis mostram badges de bloqueado.

Isso já é informação que você não tinha. bd list mostraria 12 issues em andamento, mas você precisaria rodar bd blocked separadamente e cruzar referências para entender quais issues em andamento estão realmente parados.

Você escaneia os badges de bloqueado e nota algo: quatro dos seis issues bloqueados dependem de ISSUE-19, uma migração de schema de banco de dados atribuída ao Agente 4. O Agente 4 ainda está trabalhando nisso, mas ISSUE-19 se tornou um gargalo de ponto único. Quatro agentes estão efetivamente ociosos, esperando uma única tarefa.

Sem a visão visual, você poderia não perceber isso por mais uma hora. Com ela, pode intervir imediatamente. Talvez reatribua ISSUE-19 a um agente mais rápido. Talvez divida em peças menores que possam desbloquear alguns dependentes mais cedo. Talvez perceba que duas daquelas quatro dependências foram declaradas em excesso e podem ser removidas com bd dep remove.

O ponto não é que a informação estava indisponível antes. Sempre esteve no banco de dados. O ponto é que a representação visual faz emergir padrões que texto plano obscurece.

Anti-padrões comuns de dependências

Rodar múltiplos agentes de IA em um repo produz alguns problemas recorrentes de dependências. Todos são mais fáceis de detectar visualmente do que por queries CLI.

Sobre-declaração. Agentes tendem a ser conservadores. Na dúvida, declaram uma dependência. O resultado é um grafo de dependências mais denso do que precisa, com issues bloqueados por trabalho que realmente não necessitam. No Beadbox, você detecta isso quando um issue mostra badge de bloqueado mas o issue bloqueador está em uma parte completamente não relacionada do codebase. Um rápido bd dep remove limpa.

Cadeias circulares. O Agente A declara dependência do trabalho do Agente B. O Agente B, trabalhando independentemente, declara dependência do trabalho do Agente A. Agora ambos estão bloqueados um pelo outro e nenhum pode avançar. O CLI do beads detecta dependências circulares óbvias no momento da criação, mas ciclos indiretos por três ou mais issues são mais difíceis de detectar. Na árvore de épico, você os nota como clusters de badges bloqueados que nunca se resolvem, mesmo enquanto outro trabalho se completa ao redor.

Gargalos de ponto único. Um issue acumula cinco, seis, sete dependentes a jusante. Isso acontece naturalmente quando agentes trabalhando em paralelo todos precisam da mesma peça fundamental. O cenário acima ilustra o padrão. Em uma view de lista, você vê sete issues bloqueados. Em uma view de árvore, vê sete setas apontando para o mesmo nó. O gargalo é óbvio.

Para começar

Beadbox roda em macOS, Linux e Windows. Instale com Homebrew:

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

Aponte para qualquer repositório com um diretório .beads/. Se você já está rodando beads com sua frota de agentes, o Beadbox pega o banco de dados existente e começa a renderizar imediatamente. Sem etapa de importação, sem configuração, sem criação de conta.

Seus agentes continuam usando o CLI. Rodam bd dep add, bd update, bd close como sempre. Beadbox observa o banco de dados e reflete cada mudança em tempo real. Você ganha a camada visual sem mudar nenhum workflow de agentes.

Beadbox é gratuito durante o beta.

Se você está coordenando múltiplos agentes de IA em um único codebase, o grafo de dependências é o que vai quebrar seu workflow primeiro. Você pode gerenciá-lo às cegas pelo CLI, ou pode vê-lo. Ver é mais rápido.