Este é meu terminal agora.

Sessão tmux com 13 agentes

13 agentes Claude Code, cada um em seu próprio painel tmux, trabalhando no mesmo codebase. Não como experimento. Não como demonstração de força. É assim que eu entrego software todos os dias.

O projeto é o Beadbox, um dashboard em tempo real para monitorar agentes de IA de programação. Ele é construído pela mesma frota de agentes que monitora. Os agentes escrevem o código, testam, revisam, empacotam e entregam. Eu coordeno.

Se você está rodando mais de dois ou três agentes e se perguntando como acompanhar o que todos estão fazendo, esse é o modelo no qual cheguei após meses de iteração. Um bug foi reportado às 9h e o fix foi enviado às 15h, enquanto quatro outros fluxos de trabalho rodavam em paralelo. Nem sempre funciona perfeitamente, mas a produtividade é real.

O elenco

Cada agente tem um arquivo CLAUDE.md que define sua identidade, o que ele tem responsabilidade, o que não tem, e como se comunica com outros agentes. Não são assistentes genéricos "faz-tudo". Cada um tem uma função estreita e limites explícitos.

Grupo	Agentes	O que eles cuidam
Coordenação	super, pm, owner	Despacho de trabalho, specs de produto, prioridades de negócio
Engenharia	eng1, eng2, arch	Implementação, design de sistema, suites de teste
Qualidade	qa1, qa2	Validação independente, portões de qualidade para release
Operações	ops, shipper	Testes de plataforma, builds, execução de release
Crescimento	growth, pmm, pmm2	Analytics, posicionamento, conteúdo público

A palavra-chave é limites. eng2 não pode fechar issues. qa1 não escreve código. pmm nunca toca no código fonte da app. Super despacha trabalho mas não implementa. Os limites existem porque sem eles, os agentes derivam. Eles "ajudam" refatorando código que não precisava de refatoração, ou fechando issues que não estavam verificados, ou tomando decisões arquiteturais para as quais não estão qualificados.

Cada CLAUDE.md começa com um parágrafo de identidade e uma seção de limites. Aqui vai uma versão abreviada do que eng2 tem:

## 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 padrão escala. Quando comecei com 3 agentes, eles podiam compartilhar um único prompt genérico. Com 13, roles explícitos e protocolos são a diferença entre coordenação e caos.

A camada de coordenação

Três ferramentas sustentam a frota.

beads é um issue tracker open-source e Git-nativo construído exatamente para esse workflow. Cada tarefa é um "bead" com status, prioridade, dependências e um thread de comentários. Os agentes leem e escrevem no mesmo banco de dados local através de um CLI chamado bd.

bd update bb-viet --claim --actor eng2   # eng2 reivindica um bug
bd show bb-viet                           # ver o spec completo + comentários
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 posta seu plano

gn / gp / ga são ferramentas de mensagem para tmux. gn envia uma mensagem para o painel de outro agente. gp espia o output recente de outro agente (sem interrompê-lo). ga enfileira uma mensagem não 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 escalação, formato de comunicação e critérios de conclusão. Cada agente sabe: reivindicar o bead, comentar seu plano antes de programar, rodar testes antes de fazer push, comentar DONE com passos de verificação, marcar ready for QA, reportar ao super.

Veja como isso funciona na prática. Este é um bead real de hoje cedo: super atribui a tarefa, eng2 comenta um plano numerado, eng2 comenta DONE com passos de verificação de QA e critérios de aceitação marcados, super despacha para QA.

Um thread de comentários real mostrando o workflow completo PLAN/DONE

Super roda um loop de patrulha a cada 5-10 minutos: espiar o output de cada agente ativo, verificar o status do bead, confirmar que o pipeline não travou. É como uma rotação de plantão em produção, exceto que os serviços são agentes de IA e os incidentes são "eng2 está suspeitosamente quieto há 20 minutos."

Um dia real

Isso é o que aconteceu em uma quarta-feira no final de fevereiro de 2026.

9:14 - Um usuário do GitHub chamado ericinfins abre a Issue #2: ele não consegue conectar o Beadbox ao seu servidor remoto de Dolt. A app só suporta conexões locais. Owner vê e sinaliza para super.

9:30 - Super despacha o trabalho. Arch projeta um fluxo de auth de conexão (toggle de TLS, campos de usuário/senha, passagem de variáveis de ambiente). PM escreve o spec com critérios de aceitação. Eng assume e começa a implementar.

Enquanto isso, em paralelo:

PM registra dois bugs descobertos durante os testes de release. Um é cosmético: o badge do header mostra "v0.10.0-rc.7" em vez de "v0.10.0" em builds finais. O outro é específico de plataforma: a ferramenta de captura de tela retorna uma faixa em branco em Macs ARM64 porque o Apple Silicon renderiza o WebView do Tauri via composição Metal, e o backing store está vazio.

Ops encontra a causa do bug de captura. A correção é elegante: após a captura, verificar se a altura da imagem é suspeitosamente pequena (menos de 50px para uma janela que deveria ter 800px de altura), e recorrer a captura baseada em coordenadas de tela.

Growth puxa dados do PostHog e roda uma análise de correlação de IP. A descoberta: anúncios no Reddit geraram 96 cliques e zero usuários retidos atribuíveis. O tráfego do README do GitHub converte a 15.8%. Este artigo existe por causa dessa análise.

Eng1, desbloqueado pelo design do Activity Dashboard do arch, começa a construir gerenciamento de estado de filtros cruzados e funções utilitárias. 687 testes passando.

QA1 valida o fix do badge do header: levanta um servidor de teste, usa automação de navegador para verificar que o badge renderiza corretamente, confirma que 665 testes unitários passam, marca PASS.

