BMAD-METHOD vs AIOX: comparação técnica entre dois frameworks que NÃO são intercambiáveis

O consenso técnico hoje vende uma falsa equivalência: "todo framework de orquestração de agentes faz a mesma coisa". Não faz. Em uma comparação 5-way recente entre BMAD-METHOD, Paperclip, GSD-2, CrewAI e GSD-1, o BMAD ficou com score SINKRA 82/100 (MAP-READY) — empatado com Paperclip no topo. AIOX é o próprio framework de referência do bench. E mesmo assim, dizer que um substitui o outro é categoria errada.

Este artigo compara BMAD-METHOD e AIOX tecnicamente, com números do bench interno (verificáveis em docs/bench/agent-orchestration-5way/). Não é ranking. É leitura honesta de dois frameworks que resolvem problemas diferentes — e por que confundir os dois custa caro.

Por que essa comparação é mal feita 90% do tempo

O instinto do leitor que pesquisa "BMAD vs AIOX" é encontrar uma tabela com vencedor cravado. Esse instinto é a primeira armadilha.

BMAD-METHOD é, por design, um método de desenvolvimento. Otimiza o ciclo clássico de produto: PM levanta requisito, Architect modela, Dev implementa, QA valida. Os ~8 agentes nomeados (Mary, John, Winston, Amelia, Sally, Murat) cobrem essas fases. A orquestração é um pipeline com Quick Flow alternativo. Funciona muito bem para o que se propõe.

AIOX/SINKRA é, por design, um framework de orquestração cross-domain. Os 473 agentes distribuídos em 53 squads cobrem dev, design, copy, legal, finops, brand, data, ads — tudo que um portfolio de produtos precisa. Os 8 layers (Business, Execution, Product, Services, Infrastructure, Framework, Governance, Evolution) modelam onde o trabalho vive, não quem faz.

Tese: BMAD modela quem faz. AIOX modela onde o trabalho vive. Tratar os dois como produtos competindo no mesmo mercado ignora que a unidade de problema é diferente.

BMAD-METHOD: o que é, em uma definição honesta

Versão: v6.2.2. Licença: MIT. Stack primário: JavaScript. Instalação: npx bmad-method install. Docs: docs.bmad-method.org (Astro). Comunidade: Discord. i18n: francês, mandarim, vietnamita.

O modelo de agente é persona-based. Aproximadamente 8 personas nomeadas, cada uma cobrindo uma fase do ciclo de produto. Configuração via Markdown skills + YAML manifests. O orchestration pattern é Pipeline + Quick Flow — pipeline canônico para projetos completos, quick flow para escopos reduzidos.

O que BMAD faz que poucos fazem:

• Party Mode: múltiplas personas colaborando em uma única sessão. AIOX não tem equivalente.
• Scale-Domain-Adaptive planning: auto-ajusta a profundidade do plano conforme a complexidade do projeto. Reduz overhead em projetos pequenos sem sacrificar rigor em projetos grandes.
• Module ecosystem: BMM, BMB, TEA, BMGD, CIS — extensibilidade documentada por domínio.
• Information density discipline: arquitetura de micro-arquivos com densidade obrigatória de artefato. Evita verbosidade morta.
• bmad-help routing: agente que diz "o que vem a seguir" — context-aware.

Métricas verificáveis no bench: 15 quality gates (todos com numeric thresholds, 5 com veto power), 6 bounded contexts, 35 business rules extraídas em 8 famílias, 10/10 nos 10 Mandamentos SINKRA, compliance META_AXIOMAS de 78,3%.

O que BMAD não cobre — e isso não é defeito, é escopo: governance constitucional, agent authority matrix, multi-tenant isolation, cross-domain (design, copy, legal). Não tenta cobrir.

AIOX/SINKRA: o que é, em uma definição honesta

Versão: v2.1. Licença: Privada. Stack: TypeScript + Python + Shell + YAML. i18n: pt-BR. Comunidade: privada (4 negócios sob a mesma governança).

O modelo de agente é compositional. 473 agentes em 53 squads. Cada squad é uma unidade SINKRA com regras, tasks, workflows, skills e quality gates próprios. Os squads se compõem nos 8 layers — um squad de design opera no L2-tactical, um squad de produto no L3-product, governance no L7-governance.

O que AIOX faz que poucos fazem (e BMAD não faz):

• Constitution de 322 linhas: 11 artigos não-negociáveis enforçados via hooks. Inclui CLI First, Agent Authority, Story-Driven, No Invention, Quality First, Task-First, KISS, Extraction Pipeline No Fallbacks. Hooks bloqueiam push se princípios são violados.
• Agent Authority Matrix: exclusive ops por agente. Apenas @devops dá push e cria PR. Apenas @db-sage roda migrations. Apenas @architect aprova decisão arquitetural. Hooks como enforce-migration-authority.sh bloqueiam violações em runtime.
• Multi-tenant isolation: 4 negócios em workspaces L0-L4 isolados. CODEOWNERS por path. Dados de um negócio não vazam para outro — por design e por hook.
• 53 squads cross-domain: design-system, design-ops, copy, brand, movement, legal, data, finops, customer-success, db-sage, infra, c-level, mais 40+. Não é só dev — é o stack completo de operação de uma holding.

