Onze agentes giram em torno de um núcleo só

Antes de chamar qualquer agente, entenda o que ele orbita. O núcleo é CLAUDE.md + CoreConfig + PRD. Os agentes são planetas: cada um com função, gravidade e órbita própria. Instalou AIOX, dá vontade de sair criando squad, PO, agente. Erro clássico: pedreiro com marreta tentando subir prédio de doze andares. Faltou o ambiente. Onze agentes não é sobre volume; é sobre clareza de função.

11agentes originais
6órbitas principais
1núcleo de gravidade

Mapa da aula

Use este mapa para entender a sequência da aula antes de entrar nos detalhes.

Legenda de coresO que cada cor sinaliza nesta aula
Núcleo de gravidadeCLAUDE.md, CoreConfig e PRD - o que toda órbita lê antes de responder
Lei da órbitaregra de autoridade exclusiva que separa um agente do outro
Execução do agenteato concreto que só o agente dono daquela órbita pode fazer
Gate de transiçãoportão que valida a passagem de um status da Story para o próximo
Erro de roteamentochamar o agente errado, sobrepor função ou pular gate

Como ler esta aula

1. Existe um núcleoCLAUDE.md + CoreConfig + PRD são a gravidade. Tudo orbita isso.
2. Cada agente é uma órbitaDevOps, PO, PM, Architect, Dev, QA: autoridade exclusiva, não redundância.
3. Saber qual chamar é metade do trabalhoErrar o agente é pedir o prédio pro pedreiro antes do canteiro existir.
4. Volume não é o pontoOnze agentes claros derrotam quarenta confusos.

O núcleo: CLAUDE.md + CoreConfig + PRD

Três arquivos ditam a gravidade do sistema. Sem eles coerentes, os agentes flutuam, alucinam, perdem contexto.

Pensa no AIOX como um planeta. Três arquivos no centro fazem a gravidade. Os agentes não são autônomos: cada um, ao ser chamado por barra, roda um greeting builder que puxa contexto desses três antes de responder. Coerentes, os agentes orbitam com previsibilidade. Quebrados, todos flutuam.

1

WHY - Por que existe núcleo

Sem gravidade comum, cada agente inventa contexto próprio. O núcleo evita 11 versões diferentes da mesma verdade.

GRAVITYshared truth
2

WHAT - O que compõe o núcleo

Três arquivos: CLAUDE.md (leis físicas), CoreConfig (regras sociais), PRD (escopo do projeto). Os três contam a mesma história.

FILES3 sources
3

HOW - Como o agente puxa

Chamada por barra dispara greeting builder. O builder lê o núcleo antes de qualquer resposta. Chamada por arroba só carrega o arquivo do agente.

INVOKEgreeting builder

1. CLAUDE.md: as leis da física

Regras universais que valem pra tudo que roda dentro.

regra universalvale pra todos os agentes

2. CoreConfig: as regras sociais

Ferramentas ligadas, stack, CodeRabbit enable true/false.

toolingstackflags

3. PRD: o mapa do projeto

O que será construído, com qual stack, com qual objetivo.

objetivostackescopo

barra dispara o greeting builder · arroba só carrega o arquivo

1

Chamada por barra

Dispara o greeting builder do agente.

2

Lê o núcleo

Puxa CLAUDE.md + CoreConfig + PRD.

3

Puxa o específico

DevOps pega ambiente, PO pega backlog, Dev pega code standards.

4

Só então responde

Contexto carregado antes da primeira palavra.

As seis órbitas principais

DevOps, PO, PM, Architect, Dev, QA: cada um com responsabilidade exclusiva. Saber qual chamar é metade do trabalho.

Cada agente é uma órbita com autoridade exclusiva. Não é redundância, é divisão de trabalho desenhada por quem já quebrou a cabeça antes.

[ORBITAL 01] · Guardião do Ambiente

DevOps

Mestre de obras: prepara o terreno, libera os outros

  • 1Environment bootstrap: Escaneia o computador, instala Node, Python, Git, CodeRabbit, MCPs.
  • 2Gestão de ambientes: Cuida de local, staging e production.
  • 3Push, PR, CI/CD: Toda subida pro GitHub passa por ele: autoridade exclusiva de push.
  • 4MCP setup: Configura os MCPs que dão superpoderes aos outros agentes.
[ORBITAL 02] · Validador de Story

PO: Product Owner

Bate o draft contra template e épico antes do Dev tocar

  • 1Validate Story Draft: Compara a Story com o template canônico e o readme do épico.
  • 2Decisão de prosseguir: Passou, libera pro Dev. Não passou, devolve pra reescrever.
  • 3Guarda do backlog: Sabe o que tá pronto, em revisão ou precisa de retrabalho.
[ORBITAL 03] · Arquiteto do PRD

PM: Product Manager

Converte briefing em PRD, PRD em épicos

  • 1Cria o PRD: Do briefing nasce o documento que dita objetivos, stack e escopo.
  • 2Quebra em épicos: Do PRD nascem épicos; de cada épico nascem Stories.
  • 3Mantém coerência: Mudou algo estrutural, ele dispara análise de impacto no PRD.
