Multiagente na prática: quando usar, como os agentes se comportam e onde dá errado

Ao ouvir "multiagente", muita gente imagina vários chats de IA conversando entre si. Não é isso. Multiagente é uma forma de dividir responsabilidade: em vez de um único agente analisar, desenhar, implementar e revisar o próprio trabalho, cada papel fica com um agente de escopo fechado, e quem produz nunca é quem valida.

Isso resolve problemas reais, mas cobra um preço real. Este artigo mostra quando compensa, quais padrões existem, como os agentes de fato se comportam, um exemplo do pedido ao relatório de qualidade e onde costuma dar errado. Ele continua o artigo sobre harness: multiagente é uma das camadas de um harness, a única realmente opcional.

Um agente basta?

Comece por aqui, porque é a pergunta que mais falta nos textos sobre o assunto. A resposta padrão é: um agente basta. Vários agentes só entram quando você consegue apontar o problema que um só não resolve. O guia da Anthropic sobre agentes (Building effective agents) defende o mesmo princípio: encontrar a solução mais simples possível e só aumentar a complexidade quando for necessário, porque sistemas com vários agentes trocam custo e latência por desempenho.

Quatro motivos legítimos para dividir:

E o quadro de quando o fluxo completo vale a pena:

Padrões de organização

Não existe uma única forma de organizar vários agentes. Os padrões mais comuns na literatura (a lista abaixo segue os workflows descritos no guia da Anthropic) e onde cada um aparece no meu harness:

O meu fluxo combina os quatro. Isso não é regra: um time que só precisa de verificação independente pode ficar apenas com o último padrão.

Os papéis

Cada papel tem escopo fechado, com o que faz e o que não faz:

O crítico é somente leitura: não tem como editar arquivo. O revisor segue "encontra, não corrige" por desenho do processo. Nos dois casos, a correção volta para quem implementou.

Como os agentes se comportam

Aqui está a parte que mais gente pula, e é a que decide se funciona. Um harness multiagente é uma thread orquestradora que delega para agentes que começam sem memória nenhuma da conversa. (A documentação de subagentes do Claude Code descreve o mesmo modelo: Create custom subagents, com janela de contexto separada e ferramentas restritas por agente.) Isso gera cinco comportamentos:

1. O orquestrador tem o contexto completo; cada agente recebe só uma fatia. O orquestrador lê estado do projeto, spec, design e base de conhecimento. O agente recebe apenas os caminhos dos arquivos relevantes para aquela fase. Essa assimetria evita os dois erros clássicos: alucinar por falta de contexto e estourar o limite de tokens por excesso.
2. Toda delegação tem cinco blocos. Objetivo da fase (uma frase), entradas (caminhos, não conteúdo colado), formato exato da saída, ferramentas e skills permitidas, e limites do que não fazer. Delegação vaga é a causa número um de duplicação e deriva entre agentes.
3. O agente devolve resumo, não despejo. A instrução é sempre "retorne um resumo condensado do que foi feito". O orquestrador não precisa reler tudo que o agente leu.
4. Cada agente tem só as ferramentas do papel. Restrição de ferramenta, quando existe, é mais confiável que restrição por instrução.
5. Paralelismo é exceção, com teto. Backend e frontend rodam em paralelo só quando são realmente independentes. Se dependem de um contrato compartilhado (DTOs, formato de resposta), o contrato vem primeiro. E nunca mais de 4 agentes na mesma fase.

O contexto isolado é ao mesmo tempo o maior benefício e a maior armadilha: como o agente não sabe nada além do que recebeu, a qualidade da delegação é a qualidade do resultado.

O loop de revisão

Existe um comportamento de correção que é o coração do processo:

E a regra que sustenta tudo: quem produz nunca é quem valida. Vale na cadeia inteira: quem documenta não valida a própria documentação, quem desenha a arquitetura não confere se a implementação seguiu o desenho, quem implementa não valida a própria implementação. É mais lento que deixar uma IA aprovar o próprio trabalho, de propósito.

