🎯 Supervisor Pattern
O Supervisor Pattern e o padrao de orquestracao mais usado em sistemas multiagentes em 2026. Um agente central — o supervisor — recebe a tarefa do usuario, analisa, decompoe em subtarefas e roteia cada subtarefa para o agente especialista mais adequado. Apos os agentes completarem suas tarefas, o supervisor sintetiza os resultados e entrega a resposta final.
O Supervisor e o padrao "default" porque combina controle centralizado com execucao distribuida. O supervisor mantem a visao geral do projeto e garante que tudo converge para o objetivo, enquanto os agentes especializados focam em suas areas de expertise. CrewAI usa esse padrao implicitamente, LangGraph permite implementa-lo explicitamente, e o Sisyphus do OMO e um supervisor sofisticado.
💡 Anatomia do Supervisor
Os componentes do padrao Supervisor:
- • Supervisor agent: Recebe tarefa, decompoe, roteia e sintetiza — o 'cerebro' do swarm
- • Worker agents: Especialistas que executam subtarefas — cada um no seu dominio
- • Routing logic: Como o supervisor decide qual worker acionar — regras ou LLM
- • Result synthesis: Combinar outputs dos workers num resultado coerente
📊 Vantagens e riscos
- Vantagem: Controle total — supervisor garante consistencia e qualidade
- Vantagem: Facil de debugar — supervisor centraliza logs e decisoes
- Risco: Single point of failure — se supervisor falha, todo o swarm para
- Risco: Gargalo de performance — tudo passa pelo supervisor, que pode virar bottleneck
✅ Maker-Checker Pattern
O Maker-Checker Pattern (tambem chamado de Generator-Verifier) e um padrao onde um agente cria e outro verifica. O Maker gera o output (codigo, texto, analise) e o Checker avalia a qualidade, corretude e seguranca. Se o Checker rejeita, o Maker recebe feedback e tenta novamente. Esse ciclo continua ate o Checker aprovar ou um limite de tentativas ser atingido.
A forca desse padrao esta no uso de modelos diferentes para Maker e Checker. Se o Maker usa Claude e o Checker usa GPT, os pontos cegos de um modelo sao compensados pelo outro — o que um deixa passar, o outro pega. Esse principio de heterogeneidade anti-blindspot e validado empiricamente: revisao cross-model detecta 30-40% mais bugs do que revisao com o mesmo modelo.
💡 Como funciona o Maker-Checker
O ciclo de criacao e verificacao:
- • Maker: Gera o output — codigo, texto, plano, analise
- • Checker: Avalia qualidade, corretude, seguranca — aprova ou rejeita com feedback
- • Loop: Se rejeitado, Maker recebe feedback e tenta novamente — ate aprovacao
- • Cross-model: Maker e Checker usam modelos diferentes para maximizar deteccao de erros
📊 Resultados empiricos
- 30-40% mais bugs detectados com revisao cross-model vs mesmo modelo
- Reducao de 60% em erros de producao quando Maker-Checker e aplicado a codigo
- 2-3 iteracoes: Tipicamente, o ciclo converge em 2-3 tentativas
- Custo adicional: ~50% mais tokens, mas qualidade drasticamente superior
🔀 Adaptive Agent Network
O Adaptive Agent Network e um padrao avancado onde agentes se auto-organizam dinamicamente baseado na tarefa recebida. Em vez de roteamento fixo (sempre envie codigo para o coder), o sistema avalia as capacidades de cada agente disponivel e roteia para o mais adequado no momento. Se um agente esta sobrecarregado, outro assume. Se uma nova capacidade e necessaria, um agente pode ser instanciado sob demanda.
Esse padrao e inspirado nos principios de inteligencia de enxame que vimos na Trilha 1: auto-organizacao, emergencia e descentralizacao. Na pratica, e mais complexo de implementar do que o Supervisor Pattern, mas oferece resiliencia e flexibilidade superiores. Se um agente falha, o sistema se reorganiza sem intervencao. Se a carga aumenta, agentes adicionais sao recrutados automaticamente.
💡 Principios do Adaptive Network
Como agentes se auto-organizam:
- • Capability matching: Sistema avalia capacidades de cada agente e roteia para o melhor match
- • Dynamic scaling: Novos agentes instanciados sob demanda quando carga aumenta
- • Self-healing: Se agente falha, tarefas redistribuidas automaticamente
- • Emergent behavior: Padroes de colaboracao surgem da interacao, nao de regras pre-definidas
📊 Quando usar
- Ideal: Cenarios imprevisiveis onde tipos de tarefa variam muito
- Ideal: Sistemas que precisam de alta disponibilidade — sem single point of failure
- Evitar: Quando previsibilidade e auditabilidade sao mais importantes que flexibilidade
- Complexidade: Significativamente mais complexo que Supervisor — use apenas quando necessario
🔗 Mediator Pattern
O Mediator Pattern resolve um problema especifico: o que acontece quando agentes discordam? Num sistema com Maker-Checker, o Maker pode insistir que seu codigo esta correto enquanto o Checker insiste que tem um bug. Quem tem razao? O Mediator e um terceiro agente que analisa ambos os lados, busca evidencias adicionais e toma a decisao final.
O Mediator pode usar diferentes estrategias de resolucao: voting (consultam-se mais agentes e a maioria vence), evidence-based (o Mediator busca dados concretos — roda testes, verifica documentacao), hierarchical (um modelo mais potente e usado como arbitro) ou compromise (o Mediator encontra uma solucao que incorpora o melhor de ambos os lados). Em todos os casos, a decisao e registrada para auditoria.
💡 Resolucao de conflitos
Como o Mediator decide:
- • Voting: Mais agentes opinam — maioria decide (bom para decisoes de design)
- • Evidence-based: Mediator busca provas concretas — testes, benchmarks, documentacao
- • Hierarchical: Modelo mais potente (ex: Opus) arbitras decisoes de modelos menores
- • Compromise: Mediator sintetiza o melhor de ambos os lados numa solucao hibrida
📊 Cenarios de uso
- Code review conflitante: Reviewer diz que tem bug, Coder diz que nao — Mediator roda testes
- Design decisions: Dois arquitetos propoem abordagens diferentes — Mediator avalia trade-offs
- Dados contraditorios: Duas fontes de dados discordam — Mediator busca terceira fonte
- Prioridade: Agente de velocidade vs agente de qualidade — Mediator define o equilibrio
📦 Regra das tres balas (opencode-swarm)
A regra das tres balas e uma heuristica pratica criada no projeto opencode-swarm: se voce nao consegue descrever uma tarefa em tres bullet points — TASK (o que fazer), FILE (em quais arquivos) e CONSTRAINT (restricoes) — a tarefa e grande demais para um unico agente e precisa ser decomposta.
Essa heuristica resolve um problema real: agentes perdem qualidade rapidamente quando recebem tarefas muito grandes. Uma tarefa como "refatore todo o modulo de autenticacao" e ambigua demais — pode significar dezenas de mudancas em dezenas de arquivos. A regra das tres balas forca a decomposicao: "TASK: extrair validacao de JWT para modulo separado, FILE: auth.py e jwt_utils.py, CONSTRAINT: manter compatibilidade com API existente". Isso e especifico o suficiente para um agente executar com precisao.
💡 A heuristica na pratica
Como aplicar a regra das tres balas:
- • TASK: Uma acao especifica e verificavel — 'implementar funcao X', 'corrigir bug Y'
- • FILE: Maximo 2 arquivos — se precisa de mais, decomponha em subtarefas
- • CONSTRAINT: Restricoes claras — 'manter backward compatibility', 'sem dependencias novas'
- • Se nao cabe: A tarefa precisa ser decomposta pelo orquestrador antes de delegar
📊 Impacto na qualidade
- Tarefas atomicas: Taxa de sucesso de 85%+ quando a regra e seguida
- Tarefas grandes: Taxa de sucesso cai para 30-40% sem decomposicao
- Max 2 arquivos: Agentes que modificam mais de 2 arquivos simultaneamente geram conflitos
- Orquestrador: A decomposicao e responsabilidade do supervisor, nao do worker
🏗️ Supervisores de supervisores
Para projetos muito grandes — centenas de arquivos, dezenas de features, multiplas equipes — um unico supervisor nao e suficiente. A solucao e criar hierarquias de supervisores: um supervisor principal coordena supervisores de area, que por sua vez coordenam agentes workers. Isso cria um sistema Hierarchical Multi-Agent System (MAS) com camadas de delegacao.
Na pratica, voce pode ter um Project Supervisor que coordena um Frontend Supervisor (com agentes de React, CSS, testes de UI), um Backend Supervisor (com agentes de API, banco de dados, autenticacao) e um DevOps Supervisor (com agentes de CI/CD, deploy, monitoramento). Cada supervisor de area tem autonomia total no seu dominio, e o Project Supervisor garante que tudo converge para o objetivo do projeto.
💡 Hierarquia multinivel
Como supervisores se organizam em camadas:
- • Project Supervisor: Visao geral, decomposicao em areas, integracao final
- • Area Supervisors: Autonomia no dominio, decomposicao em tarefas atomicas para workers
- • Worker agents: Executam tarefas atomicas — uma funcao, um componente, um teste
- • Delegation chains: Tarefa flui top-down, resultados fluem bottom-up
📊 Escala e limites
- 2 niveis: Suficiente para 80% dos projetos — supervisor + workers
- 3 niveis: Para projetos grandes — project + area + workers
- 4+ niveis: Raramente necessario — overhead de coordenacao pode superar beneficios
- Regra pratica: Cada supervisor deve coordenar no maximo 5-7 agentes diretos
📚 Resumo do Modulo
Proximo:
Modulo 2.8 - Swarms Framework e outros