Este e meu terminal agora.
13 agentes Claude Code, cada um em seu proprio painel tmux, trabalhando no mesmo codebase. Nao como experimento. Nao como demonstracao de forca. E assim que eu entrego software todos os dias.
O projeto e o Beadbox, um dashboard em tempo real para monitorar agentes de IA de programacao. Ele e construido pela mesma frota de agentes que monitora. Os agentes escrevem o codigo, testam, revisam, empacotam e entregam. Eu coordeno.
Se voce esta rodando mais de dois ou tres agentes e se perguntando como acompanhar o que todos estao fazendo, esse e o modelo no qual cheguei apos meses de iteracao.
O Elenco
Cada agente tem um arquivo CLAUDE.md que define sua identidade, o que ele tem responsabilidade, o que nao tem, e como se comunica com outros agentes. Nao sao assistentes genericos "faz-tudo". Cada um tem uma funcao estreita e limites explicitos.
| Grupo | Agentes | O que eles cuidam |
|---|---|---|
| Coordenacao | super, pm, owner | Despacho de trabalho, specs de produto, prioridades de negocio |
| Engenharia | eng1, eng2, arch | Implementacao, design de sistema, suites de teste |
| Qualidade | qa1, qa2 | Validacao independente, portoes de qualidade para release |
| Operacoes | ops, shipper | Testes de plataforma, builds, execucao de release |
| Crescimento | growth, pmm, pmm2 | Analytics, posicionamento, conteudo publico |
A palavra-chave e limites. eng2 nao pode fechar issues. qa1 nao escreve codigo. pmm nunca toca no codigo fonte do app. Super despacha trabalho mas nao implementa. Os limites existem porque sem eles, os agentes desviam. Eles "ajudam" refatorando codigo que nao precisava de refatoracao, ou fechando issues que nao foram verificados, ou tomando decisoes arquiteturais para as quais nao estao qualificados.
Cada CLAUDE.md comeca com um paragrafo de identidade e uma secao de limites. Veja uma versao resumida do eng2:
## Identity
Engineer for Beadbox. You implement features, fix bugs, and write tests.
You own implementation quality: the code you write is correct, tested,
and matches the spec.
## Boundary with QA
QA validates your work independently. You provide QA with executable
verification steps. If your DONE comment doesn't let QA verify without
reading source code, it's incomplete.
Esse padrao escala. Quando comecei com 3 agentes, eles conseguiam compartilhar um unico prompt generico. Com 13, papeis explicitos e protocolos sao a diferenca entre coordenacao e caos.
A Camada de Coordenacao
Tres ferramentas mantem a frota unida.
beads e um issue tracker open-source e Git-native construido exatamente para esse workflow. Cada tarefa e um "bead" com status, prioridade, dependencias e uma thread de comentarios. Agentes leem e escrevem no mesmo banco de dados local atraves de um CLI chamado bd.
bd update bb-viet --claim --actor eng2 # eng2 reivindica um bug
bd show bb-viet # ve a spec completa + comentarios
bd comments add bb-viet --author eng2 "PLAN: ..." # eng2 posta seu plano
gn / gp / ga sao ferramentas de mensagem tmux. gn envia uma mensagem para o painel de outro agente. gp espia a saida recente de outro agente (sem interrompe-lo). ga enfileira uma mensagem nao urgente.
gn -c -w eng2 "[from super] You have work: bb-viet. P2." # despacho
gp eng2 -n 40 # checar progresso
ga -w super "[from eng2] bb-viet complete. Pushed abc123." # reportar
Protocolos CLAUDE.md definem caminhos de escalacao, formato de comunicacao e criterios de conclusao. Cada agente sabe: reivindicar o bead, comentar seu plano antes de programar, rodar testes antes de fazer push, comentar DONE com passos de verificacao, marcar ready for QA, reportar ao super.
Super roda um loop de patrulha a cada 5-10 minutos: espia a saida de cada agente ativo, verifica status dos beads, confirma que o pipeline nao travou. E como um plantao de producao, exceto que os servicos sao agentes de IA e os incidentes sao "eng2 esta suspeitosamente quieto ha 20 minutos."
Um Dia Real
Veja o que realmente aconteceu numa quarta-feira no final de fevereiro de 2026.
9:14 AM - Um usuario do GitHub chamado ericinfins abre a Issue #2: ele nao consegue conectar o Beadbox ao servidor Dolt remoto. O app so suporta conexoes locais. Owner ve e sinaliza para o super.
9:30 AM - Super despacha o trabalho. Arch projeta um fluxo de autenticacao de conexao (toggle TLS, campos de usuario/senha, passagem de variaveis de ambiente). PM escreve a spec com criterios de aceitacao. Eng pega e comeca a implementar.
Enquanto isso, em paralelo:
PM registra dois bugs descobertos durante testes de release. Um e cosmetico: o badge do header mostra "v0.10.0-rc.7" em vez de "v0.10.0" nas builds finais. O outro e especifico de plataforma: a ferramenta de automacao de screenshots retorna uma faixa em branco em Macs ARM64 porque o Apple Silicon renderiza a WebView do Tauri via composicao Metal, e o backing store fica vazio.
Ops encontra a causa raiz do bug de screenshot. A correcao e elegante: apos a captura, verificar se a altura da imagem e suspeitamente pequena (abaixo de 50px para uma janela que deveria ter 800px de altura), e fazer fallback para captura de tela baseada em coordenadas.
Growth puxa dados do PostHog e roda uma analise de correlacao de IP. A descoberta: anuncios no Reddit geraram 96 cliques e zero usuarios retidos atribuiveis. Trafego do README no GitHub converte a 15.8%. Este artigo existe por causa dessa analise.
Eng1, desbloqueado pelo design do Activity Dashboard do arch, comeca a construir gerenciamento de estado cross-filter e funcoes utilitarias. 687 testes passando.
QA1 valida a correcao do badge do header: sobe um servidor de teste, usa automacao de navegador para verificar que o badge renderiza corretamente, confirma que 665 testes unitarios passam, marca PASS.
2:45 PM - Shipper mergeia o PR do release candidate, faz push da tag v0.10.0 e dispara o workflow de promocao. CI constroi artefatos para todas as 5 plataformas (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper verifica cada artefato, atualiza notas de release em ambos repos, redeploya o website e atualiza o Homebrew cask.
3:12 PM - Owner responde na Issue #2 do GitHub:
Good news: v0.10.0 just shipped with full Dolt server auth support. Update and you should be unblocked.
Bug reportado de manha. Correcao entregue de tarde. E enquanto isso acontecia, a proxima feature ja estava sendo projetada, outro bug estava sendo investigado, analytics estavam sendo analisados, e QA estava validando independentemente uma correcao separada.
Nao e porque 13 agentes sao rapidos. E porque 13 agentes sao paralelos.
O Que Da Errado
Essa e a parte que a maioria dos posts "olha meu setup de IA" omite.
Rate limits batem com alta concorrencia. Quando 13 agentes estao todos rodando na mesma conta de API, voce queima tokens rapido. Neste dia especifico, super, eng1 e eng2 bateram no teto de rate limit simultaneamente. Todo mundo para. Voce espera. E o equivalente em IA de todo mundo no escritorio tentando usar a impressora ao mesmo tempo, exceto que a impressora cobra por pagina e tem um limite de paginas por minuto.
QA devolve trabalho. Isso e por design, mas adiciona ciclos. QA rejeitou uma build porque o comentario "DONE" do engenheiro nao incluia passos de verificacao. A correcao funcionava, mas QA nao conseguia confirmar sem ler codigo fonte. Volta para eng, reescreve o comentario de conclusao, volta para QA, re-verifica. Vinte minutos para o que deveria ter sido cinco. O protocolo cria friccao, mas a friccao e estrutural. Toda vez que encurtei o QA, algo quebrou em producao.
Janelas de contexto enchem. Agentes acumulam contexto ao longo de uma sessao. Super tem um protocolo para enviar uma diretiva "salve seu trabalho" em 65% de uso de contexto. Se voce perde a janela, o agente perde o fio do que estava fazendo.
Agentes travam. As vezes um agente entra em um loop de erro e fica repetindo o mesmo comando falhando. O loop de patrulha do super pega isso, mas so se voce estiver verificando com frequencia suficiente. Ja perdi 30 minutos com um agente que estava educadamente falhando em silencio.
O custo de coordenacao e real. Arquivos CLAUDE.md, protocolos de despacho, loops de patrulha, comentarios em beads, relatorios de conclusao. Para um setup de dois agentes, e exagero. Para 13 agentes, e a estrutura minima viavel. Existe um ponto de cruzamento por volta de 5 agentes onde coordenacao informal para de funcionar e voce precisa de protocolos explicitos ou comeca a perder o rastreamento do que esta acontecendo.
O Que Aprendi
Especializacao supera generalizacao. 13 agentes focados superam 3 "full-stack". Quando qa1 so valida e nunca escreve codigo, ele pega coisas que eng perdeu toda vez. Quando arch so projeta e nunca implementa, os designs sao mais limpos porque nao ha tentacao de encurtar a spec para facilitar a implementacao.
QA independente nao e negociavel. QA tem seu proprio clone do repo. Testa o codigo que foi feito push, nao a working tree. Nao confia no auto-relato do engenheiro. Parece lento. Pega bugs em todo release.
Voce precisa de visibilidade ou a frota deriva. Com 5+ agentes, voce nao consegue rastrear estado alternando entre paineis tmux e rodando bd list na cabeca. Voce precisa de um dashboard que mostre a arvore de dependencias, quais agentes estao trabalhando no que, e quais beads estao bloqueados. Esse e o problema que construi o Beadbox para resolver.
O loop recursivo importa. Os agentes constroem o Beadbox. O Beadbox monitora os agentes. Quando os agentes produzem um bug no Beadbox, a frota pega pelo mesmo processo de QA que pegou todos os outros bugs. A ferramenta melhora porque o time que mais a usa e o time que a constroi. Tenho consciencia de que isso e ou brilhante ou a maquina de Rube Goldberg mais elaborada ja construida. As features entregues sugerem o primeiro. Minha conta de tokens sugere o segundo.
A Stack
Se voce quer tentar isso, aqui esta o que precisa:
- beads: Issue tracker open-source e Git-native. Esse e o backbone de coordenacao. Todo agente le e escreve nele.
- Claude Code: O runtime dos agentes. Cada agente e uma sessao Claude Code em um painel tmux com seu proprio arquivo CLAUDE.md de identidade.
- tmux + gn/gp/ga: Multiplexador de terminal para rodar agentes lado a lado. As ferramentas de mensagem permitem que agentes se comuniquem sem memoria compartilhada.
- Beadbox: Dashboard visual em tempo real que mostra o que a frota esta fazendo. E sobre isso que voce esta lendo.
Voce nao precisa de todos os 13 agentes para comecar. Dois engenheiros e um agente de QA, coordenados pelo beads, vao mudar como voce pensa sobre o que um unico desenvolvedor consegue entregar.
O que vem a seguir
A maior lacuna no setup atual e responder tres perguntas de relance: quais agentes estao ativos, ociosos ou travados? Onde o trabalho esta se acumulando no pipeline? E o que acabou de acontecer, filtrado pelo agente ou estagio do pipeline que me interessa?
Agora isso exige um loop de patrulha e muitos comandos gp. Entao estamos construindo um dashboard de coordenacao diretamente no Beadbox: uma faixa de status dos agentes no topo, um fluxo de pipeline mostrando onde os beads estao se acumulando, e um feed de eventos com filtros cruzados onde clicar em um agente ou estagio do pipeline filtra todo o resto para corresponder. As tres camadas compartilham a mesma fonte de dados em tempo real. As tres atualizam ao vivo.
Os 13 agentes estao construindo isso agora. Vou escrever sobre quando for lancado.