O fluxo, gate a gate

Uma feature de escopo real passa por um fluxo fixo, com um portão de revisão entre as fases de maior risco. Nenhuma fase avança por omissão:

flowchart LR
    A([Specify]) --> B{{Critique}}
    B --> C([Design])
    C --> D{{Critique}}
    D --> E([Tasks])
    E --> F([Implement])
    F --> G{{Critique}}
    G --> R([Code Review])
    R --> H([Validate])
    H --> I([Quality Report])
    

Cada losango é um ponto onde o trabalho pode ser barrado e devolvido: nunca "parece bom", sempre uma aprovação explícita ou uma lista de problemas específicos e corrigíveis.

Crítico e Code Review não são a mesma coisa. O crítico pergunta "isso resolve o que foi pedido?": escopo, premissas, bordas esquecidas. O Code Review pergunta "isso está bem feito?": Clean Code, segurança, performance, aderência aos padrões do projeto, e o Design System quando há UI. Antes de o revisor entrar, uma análise estática automática (regras de segurança, métricas de tamanho de método e acoplamento, ortografia nas mensagens) já filtrou o que é mecânico, para ele gastar atenção no que exige julgamento.

O que torna o fluxo bom não são as caixinhas, é onde cada gate está. Gate depois de Design existe porque corrigir arquitetura em texto custa uma fração de corrigir depois que já há código em cima. Gate antes de fechar a task existe porque é o último ponto em que "esqueci a borda" ainda é barato.

Exemplo ponta a ponta

Vamos seguir uma feature ilustrativa, cadastro de fornecedores com validação de CNPJ e tela de listagem, por todo o fluxo. O diagrama mostra quem fala com quem, e onde o trabalho é barrado:

sequenceDiagram
    actor Usr as Você
    participant Orq as Orquestrador
    participant Ana as Analista
    participant Cri as Crítico
    participant Arq as Arquiteto
    participant Dev as Dev backend e frontend
    participant Rev as Revisor de código
    participant QA as QA
    participant Qual as Quality Report

    Usr->>Orq: Pede a feature de fornecedores
    Note over Orq: Lê estado do projeto, spec anterior e base de conhecimento
    Orq->>Ana: Objetivo, entradas, formato de saída e limites
    Ana-->>Orq: spec.md
    Orq->>Cri: Critique a spec
    opt Crítico reprova
        Cri-->>Orq: Lista de problemas específicos
        Orq->>Ana: Corrija só os itens da lista (ciclo 1 de 2)
        Ana-->>Orq: spec.md revisada
        Orq->>Cri: Confirme item a item
    end
    Cri-->>Orq: APROVADO explícito

    Orq->>Arq: Desenhe a arquitetura a partir da spec
    Arq-->>Orq: design.md
    Orq->>Cri: Critique o design
    Cri-->>Orq: APROVADO explícito
    Note over Orq: Gera tasks.md com tarefas atômicas, contrato primeiro

    loop Para cada task
        Orq->>Dev: Confirme premissas e implemente a task
        Dev-->>Orq: Código, testes e evidência de build
        Orq->>Cri: Critique o diff da task
        Cri-->>Orq: Lista de gaps, por exemplo borda sem teste
        Orq->>Dev: Corrija só os itens da lista
        Dev-->>Orq: Correção aplicada
        Note over Orq: Análise estática automática antes do revisor
        Orq->>Rev: Revise qualidade, segurança e padrões
        Rev-->>Orq: Lista de correções, por exemplo SQL sem parâmetro
        Orq->>Dev: Corrija só os itens da lista
        Dev-->>Orq: Correção aplicada
        Orq->>QA: Confirme build e cobertura
        QA-->>Orq: Build verde
        Orq->>Rev: Confirme item a item
        Rev-->>Orq: Lista endereçada
        Orq->>Qual: Calcule o Quality Score da task
        Qual-->>Orq: Semáforo verde
    end
    Orq-->>Usr: Feature pronta com relatório de qualidade
    

