Quando se pensa em um fluxo de trabalho com agentes de IA, a maioria imagina um agente, uma tarefa longa e uma espera pelo resultado. Isso funciona para trabalhos pequenos. Em algo grande, como “migrar os pagamentos para um novo provedor”, um agente pesquisa, planeja e implementa tudo de uma vez: o contexto incha, você nunca vê um plano e os erros só aparecem depois que o código está escrito.
Este post mostra três formas de o AgentVera dividir esse trabalho entre vários agentes: uma equipe com gerente e papéis, uma equipe paralela que roda partes independentes ao mesmo tempo, e flows que passam a saída de um agente para o próximo.
Por que dividir um fluxo de trabalho com agentes de IA?
Os problemas de uma sessão com um agente só:
- O contexto cresce. Todo arquivo lido durante a pesquisa continua no contexto durante a implementação.
- O plano é invisível. O agente decide o que fazer e vai direto para o código.
- Os erros aparecem tarde. Uma suposição errada só aparece quando os testes falham.
Vários agentes com funções claras resolvem isso. Um pesquisador não escreve código, um planejador só escreve o plano, um desenvolvedor o implementa e um revisor confere. Cada um trabalha com seu próprio contexto pequeno.
Opção 1: uma equipe com gerente e papéis
A visão de equipe transforma os agentes abertos no seu workspace em uma equipe. Na janela Team structure, você os coloca em um organograma: um vira o gerente, os outros recebem um papel, instruções, alguém a quem reportam e alguém para quem repassam o trabalho. Uma equipe comporta até 24 agentes.
Você não precisa montar do zero. Papéis prontos preenchem pesquisador, planejador, desenvolvedor, revisor, testador e outros; equipes prontas, como a equipe de software (tech lead, planejador, desenvolvedor, revisor e testador), abrem os agentes de que precisam para você. A equipe e cada papel podem ter seus próprios servidores MCP, então o testador já começa com Playwright sem você configurar agente por agente.
Nada começa quando a equipe é montada. Você digita o trabalho na caixa abaixo e escolhe Give to the team. Ele vai para o gerente, que divide, distribui e confere os resultados. Os agentes resolvem tudo pelo chat entre agentes e por uma lista de tarefas compartilhada.
Enquanto roda, a visão de equipe mostra quem está trabalhando no quê, as mensagens circulando entre os agentes e em que pé está cada tarefa. Pedidos de permissão chegam à barra de atenção acima do organograma, onde você os aprova ou recusa ali mesmo. Status report pede ao gerente um resumo curto; Interrupt all para todo mundo.
Isso combina com trabalhos em que os agentes precisam conversar entre si: um planejador fazendo uma pergunta de acompanhamento ao pesquisador, um revisor devolvendo uma mudança ao desenvolvedor.
Opção 2: uma equipe paralela que termina em um PR
Alguns trabalhos se dividem em partes independentes: a API, a interface e a migração de uma nova funcionalidade, por exemplo. Uma equipe paralela roda essas partes ao mesmo tempo.
Um agente inicia a equipe por conta própria quando uma grande mudança se divide assim. Ele escreve as partes, ou dá só o objetivo e deixa o Claude Sonnet ler o repositório e planejá-las. Depois:
- Cada parte vai para o seu próprio agente, no seu próprio worktree e branch, então os agentes nunca mexem nos arquivos uns dos outros. Por padrão rodam 3 de cada vez, no máximo 6.
- Um agente termina com o marcador
[[TESLİM]]quando acaba, ou[[YARDIM]]quando trava. Uma parte travada espera por você: aceite o que ela fez, deixe continuar ou pule. - As partes concluídas são juntadas em uma branch de integração, e o comando de testes do projeto roda como verificação final. Se um merge der conflito ou a verificação falhar, um agente de integração entra em ação.
- Você abre um único pull request, ou coloca a branch na fila de merge.
Isso combina com grandes mudanças em que as partes não precisam conversar entre si, só se encaixar no final.
Opção 3: flows que repassam o trabalho
Quando você quer uma cadeia fixa, monte-a em flows. A sequência clássica de pesquisa, plano e construção fica assim:
| Etapa | Agente | O que recebe | Regra |
|---|---|---|---|
| Pesquisa | Pesquisador | O objetivo | Sem código; relatar o estado atual e as opções |
| Plano | Planejador | A última resposta do pesquisador | Objetivo, fora do escopo, arquivos, passos, estratégia de testes, critérios de aceite |
| Aprovação | Você | O plano | Nó Human approval |
| Construção | Construtor | O plano aprovado | Implementar o plano, rodar os testes |
Quando um agente termina seu turno, a última resposta dele entra no modelo de mensagem da conexão ({{output}}) e é enviada ao próximo agente. Se o próximo agente estiver ocupado, o flow espera o turno dele acabar. Os nós que deixam a cadeia segura:
- Condition: só avança quando a resposta contém uma frase ou combina com uma regex, para que uma pergunta feita no meio do caminho não dispare a próxima etapa.
- Transform: envia só o último bloco de código ou as primeiras N linhas.
- Human approval: para até você aprovar, pelo app ou pelo Telegram.
- Wait e Notify: dão um tempo entre as etapas e avisam você sobre as importantes.
- Turn limit: pausa uma conexão que entra em loop.
A etapa de aprovação é a que mais importa
Seja qual for a opção, ler o plano antes de o código ser escrito é o momento mais valioso. Um plano errado leva cinco minutos para ser corrigido ali e horas depois que o código existe. Os problemas mais pegos:
- Um módulo que deveria ficar fora do escopo entrando de fininho no plano.
- Testes existentes ausentes da estratégia de testes.
- Ordem dos passos, como primeiro a interface e depois a implementação.
Em uma equipe, peça ao gerente que envie o plano a você antes de distribuir o trabalho. Em um flow, coloque um nó Human approval antes do construtor.
Como escrever um bom objetivo
A primeira entrada é o objetivo que você escreve. Um bom objetivo:
- Descreve o resultado: “Migrar o provedor de pagamento de X para Y sem mudar o contrato atual da API.”
- Define os limites: “Não mexa no módulo de faturamento.”
- Define o sucesso: “Os testes de pagamento existentes precisam passar; adicione um teste de integração para o novo provedor.”
Um objetivo como “melhorar os pagamentos” leva todos os agentes a ler a base de código inteira.
Qual usar?
- Um agente: uma correção em um arquivo, um erro de digitação ou uma pequena mudança de estilo. Dividir leva mais tempo que o trabalho.
- Visão de equipe: trabalho contínuo em que agentes com papéis diferentes precisam conversar, perguntar e revisar uns aos outros.
- Equipe paralela: uma grande mudança com partes independentes que deve terminar como uma branch e um PR.
- Flows: uma sequência fixa que você roda várias vezes, com aprovações e condições no meio.
Rodando trabalhos longos enquanto você está fora
Você não precisa ficar no computador enquanto um trabalho longo roda:
- Notificações no Telegram: aprove uma etapa de flow pelo celular e responda a uma notificação para enviar texto àquele agente.
- App do AgentVera para celular: acompanhe o chat, o terminal e o diff de cada agente no iOS ou Android e responda aos pedidos de permissão.
- Tarefas agendadas: envie uma mensagem a um agente em um agendamento cron, por exemplo para começar uma pesquisa de dependências toda manhã.
- Impedir suspensão: a configuração que mantém o computador acordado enquanto os agentes trabalham evita que tarefas noturnas travem.
Checklist
- O objetivo descreve o resultado e os limites em um parágrafo?
- Cada agente tem uma função clara?
- Você vai ver o plano antes de o código ser escrito?
- Os testes vão rodar antes de o trabalho ser dado como pronto?
- Você vai ser avisado quando terminar?
Conclusão
Dividir um fluxo de trabalho com agentes de IA entre vários agentes os torna mais previsíveis em trabalhos grandes: cada contexto fica pequeno, o plano fica visível e os erros aparecem cedo. O AgentVera oferece três formas de fazer isso, de uma equipe ao vivo a uma execução paralela que termina em um PR.
Comece pelo plano gratuito e veja notificações e aprovações para cuidar das aprovações a distância.