Padrão Supervisor (Multiagente Hierárquico)

1. Visão geral do conceito e o problema sistêmico

Ao criar sistemas multiagente, os desenvolvedores frequentemente enfrentam desafios de coordenação. Se os agentes simplesmente trocam mensagens em um chat de grupo (Group Chat):

• Perda de foco: Os agentes começam a comentar as falas dos colegas, esquecendo-se da solicitação original do usuário.
• Crescimento descontrolado do contexto: Cada agente visualiza todo o log de mensagens dos outros, resultando em consumo quadrático de tokens e degradação da atenção.
• Ausência de determinismo: Não é possível garantir que a tarefa foi realmente resolvida, em vez de apenas silenciada.

O Supervisor Pattern implementa uma hierarquia de engenharia clássica: um orquestrador central (Supervisor) interage com o usuário, constrói o plano de execução, divide-o em tarefas isoladas, atribui-as aos agentes especializados (Specialist Workers) e agrega o resultado final.

2. Taxonomia arquitetural e modelo mental

                       ┌─────────────────────────┐
                       │       USER PROMPT       │
                       └────────────┬────────────┘
                                    │
                                    ▼
                       ┌─────────────────────────┐
                       │    SUPERVISOR AGENT     │
                       │  (State, Plan & Router) │
                       └───┬────────┬────────┬───┘
                           │        │        │
           ┌───────────────┘        │        └───────────────┐
           │ Task A                 │ Task B                 │ Task C
           ▼                        ▼                        ▼
┌────────────────────┐   ┌────────────────────┐   ┌────────────────────┐
│   RESEARCH AGENT   │   │    CODER AGENT     │   │     QA AGENT       │
│ (Search, Docs, RAG)│   │ (AST, Git, Patch)  │   │(Evals, Tests, Lint)│
└──────────┬─────────┘   └──────────┬─────────┘   └──────────┬─────────┘
           │                        │                        │
           └───────────────┐        │        ┌───────────────┘
                           ▼        ▼        ▼
                       ┌─────────────────────────┐
                       │   AGGREGATED ARTIFACT   │
                       └─────────────────────────┘

1. State Machine / Router: O Supervisor mantém uma máquina de estados finita. Após cada etapa, ele avalia: Concluído? -> Retorna a resposta ao usuário, ou Próximo passo necessário? -> Chama o worker correspondente.
2. Task Encapsulation: Cada worker recebe apenas as informações de entrada necessárias e seu próprio escopo de ferramentas (Tooling Scope). Por exemplo, o Coder Agent não tem acesso à busca no Google, enquanto o Research Agent não pode modificar o sistema de arquivos.

3. Pipeline técnico e mecânica interna

Algoritmo de operação do supervisor:

1. Análise da tarefa de entrada: O modelo do supervisor é chamado com um system prompt que descreve as competências de cada worker, junto com um esquema de retorno de decisões (Function Calling / Structured Output).
2. Geração da decisão de roteamento:

   {
     "next_worker": "coder_agent",
     "task_description": "Implement authentication middleware in src/auth.ts using Better Auth",
     "expected_artifacts": ["src/auth.ts"]
   }
   

3. Execução isolada do worker: O orquestrador inicializa o contexto do worker, dispara seu ciclo autônomo e aguarda o retorno do resultado.
4. Controle de qualidade (Evaluation Gate): Ao receber o resultado, o supervisor pode aprová-lo, encaminhá-lo a um agente de QA para testes ou devolvê-lo ao worker para correções (Self-Correction Loop).

4. Cenários práticos de engenharia em produção

01. Desenvolvimento autônomo de funcionalidades complexas

O usuário solicita: "Adicione ao projeto exportação de relatórios em PDF com gráficos". O Supervisor chama:

1. Research Worker — localiza a biblioteca adequada e verifica a licença.
2. Backend Worker — cria o API endpoint e o gerador de relatório.
3. Frontend Worker — adiciona o botão na UI e o indicador de carregamento.
4. Tester Worker — executa os testes Playwright.

02. Triagem e resolução de incidentes de segurança

O Supervisor reage a um alert no Sentry, passa o stack trace para o agente de diagnóstico, valida o hotfix proposto pelo agente de testes e cria um pull request.

5. Armadilhas comuns, erros típicos e segurança

• Deadlock Loops (Looping entre supervisor e worker): O supervisor considera a tarefa incompleta e a devolve ao worker. O worker retorna o mesmo código. Solução: definir max_iterations = 5 e lançar um erro para intervenção humana.
• Context Bleed (Poluição da memória do supervisor): Se um worker retornar 10.000 linhas de código, o contexto do supervisor será rapidamente sobrecarregado. Os workers devem salvar o código no sistema de arquivos e retornar apenas o status e o diff.
• Single Point of Failure: Se o modelo do supervisor alucinar e escolher o worker errado, todo o sistema segue por um caminho incorreto. É essencial implementar verificações claras de invariantes antes das chamadas.

6. Conclusão estratégica para o engenheiro de 2026

O Supervisor Pattern é a base para o desenvolvimento industrial confiável de sistemas multiagente. Em vez de confiar em uma "colaboração mágica" entre vários agentes em um chat aberto, o supervisor garante despachamento de engenharia claro, isolamento de contextos e controle de custos.