Mais agentes, mais coordenação

Um agente de programação é uma ferramenta. Dois ou mais começam a parecer uma equipe, e equipes trazem um problema antigo: coordenação. Alguém precisa decidir o que fazer, alguém precisa lembrar em que pé estão as coisas e alguém precisa verificar se “pronto” significa pronto.

Quando uso Claude Code ou Codex em uma sessão, sou essas três pessoas. Funciona até o trabalho ultrapassar uma sessão. Então viro o roteador, copiando contexto de uma conversa para outra, lembrando qual mudança esperava por qual e explicando de novo decisões já tomadas. Os agentes são rápidos. A coordenação sou eu, e eu não sou.

Por isso tenho pesquisado ferramentas que levam coordenação a sério. Não para construir uma fábrica autônoma de software, mas para entender que parte desse trabalho pode ser explicitada.

Três responsabilidades fáceis de confundir

Decidir o trabalho. Qual parte vem a seguir, quem a assume e com quais instruções. Isso é orquestração.

Manter o estado. O que está pronto, bloqueado, em andamento e o que depende do quê. Isso precisa sobreviver ao fim de uma sessão, porque os agentes esquecem e eu também.

Verificar. Se o resultado realmente atende aos critérios. Importa quem faz isso. Um agente que escreve o código e depois o aprova não verificou muita coisa.

A maior parte da confusão que encontrei vem de uma ferramenta fazer silenciosamente as três coisas ou de ninguém assumir claramente a terceira.

O que tenho testado

Duas ferramentas do mesmo ecossistema correspondem bem às duas primeiras responsabilidades. Não construí nenhuma delas; sou um usuário tentando entendê-las.

Gas City se descreve como um SDK para construir orquestração de fluxos de programação com múltiplos agentes. Ele pega a infraestrutura reutilizável do Gas Town (provedores de execução, encaminhamento de trabalho, fórmulas e monitoramento de saúde) e a torna configurável. Nos meus termos, é um candidato a decidir o trabalho.

Beads é um rastreador persistente de tarefas, com consciência de dependências, criado para agentes de programação. Em vez de um plano Markdown que um agente talvez releia ou não, o trabalho é um grafo de tarefas com dependências explícitas. Assim, “o que está pronto para começar?” vira uma consulta, não um palpite. Nos meus termos, é manter o estado.

Configurei os dois localmente, junto com o Serena, que oferece aos agentes navegação e edição de código por símbolos via MCP, em vez de ler arquivos inteiros. Depois executei um teste de ponta a ponta deliberadamente pequeno em um cenário sintético. O fluxo leu uma especificação aprovada, produziu um plano, revisou esse plano, dividiu-o em um grafo de tarefas no Beads, implementou a mudança em uma árvore de trabalho isolada e executou verificações protegidas. Uma sessão separada fez a revisão antes da verificação final.

Passou. A mudança eram poucas linhas em um módulo de cálculo de exemplo.

Quero ser preciso sobre o que isso demonstra. Demonstra que esse fluxo pode funcionar de ponta a ponta, com essa configuração, em algo minúsculo. Não demonstra que escala, que é mais rápido que eu com um agente ou que está pronto para construir um produto real. Chegar lá também exigiu várias execuções de diagnóstico, o que já é um dado sobre o custo de operar isso.

Onde fica a verificação

A parte que mais me interessa é a relação entre encerrar uma tarefa e provar que ela terminou. Em um rastreador, encerrar é uma mudança de estado. Quero que o encerramento exija evidência: quais verificações rodaram, em qual commit e com revisão de quem. O sistema deve conseguir dizer “encerrada porque estas verificações passaram”, não apenas “encerrada”.

É também por isso que mantenho a especificação e as decisões fora da ferramenta de acompanhamento. Ela guarda o estado da execução; os motivos do trabalho ficam em documentos que não mudam quando troco de ferramenta.

Para as verificações em si, tenho lido sobre Dagger (pipelines como código, com mecanismo de execução portátil e cache) e sobre execuções do Nx apenas para o que foi afetado. Nenhum foi adotado na minha configuração, e não tenho medições para compartilhar. Estão na lista porque “rodar tudo, toda vez” fica caro quando os agentes produzem mudanças mais rápido do que a CI termina.

Perguntas em aberto

• Onde a orquestração reduz a coordenação manual e onde só cria mais um sistema para operar? Uma configuração com múltiplos agentes tem sua própria configuração, falhas e atualizações. Esse custo é real.
• Quanta autonomia é útil antes de a revisão virar o gargalo? Mais agentes significam mais mudanças para verificar, e a revisão não se paraleliza tão bem quanto a geração de código.
• Qual é o mínimo de contexto para uma tarefa ainda ser bem-feita? Com pouco, o agente adivinha. Com muito, ele se afoga.

Ainda não tenho respostas e desconfio de quem já as tem. Tenho uma visão mais clara das três responsabilidades e a forte impressão de que a última é a que mais merece proteção: alguém, ou algo independente, precisa conferir o trabalho.