Agentes

Um agente é quem executa: um shell despachador que recebe uma tarefa, identifica qual skill ela pede, e roda só aquela skill. Ele não improvisa — a skill é a autoridade, e o agente é o invólucro que a carrega com o modelo e as ferramentas daquele papel.

São quatro, e a divisão é por etapa do ciclo, não por assunto. Isso é o que evita dois agentes disputando o mesmo trabalho:

To scout ──► Reach ──► To build ──► Review ──► Check ──► Monitoring ──► Done
  scout      reach       build      monitor    VOCÊ      monitor
inventaria   planeja    constrói    revisa    mergeia     soak

Cada agente trabalha pra passar pro próximo

O produto de um elo não é o relatório dele: é o insumo que o próximo precisa pra começar. Por isso cada um tem uma barra de entrega, e ela não é burocracia — é o que o elo seguinte consome:

Elo	Recebe	A barra pra avançar	Sem isso, o próximo…
agente-scout	card cru em To scout	bug: causa com arquivo:linha + sinal de reprodução · resto: PRD + fatias	planeja em cima de sintoma, não de causa
agente-reach	card pesquisado em Reach	PRD com critério de aceite verificável + fora de escopo	implementa o recorte que ele mesmo inventou
agente-build	card aprovado em To build	PR draft + suíte rodada de verdade + subtasks sincronizadas	revisa sem saber se passa, e valida por opinião
agente-monitor	PR em Review · entrega em Monitoring	veredito explícito · soak de 14 dias limpos com uso	mergeia no escuro, ou fecha soak sem evidência

Lido de trás pra frente, fica óbvio o que cada barra protege: critério de aceite que não dá pra checar faz o monitor validar por opinião; causa sem sinal de reprodução faz o build "corrigir" sem saber se corrigiu. É por isso que não fechar é resultado válido e não avança — card que passa sem a barra transfere o buraco pro próximo elo, onde custa mais caro descobrir.

Os dois gates humanos ficam nas duas transições que mudam o custo do erro: Reach → To build (alguém vai gastar tempo implementando) e Check (vai pra produção). Nenhum agente atravessa esses dois sozinho.

Agente	Papel	Pergunta	model	effort
agente-scout	inventaria o estado real	qual é a situação, de verdade?	sonnet	medium
agente-reach	cria o plano/material	o que vamos construir, com que critério de aceite?	opus	high
agente-build	constrói/produz	como isso vira código, teste, tela, doc?	sonnet	high
agente-monitor	acompanha e valida	confere com inventário, plano e regras?	opus	high

O par sonnet constrói / opus julga não é economia cega: quem produz trabalha em cima de um plano já fechado, e quem revisa precisa enxergar o que o produtor não viu. Errar na revisão custa mais que errar na primeira tentativa, porque a revisão é a última rede.

O que cada um recusa fazer

A fronteira é a parte útil. Quando a tarefa não casa com nenhuma skill da cesta, o shell não improvisa: responde qual dos outros três é o dono.

Agente	Faz	Não faz
agente-scout	observa e relata; em produção é read-only	não conserta código, não decide escopo
agente-reach	PRD, issues, modelo de domínio	não implementa e não revisa/mergeia
agente-build	código, testes, telas, documentação — sempre PR draft	nunca mergeia nem deploya; não decide escopo
agente-monitor	revisa, triage, veta, fala com o humano	não produz e não mergeia — quem mergeia é o humano

Duas consequências que valem saber de cor:

• Só o monitor fala com o humano em nome do comitê. Os outros três reportam pra ele, que decide o canal. É o que impede quatro remetentes disparando no mesmo horário.
• O build entrega PR draft, sempre. Ninguém do comitê mergeia. O merge é o gate humano.

Como as skills se distribuem

Cada agente tem uma cesta: as skills que ele pode despachar. Duas skills têm dois donos, e nos dois casos o critério é o modo, não o assunto:

• backlog-scout — VARREDURA (listar tickets elegíveis) roda no scout; EXECUÇÃO (implementar um ticket em worktree isolado) roda no build.
• impeccable — lentes de produção (design, polish, harden, animate) rodam no build; lentes de monitoração do design system (critique, audit) rodam no monitor.

As réguas (priorize, estimate, criticidade, modelo-effort) e a linear não pertencem a ninguém: são de todos. Catálogo completo em skills.

Trabalho em paralelo

Paralelismo é instância paralela do mesmo shell, não um agente novo: duas instâncias do build, uma rodando to-build e outra test-writer, é o padrão de implementar e testar ao mesmo tempo sem ping-pong.

Antes de abrir subagente, os quatro passam pela matriz inteligência × volume da régua modelo-effort: inteligência sobe o degrau, volume desce, e num fan-out a inteligência se paga no juiz, não nos coletores.