Métricas verificáveis no mesmo bench: 15+ quality gates por squad, 8 layers, 100+ business rules em 15+ famílias, 28 práticas de orquestração distintas (a maior contagem entre todos os frameworks comparados), 16 práticas exclusivas — também a maior do conjunto.

O que AIOX não cobre: open-source, comunidade pública, módulos plug-and-play estilo BMAD, Party Mode multi-agent em sessão única, scale-adaptive planning automático.

Arquitetura comparada: bounded contexts vs layers

Aqui está o ponto técnico mais importante — e o mais ignorado em comparações superficiais.

BMAD organiza o trabalho em 6 bounded contexts. Cada bounded context corresponde a uma fase do ciclo de produto. Brainstorm, PRD, Architecture, Story, Implementation, Quality. O agente certo opera no contexto certo. Domain-Driven Design clássico aplicado ao próprio framework.

AIOX organiza em 8 layers verticais que cortam transversalmente domínios:

1. L1 Business — workspace por negócio (4 businesses)
2. L2 Execution — squads que executam
3. L3 Product — apps e produtos compartilhados
4. L4 Services — adapters (ServiceBus, ClickUp, Google Workspace, ETL)
5. L5 Infrastructure — packages, infra, CI/CD
6. L6 Framework — SYNAPSE, WIS, orchestration
7. L7 Governance — Constitution, CODEOWNERS, hooks
8. L8 Evolution — auto-aprendizado

Diferença filosófica: BMAD modela quem faz o trabalho (a persona certa para a fase). AIOX modela onde o trabalho vive (a layer certa para o tipo de artefato, atravessada por squads de domínio). Não dá para mapear 1-para-1.

Implicação prática: equipe pequena (1-5 devs) cabe melhor em BMAD — bounded contexts cobrem o ciclo todo sem overhead de layers. Portfolio multi-business cabe melhor em AIOX — layers permitem isolar negócios e cruzar domínios sem colisão.

Top 10 práticas-chave comparadas

Esta seção é overview. A matriz exaustiva de 60+ práticas vive no spoke 60 práticas comparadas em detalhe. Aqui ficam as 10 que mais movem decisão:

1. Definição de agente: BMAD ~8 personas nomeadas vs AIOX 473 agentes em 53 squads. Escala distinta porque o problema é distinto.
2. Quality gates: BMAD 15 gates (todos com numeric thresholds, 5 com veto). AIOX 15+ por squad (15 squads × 15 = 225+ gates ativos).
3. Anatomia de tarefa: BMAD usa story template implícito. AIOX exige 8 campos obrigatórios por task, validados em hook.
4. Conformidade SINKRA: BMAD 10/10 nos 10 Mandamentos. AIOX é o próprio framework de referência (não se mede).
5. Constitution: BMAD não tem. AIOX tem 322 linhas + 11 artigos enforçados.
6. Agent Authority Matrix: BMAD não tem. AIOX tem hooks que bloqueiam quem-pode-o-quê.
7. Multi-tenant isolation: BMAD não tem. AIOX isola 4 negócios via L0-L4.
8. Story-driven enforcement: BMAD aplica DoD por story. AIOX aplica via commit hook (modo WARN).
9. Party Mode: BMAD tem (multi-agente em sessão única). AIOX não tem — gap explícito no bench.
10. Information Density discipline: BMAD aplica (micro-arquivos com densidade obrigatória). AIOX aplica parcialmente.

Onde BMAD passa o AIOX (e por que isso importa)

Honestidade técnica primeiro: BMAD tem coisas que AIOX não tem, e fingir que não tem é desserviço.

Party Mode. AIOX hoje opera com um agente por sessão (com chief delegando para subagents em pipeline). BMAD permite múltiplas personas colaborando ao vivo na mesma sessão. Para sessões de brainstorming ou roundtables onde a fricção entre perspectivas é o ponto, BMAD vence.

Module Ecosystem. BMM, BMB, TEA, BMGD, CIS — módulos extensíveis com escopo bem definido. AIOX tem squads scaffolded, mas o modelo de extensibilidade é menos plug-and-play. Em projetos onde o time precisa adicionar uma metodologia inteira (ex.: design thinking) sem fork, BMAD é mais flexível.

Scale-Adaptive Planning. BMAD auto-ajusta a profundidade do plano conforme a complexidade detectada. AIOX exige decisão manual sobre full-flow vs quick-flow. Em projetos com escopo variável e equipe pequena, isso reduz overhead real.

