🏗️ Hierarquica (Supervisor/Worker)
A arquitetura hierarquica, tambem conhecida como Supervisor/Worker ou hub-and-spoke, e o padrao mais comum e intuitivo de swarms. Nela, um agente supervisor (orquestrador) ocupa o centro do sistema e delega tarefas para agentes trabalhadores (workers) especializados. O supervisor recebe a tarefa do usuario, analisa o que precisa ser feito, decide quais workers acionar, distribui subtarefas e coleta os resultados. E exatamente como uma equipe corporativa: o gerente de projeto distribui tarefas, os especialistas executam e reportam de volta.
A grande vantagem dessa arquitetura e a previsibilidade e controle. O supervisor tem visao global do progresso, pode repriorizar tarefas, detectar falhas e realocar trabalho. Em sistemas como CrewAI e LangGraph, esse padrao e implementado nativamente. O supervisor tipicamente usa um modelo mais potente (Claude Opus, GPT-5.3) para raciocinio complexo, enquanto os workers podem usar modelos mais leves e baratos. A desvantagem e que o supervisor pode se tornar um gargalo: se ele falha ou fica sobrecarregado, todo o swarm para.
💡 Anatomia do Padrao Hub-and-Spoke
O modelo hierarquico segue um fluxo centralizado onde toda comunicacao passa pelo supervisor:
- • Supervisor (Hub): Recebe a tarefa, cria plano de execucao, seleciona workers, delega subtarefas e agrega resultados finais
- • Workers (Spokes): Agentes especializados que recebem subtarefas atomicas, executam com foco total e retornam o resultado ao supervisor
- • Delegacao inteligente: O supervisor escolhe o worker certo baseado no tipo de tarefa — codigo vai para o Coder, revisao para o Reviewer, testes para o Tester
- • Controle centralizado: O supervisor monitora progresso, detecta falhas e pode relancar tarefas ou mudar o plano em tempo real
📊 Onde o hierarquico brilha
- Adocao: Mais de 60% dos swarms em producao usam alguma variante hierarquica — e o padrao mais testado e confiavel
- Frameworks: CrewAI (manager_llm), LangGraph (supervisor node), AutoGen (GroupChat manager) — todos oferecem suporte nativo
- Ideal para: Projetos com equipe definida de agentes, tarefas decomposiveis e necessidade de controle e auditoria
- Risco principal: Single point of failure — se o supervisor trava, nenhum worker pode continuar. Mitigacao: health checks e fallback supervisors
🔗 Pipeline sequencial
Na arquitetura de pipeline sequencial, os agentes estao organizados em uma cadeia (chain) onde cada um processa uma etapa e passa o resultado para o proximo. E como uma linha de montagem industrial: a peca entra crua no inicio, cada estacao adiciona valor e no final sai o produto acabado. No contexto de swarms de codigo, um pipeline tipico seria: Explorer (escaneia codebase) → Architect (projeta solucao) → Coder (implementa) → Reviewer (revisa) → Tester (testa) → Docs (documenta).
O conceito de handoff e central nessa arquitetura: quando um agente termina sua tarefa, ele "passa o bastao" para o proximo, transferindo seu contexto e resultados. Em pipelines avancados, existem gates entre etapas — checkpoints de qualidade que precisam ser aprovados para o fluxo continuar. Por exemplo, o codigo produzido pelo Coder so avanca para o Tester se o Reviewer aprovar. Se reprovar, o fluxo retorna ao Coder com feedback para correcao. Esse mecanismo de gated pipeline e o que garante qualidade em sistemas como o OpenCode Swarm.
💡 Elementos do Pipeline Sequencial
Um pipeline sequencial robusto combina tres elementos que garantem fluxo ordenado e qualidade:
- • Chain (cadeia): Agentes conectados em sequencia fixa — a saida de um e a entrada do proximo. A ordem importa porque cada etapa depende da anterior
- • Handoff (transferencia): O mecanismo de passagem de contexto entre agentes — inclui o resultado produzido, metadados e instrucoes para a proxima etapa
- • Gates (portoes de qualidade): Checkpoints entre etapas que validam se o resultado e aceitavel antes de prosseguir. Se reprovar, o fluxo retorna a etapa anterior
- • Feedback loops: Quando um gate rejeita, o agente anterior recebe feedback especifico sobre o que corrigir — criando um ciclo de melhoria dentro do pipeline
📊 Pipeline na pratica
- OpenCode Swarm: Pipeline de 8 etapas (Explorer → SME → Architect → Critic → Coder → Reviewer → Test → Docs) com gates entre cada transicao
- Vantagem principal: Simplicidade e previsibilidade — facil de debugar porque voce sabe exatamente qual etapa falhou
- Desvantagem principal: Lentidao — cada agente espera o anterior terminar, mesmo quando poderia trabalhar em paralelo
- Quando usar: Tarefas com dependencias estritas entre etapas, quando qualidade e mais importante que velocidade, e quando cada etapa modifica o mesmo artefato
🔀 Paralelo (Fan-out/Fan-in)
A arquitetura paralela, conhecida como fan-out/fan-in, e o padrao que maximiza velocidade. Em vez de processar etapas uma a uma, o orquestrador identifica tarefas que sao independentes entre si e as dispara simultaneamente para multiplos agentes. Cada agente trabalha em sua tarefa sem esperar pelos outros, e quando todos terminam, os resultados sao mesclados (merge) em um resultado final coerente. E como uma equipe de jornalistas cobrindo diferentes aspectos de uma mesma historia: cada um investiga seu angulo em paralelo e o editor junta tudo no final.
O grande desafio da execucao paralela e a concorrencia: quando dois agentes tentam modificar o mesmo arquivo simultaneamente, conflitos surgem. Sistemas maduros resolvem isso com zonas seguras — cada agente recebe uma area exclusiva de trabalho (arquivos ou pastas especificas) e nenhum outro pode tocar nessa area. O oh-my-openagent (OMO), por exemplo, despacha agentes paralelos em categorias separadas (Frontend, Backend, Database) onde cada agente trabalha em arquivos distintos, eliminando o risco de conflito. A fase de merge no final reconcilia os resultados.
💡 Fan-out/Fan-in: o padrao
A execucao paralela segue um fluxo de dispersao e convergencia:
- • Fan-out (dispersao): O orquestrador identifica N tarefas independentes e dispara N agentes simultaneamente — cada um recebe sua tarefa e contexto isolado
- • Execucao concorrente: Todos os agentes trabalham ao mesmo tempo em suas respectivas tarefas, sem depender uns dos outros
- • Fan-in (convergencia): Quando todos terminam, os resultados sao coletados e mesclados em um resultado unificado pelo orquestrador
- • Zonas seguras: Cada agente tem uma area exclusiva de trabalho (arquivos, pastas, modulos) para evitar conflitos de concorrencia
📊 Paralelo na pratica
- Ganho de velocidade: Com 4 agentes paralelos, tarefas que levariam 40 minutos sequencialmente podem ser concluidas em 10-15 minutos
- Custo: Execucao paralela consome mais tokens por minuto (multiplas chamadas de API simultaneas), mas o custo total pode ser similar porque cada agente trabalha com contexto menor
- Risco de conflito: Sem zonas seguras, dois agentes editando o mesmo arquivo simultaneamente geram merge conflicts e codigo inconsistente
- Melhor caso: Tarefas genuinamente independentes — implementar 5 endpoints de API diferentes, escrever testes para modulos distintos, documentar componentes separados
🕸️ Peer Mesh (descentralizado)
A arquitetura Peer Mesh (ou mesh descentralizado) e o padrao mais radical: nao ha supervisor central. Os agentes colaboram diretamente entre si, negociando tarefas, compartilhando resultados e se auto-organizando sem que nenhum deles tenha autoridade sobre os demais. Cada agente e um "par" (peer) com capacidade de iniciar trabalho, pedir ajuda a outros agentes e contribuir para o objetivo coletivo. E o padrao mais proximo da inteligencia de enxame biologica original — como formigas que se coordenam sem rainha.
A grande vantagem do mesh e a resiliencia: se um agente falha, os outros continuam operando normalmente porque ninguem depende de um ponto central. Alem disso, o sistema e inerentemente escalavel — adicionar mais agentes nao cria gargalo no supervisor porque nao ha supervisor. A desvantagem e a complexidade de coordenacao: sem controle central, garantir que dois agentes nao facam a mesma tarefa ou que nenhuma tarefa fique sem dono e um desafio significativo. Por isso, o mesh puro e relativamente raro em producao; ele e mais comum como componente dentro de arquiteturas hibridas.
💡 Principios do Mesh Descentralizado
O mesh descentralizado se apoia em tres propriedades emergentes que dispensam controle central:
- • Auto-organizacao: Agentes decidem autonomamente que tarefas assumir com base em suas capacidades e na disponibilidade de trabalho
- • Comunicacao peer-to-peer: Agentes se comunicam diretamente entre si via protocolos como A2A (Agent-to-Agent) sem intermediario
- • Resiliencia: Nenhum ponto unico de falha — se um agente cai, os demais redistribuem o trabalho automaticamente
- • Emergencia: O comportamento coletivo inteligente surge das interacoes locais entre agentes, sem ser programado explicitamente
📊 Mesh na pratica
- Adocao: Menos de 10% dos swarms em producao usam mesh puro — e mais comum como sub-padrao dentro de arquiteturas hibridas
- Protocolo A2A: O Google Agent-to-Agent Protocol facilita comunicacao direta entre agentes de diferentes plataformas — essencial para mesh cross-platform
- Casos de uso: Sistemas de monitoramento distribuido, swarms de pesquisa exploratoria onde cada agente investiga uma direcao diferente autonomamente
- Desafio principal: Coordenacao — sem supervisor, quem garante que todas as tarefas foram feitas e que nenhuma foi duplicada? Requer mecanismos de consenso
🔄 Sequencial vs Paralelo na pratica
Para entender concretamente a diferenca entre sequencial e paralelo, nada melhor do que comparar dois sistemas reais. O OpenCode Swarm e um exemplo classico de pipeline sequencial: Explorer analisa o codebase, SME (Subject Matter Expert) fornece contexto de dominio, Architect projeta a solucao, Critic avalia o design, Coder implementa, Reviewer revisa, Test Engineer valida e Docs documenta. Cada agente espera o anterior terminar. O resultado e altamente consistente e auditavel, mas o processo completo pode levar 20-40 minutos para uma feature media.
O oh-my-openagent (OMO), por contraste, adota execucao paralela agressiva. O agente Sisyphus (orquestrador) recebe a tarefa, o Prometheus cria o plano e depois despacha agentes Hephaestus em paralelo por categorias: um para Frontend, outro para Backend, outro para Database, todos trabalhando simultaneamente em seus respectivos arquivos. O resultado e velocidade dramaticamente maior — a mesma feature pode ser completada em 8-12 minutos — mas com maior risco de inconsistencias entre os modulos produzidos por agentes diferentes, exigindo uma fase de integracao mais cuidadosa.
💡 Trade-offs: Sequencial vs Paralelo
Cada abordagem tem vantagens e desvantagens claras que determinam quando usar cada uma:
- • Consistencia vs Velocidade: Sequencial garante que cada etapa tem o contexto completo da anterior; paralelo sacrifica isso em troca de velocidade
- • Depuracao: Sequencial e facil de debugar (qual etapa falhou?); paralelo exige monitoramento mais sofisticado de multiplos agentes simultaneos
- • Race conditions: No paralelo, dois agentes podem criar funcoes com nomes conflitantes ou dependencias contraditorias — requer zonas seguras bem definidas
- • Custo: Paralelo usa mais recursos por minuto, mas o custo total pode ser similar ou menor porque cada agente trabalha com contexto mais enxuto
📊 Comparacao OpenCode Swarm vs OMO
- OpenCode Swarm (sequencial): 8 agentes em cadeia, 828+ commits de maturidade, gates de qualidade entre cada etapa, resultado altamente consistente, 20-40 min por feature
- OMO (paralelo): 7 agentes com execucao paralela por categoria, Sisyphus nao para ate terminar, velocidade 2-3x maior, requer fase de integracao cuidadosa
- Quando sequencial vence: Tarefas que modificam um unico arquivo/modulo profundamente, refatoracoes que afetam toda a codebase, migracoes de banco de dados
- Quando paralelo vence: Features que tocam multiplos modulos independentes, criacao de CRUD completo, implementacao simultanea de frontend e backend
🎨 Hibrido: o melhor dos dois mundos
Na pratica, a maioria dos swarms de producao nao usa uma unica arquitetura pura — eles combinam padroes em uma abordagem hibrida que pega o melhor de cada mundo. O padrao mais eficaz e o que chamamos de "Plan Sequential, Execute Parallel": as fases de planejamento e revisao rodam sequencialmente (porque precisam de contexto completo e coerencia), enquanto as fases de execucao rodam em paralelo (porque as tarefas sao independentes entre si). Esse padrao captura a consistencia do sequencial na fase critica (planejamento) e a velocidade do paralelo na fase de producao (execucao).
Em um swarm hibrido tipico, o fluxo seria: (1) Planejamento sequencial — o Explorer escaneia o codebase, o Architect cria o plano detalhado, o Critic valida o plano; (2) Execucao paralela — multiplos Coders implementam diferentes partes do plano simultaneamente em zonas seguras; (3) Revisao sequencial — o Reviewer avalia cada contribuicao, o Tester roda suites de teste, os resultados sao integrados. Os gates de qualidade ficam nas transicoes entre fases: o plano so avanca para execucao se o Critic aprovar, e o codigo so avanca para integracao se o Reviewer aprovar. Esse modelo combina rigor e velocidade de forma equilibrada.
💡 Padrao Plan Sequential → Execute Parallel
O hibrido mais eficaz combina tres fases com transicoes controladas por gates:
- • Fase 1 — Planejamento (sequencial): Explorer → Architect → Critic. Cada etapa depende da anterior. O plano e validado antes de qualquer execucao
- • Gate 1: O Critic avalia o plano. Se aprovado, o plano e dividido em tarefas atomicas independentes para execucao paralela
- • Fase 2 — Execucao (paralela): Multiplos Coders trabalham simultaneamente em tarefas independentes, cada um em sua zona segura de arquivos
- • Fase 3 — Integracao (sequencial): Reviewer valida cada contribuicao, Tester roda testes de integracao, resultados sao mesclados no branch final
📊 Hibrido na pratica
- Ganho real: Swarms hibridos combinam a consistencia do sequencial (95%+ de acuracia no plano) com a velocidade do paralelo (3-4x mais rapido na execucao)
- Gates de qualidade: Funcionam como "semaforos" que impedem codigo ruim de avancar — APPROVED ou NEEDS_REVISION sao as unicas saidas possiveis
- Adocao crescente: Em 2026, a tendencia clara e migrar de sequencial puro para hibrido — os ganhos de velocidade sao grandes demais para ignorar
- Complexidade de implementacao: Hibrido exige mais engenharia (zonas seguras, merge logic, gates) mas o investimento se paga em projetos medios e grandes
📚 Resumo do Modulo
Proximo Modulo:
1.4 - Papeis e Especializacao de Agentes