[ORBITAL 04] · Dono da Tech Stack

Architect

Dev propõe, Architect decide

  • 1Document project: Em brownfield, gera o architecture.md pro analista e pro PM.
  • 2Decisões de stack: Stack, banco, arquitetura: autoridade exclusiva dele.
  • 3Review crítica: Valida contra ADRs e a arquitetura do PRD antes do push.
[ORBITAL 05] · Implementador

Dev

Executa a Story em três modos

  • 1Modo yolo: Autônomo, sem perguntar. Pra Story bem definida em local seguro.
  • 2Modo interactive: Balanceado e educacional. Padrão pra quem aprende o sistema.
  • 3Modo preflight: Lê a Story inteira e pergunta antes de começar. Pra Story crítica.
  • 4Self-healing CodeRabbit: Lint, types, segurança corrigidos antes de finalizar. Não é opcional.
[ORBITAL 06] · Quality Gate

QA

Aprovação técnica final antes do deploy

  • 1Acceptance Criteria: Valida cada AC. Falhou, devolve pra fix com finding registrado.
  • 2Testes e cobertura: Unitário, integração e contrato passam. Cobertura mínima respeitada.
  • 3Risk escalation: Risco de segurança ou regressão escala antes do push.

O ciclo da Story: draft → done

Toda Story é uma entidade com status próprios. Cada transição tem um dono. Pular etapa é abrir buraco; trocar a ordem é gerar retrabalho.

Tudo no AIOX é entidade: Story, épico, agente, task, e toda entidade tem ciclo. O da Story é o coração do desenvolvimento. A etapa que muita gente pula é o PO validar o draft antes do Dev pegar. Eu pulava. Hoje não pulo mais.

José Carlos encontrou a analogia certa

A imagem do mestre de obras fez a turma entender por que DevOps vem antes dos outros agentes.

Rota · insight
Começou comoConfusão sobre qual agente chamar primeiro.
VirouUma metáfora operacional: canteiro antes do prédio.
ProvaQuando a analogia entra, o aluno para de tratar DevOps como detalhe técnico.
LiçãoBoa didática troca nomenclatura por imagem concreta antes de voltar ao processo.
1TerrenoComputador sem ambiente configurado.
2Mestre de obrasDevOps monta o canteiro e libera os especialistas.
3PrédioPO, PM, Architect, Dev e QA trabalham sem improvisar infraestrutura.
AntesAgente como lista de nomes.
DepoisAgente como responsabilidade dentro de obra.
LiçãoAnalogia boa reduz carga cognitiva sem empobrecer o processo.
  • Quando a analogia entra, o aluno para de tratar DevOps como detalhe técnico.
  • Boa didática troca nomenclatura por imagem concreta antes de voltar ao processo.
  • Analogia boa reduz carga cognitiva sem empobrecer o processo.
  • Terreno: Computador sem ambiente configurado.
  • Mestre de obras: DevOps monta o canteiro e libera os especialistas.
  • Prédio: PO, PM, Architect, Dev e QA trabalham sem improvisar infraestrutura.

@sm → @po → @dev → @qa → done · depois @devops faz o deploy

1

draft

@sm cria via create-next-story a partir do épico aberto.

2

ready

@po valida o draft (Validate Story Draft) e move para ready. Gate crítico antes do Dev pegar.

3

in_progress

@dev pega a Story ready e implementa em yolo, interactive ou preflight.

4

in_review

@qa move para in review, roda Quality Gates + CodeRabbit e faz sign-off técnico.

5

done

@qa aprova → done. Done fecha o ciclo da Story (não é deploy).

6

deploy (ciclo separado)

@devops cria PR, roda CodeRabbit, executa CI/CD e faz merge. É outro ciclo, fora do status da Story.

Volume de agentes não é o ponto

Onze agentes bem definidos derrotam quarenta agentes confusos. O critério é necessidade, não sofisticação.

Eu criei vinte e oito copywriters aqui dentro porque minha operação precisava. Mas o critério foi necessidade, não volume. Mais agente sem responsabilidade exclusiva é mais confusão, não mais capacidade.

O que volume de agentes NÃO resolve

  • Sobreposição de função: dois agentes brigando pela mesma decisão.
  • Contexto disperso: ninguém é dono claro da transição.
  • Push sem gate: qualquer um sobe código, ninguém valida.
  • Sofisticação de fachada: quarenta agentes pra parecer maduro.

O que clareza de responsabilidade força

  • Autoridade exclusiva: só DevOps faz push, só Architect decide stack.
  • Delegação constitucional: quem propõe não é quem aprova.
  • Ciclo previsível: cada status da Story tem um único dono.
  • Criar novo agente só com necessidade real provada.

Qual agente tem autoridade para a tarefa que você quer fazer?

Antes de digitar, decida a órbita. Errar o agente é o erro mais caro do começo.

DevOps

É preparar ambiente, push, PR ou deploy?

action

Architect

É decisão de stack, banco ou arquitetura?

bench
↓ ↓ ↓

PO

É validar a Story antes do Dev pegar?