14:45 - Shipper faz merge do PR do release candidate, faz push da tag v0.10.0 e dispara o workflow de promoção. CI constrói artefatos para as 5 plataformas (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper verifica cada artefato, atualiza as notas de release em ambos repos, faz redeploy do site e atualiza o cask do Homebrew.

15:12 - Owner responde no GitHub Issue #2:

Boas notícias: v0.10.0 acabou de ser lançada com suporte completo de auth para servidor Dolt. Atualize e você deve estar desbloqueado.

Bug reportado de manhã. Fix enviado de tarde. E enquanto isso acontecia, a próxima feature já estava sendo projetada, outro bug estava sendo investigado, analytics estavam sendo analisados, e QA estava verificando independentemente outro fix.

Isso não é porque 13 agentes são rápidos. É porque 13 agentes são paralelos.

O que dá errado

Essa é a parte que a maioria dos posts "olha meu setup de IA" omitem.

Limites de taxa batem com alta concorrência. Quando 13 agentes rodam na mesma conta de API, você queima tokens rápido. Nesse dia específico, super, eng1 e eng2 bateram no teto de limite de taxa simultaneamente. Todo mundo para. Você espera. É o equivalente em IA de todo mundo no escritório tentando usar a impressora ao mesmo tempo, exceto que a impressora cobra por página e há um teto de páginas por minuto.

QA devolve trabalho. Isso é por design, mas adiciona ciclos. QA rejeitou um build porque o comentário "DONE" do engenheiro não incluía passos de verificação. O fix funcionava, mas QA não conseguia confirmar sem ler código fonte. De volta para eng, reescrever o comentário de conclusão, de volta para QA, re-verificar. Vinte minutos para o que deveria ter sido cinco. O protocolo cria fricção, mas a fricção é estrutural. Toda vez que eu encurtei o QA, algo quebrou em produção.

As janelas de contexto enchem. Agentes acumulam contexto ao longo de uma sessão. Super tem um protocolo para enviar uma diretiva de "salve seu trabalho" a 65% de uso de contexto. Se você 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 retentando o mesmo comando falhando. O loop de patrulha do super detecta isso, mas só se você verificar com frequência suficiente. Eu já perdi 30 minutos com um agente que estava educadamente falhando em silêncio.

O overhead de coordenação é real. Arquivos CLAUDE.md, protocolos de despacho, loops de patrulha, comentários em beads, relatórios de conclusão. Para um setup de dois agentes, isso é excessivo. Para 13 agentes, é a estrutura mínima viável. Há um ponto de cruzamento por volta de 5 agentes onde a coordenação informal para de funcionar e você precisa de protocolos explícitos ou começa a perder a noção do que está acontecendo.

O que aprendi

Especialização supera generalização. 13 agentes focados superam 3 "full-stack". Quando qa1 só valida e nunca escreve código, ele pega coisas que eng perdeu toda vez. Quando arch só projeta e nunca implementa, os designs ficam mais limpos porque não há tentação de atalhar o spec para facilitar a implementação.

QA independente é inegociável. QA tem seu próprio clone do repo. Ele testa o código pushed, não o working tree. Não confia no auto-relato do engenheiro. Parece lento. Pega bugs em todo release.

Você precisa de visibilidade ou a frota deriva. Com 5+ agentes, você não consegue rastrear o estado alternando entre painéis tmux e rodando bd list na sua cabeça. Você precisa de um dashboard que mostre a árvore de dependências, quais agentes estão trabalhando em quê e quais beads estão bloqueados. Esse é o problema que construí 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 o detecta pelo mesmo processo de QA que detectou todos os outros bugs. A ferramenta melhora porque o time que mais a usa é o time que a constrói. Eu sei que isso é ou brilhante ou a máquina de Rube Goldberg mais elaborada já construída. As features entregues sugerem o primeiro. Minha fatura de tokens sugere o segundo.

O stack

Se você quer tentar isso, aqui vai o que você precisa:

beads: Issue tracker open-source nativo de Git. É a espinha dorsal da coordenação. Cada agente lê e escreve nele.
Claude Code: O runtime de agentes. Cada agente é uma sessão de Claude Code em um painel tmux com seu próprio arquivo de identidade CLAUDE.md.
tmux + gn/gp/ga: Multiplexador de terminal para rodar agentes lado a lado. As ferramentas de mensagem permitem que agentes se comuniquem sem memória compartilhada.
Beadbox: Dashboard visual em tempo real que mostra o que a frota está fazendo. É sobre isso que você está lendo.

Você não precisa dos 13 agentes para começar. Dois engenheiros e um agente de QA, coordenados pelo beads, vão mudar como você pensa sobre o que um único desenvolvedor pode entregar.

O que vem a seguir

A maior lacuna no setup atual é responder três perguntas de relance: quais agentes estão ativos, ociosos ou travados? Onde o trabalho está se acumulando no pipeline? E o que acabou de acontecer, filtrado pelo agente ou etapa do pipeline que me interessa?

Agora isso requer um loop de patrulha e muitos comandos gp. Então estamos construindo um dashboard de coordenação diretamente no Beadbox: uma faixa de status de agentes no topo, um fluxo de pipeline mostrando onde beads estão se acumulando, e um feed de eventos com filtros cruzados onde clicar em um agente ou etapa do pipeline filtra todo o resto. As três camadas compartilham a mesma fonte de dados em tempo real. As três atualizam ao vivo.

Preview do Activity Dashboard

Os 13 agentes estão construindo isso agora. Vou escrever sobre quando for lançado.

Eu entrego software com 13 agentes de IA. Veja como funciona na prática