4.5 — Topologia Supervisor e Delegação entre Agentes Pares: Orquestração Multi-Agente além do Paralelismo Temporário

Objetivo da Aula

Diferenciar subagente temporário (efêmero, micro-tarefa) de agente par de longa duração (persistente, especialista)

Desenhar a topologia supervisor: um agente coordenador delegando para agentes especializados com escopo próprio

Projetar um protocolo de comunicação entre supervisor e pares baseado em mensagens estruturadas, não em contexto compartilhado bruto

Avaliar quando usar topologia supervisor/pares em vez de paralelismo temporário (4.4) ou loop investigativo único (4.3)

Desenhar a etapa de consolidação, em que o supervisor agrega resultados de múltiplos especialistas em uma resposta final coerente

Por que isso importa

O capítulo anterior resolveu paralelismo para tarefas de vida curta: instancia, executa, descarta. Mas nem todo sistema multi-agente é feito de tarefas descartáveis. Considere um sistema que mantém, ao longo de um projeto inteiro, um agente especializado em revisão de código, outro em geração de testes, outro em documentação — cada um com seu próprio histórico acumulado de decisões, seu próprio system prompt afinado para aquele domínio, e uma responsabilidade que não termina depois de uma única chamada.

Esses não são subagentes efêmeros. São agentes pares de longa duração, cada um dono de uma fatia persistente de responsabilidade, coordenados por um agente supervisor que decide para qual especialista delegar cada parte do trabalho e como consolidar os resultados numa entrega final coerente. É uma topologia diferente, resolvendo um problema diferente: não “como isolar ruído de uma micro-tarefa”, mas “como distribuir um trabalho complexo entre pontos de responsabilidade especializados e manter o resultado coeso”.

Impacto direto no seu trabalho: confundir essas duas topologias é um erro comum e caro. Tratar um especialista de longa duração como se fosse descartável perde o valor do contexto acumulado que ele carrega (a memória do agente de revisão de código sobre convenções do projeto, por exemplo). Tratar uma micro-tarefa como se precisasse de um agente par persistente cria overhead de manutenção — system prompt, escopo, ciclo de vida — para algo que deveria nascer e morrer numa única execução.

Conceitos Fundamentais

Subagente efêmero vs. agente par de longa duração

A pergunta que separa as duas topologias não é "quantos agentes", é "esses agentes têm identidade que sobrevive além de uma tarefa". Um agente de revisão de código que lembra que o time decidiu, na semana passada, banir um determinado padrão de código é um par de longa duração. Um agente que resume oito páginas web e nunca mais é chamado de novo é um subagente efêmero.

Anatomia da topologia supervisor

Agente Supervisor

• Decompõe a tarefa
• Delega para os agentes pares especializados
• Consolida os resultados

O supervisor delega para três agentes pares, cada um com escopo, system prompt e memória próprios:

Agente de Revisão de Código

• Escopo, system prompt e memória próprios

Agente de Testes

• Escopo, system prompt e memória próprios

Agente de Documentação

• Escopo, system prompt e memória próprios

Cada agente par tem escopo e system prompt próprios — o agente de revisão de código não recebe as mesmas instruções que o agente de documentação, porque o julgamento que cada um precisa exercer é diferente. O supervisor não executa a tarefa técnica diretamente; sua responsabilidade é decompor o objetivo em subtarefas, decidir qual especialista atende cada uma, e depois consolidar os resultados individuais numa saída única e coerente.

Protocolo de comunicação: mensagens, não contexto compartilhado

Um erro comum ao montar essa topologia é dar a todos os agentes pares acesso ao mesmo contexto bruto compartilhado — na prática, isso reintroduz o problema de context saturation do capítulo anterior, agora multiplicado por N agentes lendo o mesmo volume de ruído. O padrão correto é comunicação por mensagens estruturadas: o supervisor envia a cada par só o que é relevante para a subtarefa dele, e recebe de volta um resultado estruturado, não o histórico de raciocínio interno do par.

Supervisor → Agente de Testes:
  mensagem = {
    tarefa: "gerar testes para o módulo de autenticação
              alterado neste PR",
    contexto_minimo: { diff: "...", arquivos_afetados: [...] },
    contrato_de_retorno: { testes_gerados: [...],
                            cobertura_estimada: float,
                            avisos: [...] }
  }