Information Density Discipline. A arquitetura de micro-arquivos com densidade obrigatória de artefato é um padrão que previne documentação morta. AIOX tem regras KISS (anti-overengineering) similares, mas a disciplina de densidade não está formalizada do mesmo jeito.

Honest take: para uma equipe de 1-5 devs fazendo produto de software clássico, BMAD pode entregar mais valor por hora investida do que AIOX. AIOX só compensa quando o problema cresce além do dev-lifecycle.

Onde AIOX passa o BMAD (e por que isso importa)

Do outro lado, AIOX faz coisas que BMAD não faz — e dependendo do problema, isso é decisivo.

Governance Constitucional. 322 linhas de Constitution, 11 artigos não-negociáveis, hooks que bloqueiam push em violação. BMAD tem DoD por story; AIOX tem Constitution + DoD + agent authority + extraction-no-fallbacks + KISS + cross-business isolation — tudo enforçado por hook. Para times que vivem em ambientes regulados ou com múltiplos stakeholders, isso não é overhead — é necessidade.

Agent Authority Matrix. Exclusive ops por agente. Apenas @devops faz push e PR. Apenas @db-sage roda migrations em produção (enforçado por enforce-migration-authority.sh). Apenas @architect aprova arquitetura. Hooks bloqueiam violações em runtime, não em code review. BMAD não tem nada equivalente.

Multi-tenant Isolation. 4 negócios sob a mesma governança, mas com workspaces L0-L4 isolados. CODEOWNERS por path. Dados de um negócio não vazam para outro. Para holdings, agências com múltiplos clientes, ou frameworks que servem várias unidades, isso é fundacional.

Cross-Domain Breadth. 53 squads cobrem design-system, design-ops, copy, brand, movement, legal, data, finops, customer-success, db-sage, infra, c-level, e mais 40+. Não é só dev. É o stack inteiro de operação de uma holding. BMAD foca dev-lifecycle; AIOX foca operação-completa.

Honest take: para uma holding com múltiplos negócios, ou um time que precisa de governance forte e cross-domain orchestration, AIOX entrega o que BMAD não se propõe a entregar. O custo é overhead — que em time pequeno se torna fricção.

Armadilhas reais ao escolher (sem hype)

Toda escolha de framework esconde trade-offs. Aqui estão 4 que geralmente passam batido:

Armadilha 1 — Falsa equivalência. A maioria das comparações trata "método de desenvolvimento" e "framework de orquestração" como se fossem o mesmo produto. Não são. Escolher BMAD para gerenciar um portfolio de 4 negócios é forçar o framework para fora do escopo dele. Escolher AIOX para um projeto solo de software é assumir overhead que não traz benefício.

Armadilha 2 — Subestimar o custo de governance. AIOX traz Constitution, agent authority e CODEOWNERS por padrão. Em equipe de 1-3 pessoas, isso é overhead, não benefício. Times pequenos perdem velocidade tentando cumprir cerimônia que existe para times grandes. BMAD com Quick Flow é mais honesto com a realidade do solo-builder.

Armadilha 3 — Superestimar autonomia de agents. Ambos os frameworks exigem human-in-the-loop. BMAD usa workflow checkpoints. AIOX usa elicitation points e hooks de quality gate. Sem isso, alucinação escala junto com volume de execução. Frameworks de agente "autônomos" sem humano na loop falham em produção — vale para BMAD, vale para AIOX, vale para qualquer um.

Armadilha 4 — Ignorar o lock-in invisível. AIOX é privado, não MIT. Em projeto open-source puro, BMAD ganha por questão de licença, não de qualidade técnica. E vice-versa: BMAD não cobre cross-domain — escolher BMAD para holding com 4 negócios cria lock-in escondido em fork e adaptação manual. Sempre pergunte: "o que vou perder se quiser sair daqui em 18 meses?"

Como decidir (sem fórmula mágica)

A decisão não é "qual é melhor". É "qual problema você está resolvendo agora":

• Dev-lifecycle clássico, equipe pequena, projeto OSS → BMAD-METHOD. Versionamento, comunidade, módulos, Party Mode, Quick Flow. Ferramenta certa.
• Holding com múltiplos negócios, governance constitucional, cross-domain → AIOX/SINKRA. Squads, layers, multi-tenant, agent authority. Ferramenta certa.
• Empresa em meio-do-caminho → roda os dois em escopos diferentes. BMAD para dev-lifecycle dentro de um produto. AIOX para a camada de portfolio. Não é exclusivo.

O decision tree completo por ICP aprofunda esse mapeamento por persona, use-case e tamanho de time.

Para explorar o framework AIOX em profundidade, com 53 squads, 8 layers e governance constitucional ativa, comece em aioxsquad.ai. Para ver o BMAD-METHOD em código, o repositório oficial está em github.com/bmad-code-org/BMAD-METHOD.