signal
↓ ↓ ↓

Dois agentes parecem igualmente donos da tarefa?

Se parecem, você ainda não entendeu a fronteira de autoridade: releia as seis órbitas.

A analogia do José Carlos: pedreiro vs mestre de obras

Um aluno traduziu o sistema numa imagem que vale mais que dez slides técnicos.

Um aluno chamado José Carlos desenhou no whiteboard a melhor analogia da aula. "Quando a gente instala AIOX, quer sair criando squad, criando PO. Mas é como pedreiro com marreta e carrinho de mão tentando subir prédio de doze andares. Faltou o ambiente." "DevOps é o mestre de obras. Antes de subir o prédio, ele analisa o terreno, prepara o canteiro, traz andaime, monta elevador de carga." No AIOX isso vira o bootstrap: o DevOps escaneia teu computador, configura tudo, e só aí libera os outros pra trabalhar. PO, PM, Architect, Dev, QA são os pedreiros especialistas. Sem o mestre de obras montando o canteiro primeiro, nenhum sobe um andar. Por isso o primeiro comando que você dá no AIOX é chamar o DevOps pro environment bootstrap.

o canteiro vem antes do prédio

1

Terreno vazio

Computador recém-instalado, nada configurado.

2

Mestre de obras chega

Você chama o DevOps pro environment bootstrap.

3

Canteiro montado

Node, Python, Git, CodeRabbit, MCPs prontos.

4

Pedreiros liberados

PO, PM, Architect, Dev, QA sobem o prédio andar por andar.

Glossário rápido

Sete termos pra fixar antes da próxima aula.

Agente orbital

Agente que gira em torno do núcleo CLAUDE.md + CoreConfig + PRD e puxa contexto via greeting builder.

Núcleo de gravidade

CLAUDE.md (leis), CoreConfig (regras do projeto) e PRD (escopo). Quebrou um, todos perdem direção.

Environment bootstrap

Primeira tarefa do DevOps: escaneia o computador, valida Node, Python, Git, CodeRabbit.

Ciclo da Story

draft → ready → in_progress → in_review → done. Cada transição tem um dono.

Greeting builder

Script que roda quando o agente é chamado por barra. Puxa o mínimo de contexto antes da resposta.

Self-healing loop

Ciclo do Dev com CodeRabbit CLI: lint, types e segurança corrigidos antes da Story sair de in_progress.

Onze agentes originais

Conjunto canônico do AIOX. Criar mais é legítimo com necessidade real, não pra parecer elaborado.

Portão da aulaVocê entendeu quando consegue olhar para uma tarefa e dizer qual agente tem autoridade, qual contexto ele puxa e qual transição ele deve mover.

Prática: escolha o agente certo

Pegue uma tarefa real e roteie para a órbita correta antes de executar.

◇▶ signal_plus_action

Sequência para rotear uma tarefa ao agente certo

Use antes de digitar qualquer pedido: decida a órbita primeiro, execute depois.

descrever tarefa→classificar domínio→escolher órbita→nomear o gate→executar
  1. Descrever — Escreva a tarefa em uma frase concreta.
  2. Classificar — Ambiente, produto, arquitetura, código, qualidade ou deploy?
  3. Órbita — Escolha o agente com autoridade exclusiva: DevOps, PO, PM, Architect, Dev ou QA.
  4. Gate — Diga qual portão fecha a tarefa antes de chamar de pronta.

Exemplo preenchido: 'quero migrar o banco para Supabase'

TarefaMigrar Postgres self-hosted para Supabase no projeto X.
DomínioArquitetura. Decisão de stack + banco + RLS policies. Não é só código.
Agente dono@architect decide a stack e a estratégia de migração. @db-sage executa as migrations. @devops faz o deploy. @dev não decide isso sozinho.
Sequência@architect propõe ADR -> @db-sage desenha schema + RLS -> @dev implementa client -> @qa valida -> @devops faz push e deploy.
GateADR aprovado + migration testada em staging + RLS validada + zero downtime documentado. Só depois @devops promove pra prod.
Teste rápidoSe dois agentes parecem igualmente responsáveis, você ainda não entendeu a fronteira de autoridade.
  1. Tarefa: Escreva uma tarefa que você quer fazer no AIOX esta semana.
  2. Domínio: Classifique o domínio: ambiente, produto, arquitetura, código, qualidade ou deploy.
  3. Agente: Escolha o agente com autoridade exclusiva para esse domínio.
  4. Gate: Diga qual gate precisa passar antes da tarefa ser considerada pronta.

Bloco de código: roteamento de agente

Use este mapa antes de chamar qualquer agente por impulso.

aula.yaml5 linhas
01tarefa: 02  dominio: "ambiente | produto | arquitetura | codigo | qualidade | deploy"03  agente_dono: "@devops | @pm | @architect | @dev | @qa"04  gate: "qual prova fecha a tarefa?"05  nao_chamar: "agentes que só opinam, mas não têm autoridade"

Produz

Órbita boa reduz ruído: um dono, um gate, uma próxima ação.

Portão

Mapa de decisão