Agente de Testes → Supervisor:
  resposta = {
    testes_gerados: ["test_login_invalido", "test_token_expira"],
    cobertura_estimada: 0.84,
    avisos: ["função reset_senha não tem teste — sem
              fixture de e-mail disponível no ambiente"]
  }

O supervisor nunca precisa saber como o agente de testes chegou àquele resultado — só precisa do contrato de retorno. Essa fronteira de mensagem estruturada é o que permite trocar a implementação interna de um agente par (mudar seu modelo, seu prompt, sua lógica) sem afetar o supervisor ou os outros pares, desde que o contrato de mensagem seja mantido.

Memória persistente: o que torna um par diferente de uma instância nova

A característica que mais distingue um agente par de um subagente efêmero é a memória que sobrevive entre chamadas. Sem essa memória, "agente de longa duração" seria só um nome — na prática, seria um agente recriado do zero a cada delegação, idêntico a um subagente. O que dá substância à persistência é um estado próprio que o agente par acumula e consulta em delegações futuras.

estado_persistente(agente_revisao_codigo) = {
    convencoes_aprendidas: [
        "time decidiu banir uso de 'any' em TypeScript
         (decisão de 2026-05-12)",
        "PRs que tocam módulo de pagamento exigem
         2 aprovações, não 1"
    ],
    historico_de_decisoes: [
        { pr: 342, decisao: "aprovado com ressalva",
          motivo: "cobertura de teste abaixo do padrão,
                    mas prazo urgente aprovado pelo tech lead" }
    ]
}

# na delegação seguinte, o supervisor não precisa reexplicar
# essas convenções — o agente par já as carrega
mensagem = {
    tarefa: "revisar PR 358, módulo de pagamento",
    # sem necessidade de reafirmar a regra de 2 aprovações:
    # o agente par já sabe, é parte do seu estado acumulado
}

Esse estado é o que justifica o custo adicional de manter um agente par vivo em vez de recriá-lo a cada tarefa: o valor cresce com o tempo, na medida em que o agente acumula contexto de domínio que um agente recém-instanciado precisaria reconstruir — ou, pior, nunca teria acesso.

Aprofundamento Técnico

Consolidação: o supervisor como agregador, não pass-through

A etapa mais frequentemente subestimada dessa topologia é a consolidação final. Um supervisor mal desenhado apenas concatena as respostas dos pares e entrega isso como resultado — o que empurra para o usuário final o trabalho de reconciliar informações potencialmente conflitantes ou redundantes entre especialistas diferentes.

Consolidação ruim (pass-through):
  resultado_final = [resposta_revisao, resposta_testes,
                      resposta_documentacao]
  → usuário recebe 3 relatórios desconexos, precisa
    reconciliar sozinho

Consolidação real (agregação com julgamento):
  função consolidar(respostas_dos_pares):
      conflitos = detectar_inconsistencias(respostas_dos_pares)
      se conflitos:
          resolver_ou_sinalizar(conflitos)   # ex: revisão de
              código apontou risco de segurança que o
              agente de testes não cobriu — supervisor
              sinaliza a lacuna explicitamente

      retornar {
          resumo_executivo: sintetizar(respostas_dos_pares),
          detalhes_por_area: respostas_dos_pares,
          lacunas_identificadas: conflitos
      }

A consolidação real exige que o supervisor tenha visibilidade sobre os contratos de retorno de todos os pares simultaneamente — é por isso que a topologia supervisor não é simétrica como o fan-out/fan-in do capítulo anterior: existe um ponto central com responsabilidade explícita de reconciliar, não apenas agregar.

Falhas de coordenação: resultados conflitantes e deadlock

Dois modos de falha são específicos dessa topologia. O primeiro é resultado conflitante: dois pares chegam a conclusões incompatíveis sobre a mesma questão (o agente de revisão aprova uma mudança que o agente de segurança rejeitaria, se tivesse sido consultado sobre ela). A mitigação é o supervisor tratar sobreposição de escopo como sinal de alerta, não como redundância inofensiva — se dois pares opinam sobre a mesma decisão, o design de escopo provavelmente tem uma lacuna.

O segundo é deadlock de dependência: o agente de testes espera o diff final do agente de revisão de código, que por sua vez espera a lista de testes existentes do agente de testes para avaliar cobertura antes de aprovar. Topologias supervisor devem ser desenhadas com dependências explícitas e resolvidas pelo supervisor — nunca dois pares aguardando um ao outro diretamente, sem o supervisor mediando a ordem.

Errado (dependência circular entre pares):
  Agente Revisão espera → resultado de Agente Testes
  Agente Testes espera  → resultado de Agente Revisão
  → deadlock

Correto (supervisor resolve ordem):
  Supervisor decide ordem: Testes primeiro (cobertura básica),
    depois Revisão (usa cobertura como um dos critérios)
  → sem dependência circular, pares nunca esperam um pelo outro
    diretamente

Quando a topologia supervisor é overkill

Manter agentes pares de longa duração tem custo estrutural mesmo quando eles não estão processando nenhuma tarefa: system prompt próprio para versionar, memória persistente para armazenar e proteger, e a complexidade adicional de um protocolo de mensagens formal entre supervisor e cada par. Esse custo só compensa quando o domínio realmente se beneficia de especialização contínua — quando a memória acumulada de um par muda a qualidade das decisões futuras, como no exemplo do agente de revisão de código que lembra convenções do time.

Para domínios que não têm esse componente cumulativo — cada tarefa é independente da anterior, não existe convenção de time nem histórico relevante a acumular — a topologia supervisor adiciona overhead sem contrapartida. Um sinal prático de alerta: se você notar que os agentes pares do seu sistema nunca consultam o próprio estado persistente ao decidir algo, a persistência não está gerando valor, e subagentes efêmeros (4.4) resolveriam o mesmo problema com menos complexidade de manutenção.

As três topologias desta parte, lado a lado

Com essas três topologias — loop investigativo, subagentes efêmeros e supervisor/pares — e a base de skills modulares e catálogo compartilhado das duas primeiras aulas desta parte, você tem o vocabulário completo de composição multi-agente do Nível 2 desta série. A Parte 5 muda de eixo: com sistemas multi-agente rodando em produção, a pergunta deixa de ser "como orquestrar" e passa a ser "quanto isso custa e como conter a inflação de tokens que cada uma dessas topologias, sem governança, tende a gerar".