Quatro momentos merecem atenção:

• A spec volta antes de virar design. Se o analista escreveu "validar CNPJ quando possível", o crítico devolve: possível quando? Essa ambiguidade custaria uma decisão adivinhada em cada camada seguinte.
• O crítico nunca corrige. Ele lista o gap ("a task não testa CNPJ com máscara"); quem corrige é o dev; o QA confirma que o build segue verde; e o mesmo crítico confere item a item. Quatro papéis, uma correção, de propósito.
• O Code Review vem depois do crítico e segue o mesmo loop. O crítico já garantiu que a task cobre o pedido; o revisor olha a qualidade do código (ex.: uma query montada por concatenação de string). Ele lista, o dev corrige, o QA confirma o build e o mesmo revisor fecha item a item.
• O fim da task é um número. O Quality Score bloqueia a task se algum eixo estiver vermelho. Vermelho volta para implementação; passou do teto de tentativas, escala para o humano. (Como esse número é montado está no artigo sobre medição.)

Como são as mensagens de verdade

O diagrama mostra quem fala com quem; falta mostrar o quê. Dois exemplos ilustrativos (nomes de arquivo e linhas são fictícios), no formato que o harness usa.

Uma delegação do orquestrador ao dev: repare nos cinco blocos (objetivo, entradas, saída, ferramentas e limites).

Objetivo: implementar a validação de CNPJ no cadastro de fornecedores (task T3).

Entradas (caminhos, não conteúdo):
  .specs/features/fornecedores/spec.md
  .specs/features/fornecedores/design.md
  .specs/features/fornecedores/tasks.md  (só a task T3)
  src/Fornecedores/Domain/

Saída esperada: diff aplicado + lista de arquivos tocados
  + resumo de até 10 linhas do que foi feito.

Ferramentas e skills: rodar a skill de verificação de premissas antes de
  codar; usar build e testes para gerar evidência.

Limites: não alterar o contrato da API definido no design.md;
  não implementar outras tasks; não adicionar bibliotecas novas.

A devolução do crítico: específica, com local e motivo. Nunca "parece bom", nunca "melhorar a qualidade".

Fase: Implementação — task T3 (validação de CNPJ)
Veredito: NÃO APROVADO — 3 pendências

1. [Bloqueante] Cnpj.cs:27
   A máscara "12.345.678/0001-95" é rejeitada, mas a spec (RN-02) exige
   aceitar o CNPJ com e sem máscara. Não há teste para esse caso.

2. [Bloqueante] FornecedorService.cs:64
   CNPJ duplicado lança exceção. O padrão do projeto é devolver um
   Result com erro de negócio, não usar exceção para fluxo previsível.

3. [Menor] mensagem de erro sem acento
   "CNPJ invalido" deve ser "CNPJ inválido" (texto visível ao usuário).

O item 3 é pequeno de propósito: o crítico não perdoa o trivial nem trata o trivial como bloqueante. Classificar a gravidade evita que a lista vire ruído.

Onde dá errado

Multiagente falha de jeitos previsíveis. Conhecer os modos de falha vale mais do que conhecer o fluxo ideal:

O custo do multiagente

Dividir em vários agentes não é de graça. Você paga em tokens (cada agente carrega o seu contexto), em latência (fases em sequência esperam umas às outras) e em atenção humana (alguém lê os relatórios e resolve as escaladas). O custo só compensa quando o retrabalho evitado vale mais do que ele consome, e essa conta muda a cada modelo novo, tema do artigo sobre harness.

A régua que uso para manter o custo proporcional:

• Feature pequena (1 a 2 arquivos, sem ambiguidade) → 1 agente.
• Multi-stack independente (ex.: backend e frontend sem contrato compartilhado) → 1 agente por stack.
• Nunca mais de 4 agentes na mesma fase; acima disso, quebre em sub-fases sequenciais.

Prós e contras, sem maquiagem