Escrito e revisado por Jefferson Oliveira. Os exemplos vêm da missão que construiu este site e das skills que eu uso no dia a dia.
Pedir pro agente “faz a Home inteira” funciona no começo. Depois ele esquece o que combinou, mede uma coisa e implementa outra, e no fim diz que está tudo pronto. Não está.
O modelo dá conta de cada parte. O que dá errado é juntar tudo numa conversa só: ele planeja, escreve e confere o próprio trabalho com o mesmo contexto, que só cresce. Missão é o fluxo que eu uso pra separar esses trabalhos. Este site foi feito assim, e eu uso o mesmo formato em outros projetos, de WordPress a Laravel.
De onde veio a ideia
Vi o formato numa palestra do Luke Alvoeiro, da Factory, no canal AI Engineer [1]. A Factory chama de Missions um modo do agente deles em que um orquestrador planeja junto com você, workers implementam features organizadas em milestones e validadores conferem cada milestone no fim.
Duas ideias da palestra me pegaram. Teste escrito depois da implementação não pega bug, só confirma as decisões que já foram tomadas. E quem implementou avalia pior o próprio trabalho do que um revisor que chega sem contexto. A Factory ainda diz que a maior parte do valor está no planejamento [2].
Eu não uso o produto da Factory. Montei a mesma ideia no Claude Code, com uma skill de orquestração e quatro agentes. A versão enxuta deles está no fim do post, pra copiar.
Os papéis
O /mission é o único comando. Ele lê o estado em docs/mission/plan.md e faz um passo só: planeja, executa a próxima fase ou valida o milestone que fechou. Um passo por chamada é de propósito, pra eu revisar entre as fases.
O planner lê a spec e o Figma e escreve três arquivos: o PRD, o plano em milestones e fases, e o contrato de validação. Se algo estiver ambíguo, ele para e devolve perguntas antes de escrever qualquer coisa.
O worker implementa uma fase, em contexto limpo. Lê o PRD, o plano, o contrato e os handoffs anteriores, faz o trabalho e escreve o próprio handoff. Não commita.
No fim de cada milestone entram dois validadores que não implementaram nada. O scrutiny roda lint, build e code review e não tem ferramenta pra editar arquivo. O user-testing é o QA: navega o site como visitante e como editor, mede cada seção contra o Figma e não lê o código-fonte.
// o detalhe que eu gosto
O orquestrador não lê código. Só despacha, lê o retorno e marca o plano. Numa missão longa ele é quem mais acumula contexto, então quanto menos carrega, mais tempo aguenta sem se perder.
O contrato vem antes do código
O contrato de validação é uma lista de asserções verificáveis, escrita a partir do PRD antes da primeira linha de código. Ele define quando a missão terminou.
Aqui no site, cada seção tem uma asserção de fidelidade com os nodes do Figma e os ids que o validador mede em 1366, 768 e 390. Tem outra dizendo onde o editor troca cada texto pelo painel, e uma de performance: nenhum get_field em Blade, nenhuma query repetida. O worker grava exatamente esses ids, e o validador confere contra o contrato, não contra o que o worker disse que fez.
É o que mais muda o resultado. Sem contrato, o validador lê o código e acha razoável. Com contrato, ele tem uma régua que ninguém ajustou depois.
O handoff no lugar da memória
Cada fase termina num arquivo: o que foi feito, onde o editor mexe, o que ficou de fora e por quê, os comandos com exit code, os problemas encontrados e os arquivos tocados. A próxima fase lê os handoffs que tocam nela. Ninguém depende de lembrar da conversa.
## Ficou de fora- ... (e por quê)## Comandos executados| Comando | Exit code || --- | --- || `...` | 0 |## Procedimentos- [ ] Lint/build rodados- [ ] Script de conteúdo rodado 2x (idempotente)- [ ] (UI) Inventário escrito antes do build- [ ] Conferido em 1366 e 390 contra o Figma (`measure.py` + `--overflow`)- [ ] Ficou dentro do escopo da faseO “Procedimentos” é o que o orquestrador olha primeiro. Caixa desmarcada ou bloqueio, ele para e me chama em vez de seguir pra próxima fase.
// na prática
O handoff vale pelo que ele admite. Na fase do blog da Home, a conexão com o Figma caiu logo depois da leitura dos nodes, e o worker escreveu que dois scripts de conferência não rodaram e o que faltava checar. Num agente só, isso vira “pronto” e some.
Contexto curto por sessão
Dividir em agentes tem outro efeito, fora o validador: cada sessão fica pequena. O worker começa do zero, lê o PRD, o plano, o contrato e os handoffs que tocam nele, faz uma fase e acaba. Ninguém carrega a conversa das 40 fases anteriores.
Tem gente que fala que até uns 200 mil tokens de contexto o modelo é inteligente, e depois disso começa a ficar burro. Não sei se o corte é esse número, mas a direção bate com o que eu vi. Com as fases separadas, o agente ficou mais certeiro: menos “esqueci o que combinamos”, menos medida trocada. É mais um ponto a favor.
// o número que eu medi
Nos registros da missão deste site, o pico de contexto dos 64 agentes teve mediana de 158 mil tokens. A sessão do orquestrador, que só despachava, chegou a 366 mil, mesmo compactada cinco vezes. Numa conversa só, tudo isso estaria junto. Ainda tem o que cortar: 15 agentes passaram de 200 mil.
O que me ajudou a enxergar isso foi o TokenLens, um painel open source que eu fiz pra ver os tokens das sessões do Claude Code, do Codex e do pi (github.com/jeffersonrucu/token-lens). Ele roda só na máquina e lê os registros que os agentes já gravam. Mostra o gasto de cada subagente e quem iniciou cada um, o contexto enviado a cada resposta, onde o cache se perdeu e onde um /compact cortou. A sessão ao vivo fica vermelha quando passa de 100 mil tokens.
Foi nesses gráficos que eu debuguei o fluxo, otimizei e entendi quanto custava cada parte.
O que os validadores pegaram
A missão deste site teve 7 milestones, 43 handoffs e 101 asserções no contrato. Os validadores reprovaram 4 rodadas e aprovaram 13.
Nenhuma reprovação era erro de compilar. No primeiro milestone, o foco do teclado sumia abaixo de 1024 px porque o contorno laranja ficava em cima do botão laranja. Na Home, durante a animação de digitação do terminal, o Tab parava num link invisível. Os dois passam no lint, no build e no olho de quem escreveu.
// quase foi pro ar
Na passada final, com tudo aprovado, o QA abriu o sitemap e achou /author/jefferson/ indexável, sem layout, com a lista crua de posts. Nenhuma fase tinha tocado nessa página, então nenhuma asserção cobria. Ele achou porque navega o site em vez de ler o código.
Validador também erra. Um apontou que faltava o link “ver certificado”, que estava lá. Outro rodou uma exclusão com o ID errado, e por sorte nada se perdeu. Validador é mais um agente: o veredito dele também passa pelo meu olho antes de virar fase de correção.
O preço: mais lento e mais caro
O custo é alto, em token e em tempo. Cada fase é um agente novo que relê PRD, plano, contrato e Figma antes de escrever uma linha. Cada milestone chama mais dois agentes. Fase reprovada volta pro começo.
A Anthropic mediu algo parecido: o mesmo app saiu em 20 minutos e US$ 9 com um agente sozinho, e em 6 horas e US$ 200 com planner, gerador e avaliador separados, com qualidade bem maior [3].
O tempo pesa mais que o token. A missão deste site levou umas 48 horas corridas, do pedido ao “terminamos”. Pra quem está acostumado a pedir e receber em minutos, é lento mesmo. A troca que eu faço é essa: demora mais, acerta mais e me sobra menos pra revisar.
E boa parte desse tempo vai pra validação. O QA não lê código: ele roda scripts que sobem um navegador, abrem o site, navegam, preenchem formulário, editam pelo painel e medem cada seção em várias larguras. Cada passo espera a página carregar. É lento por natureza, e pular essa etapa é perder justamente o que pega o bug.
// onde vai o tempo
Somando o tempo ativo dos agentes da missão deste site, os validadores ficaram com cerca de 30% e os workers com o resto. Dentro do QA, mais de um terço do tempo foi esperando script de navegador. E o worker também roda o medidor contra o Figma antes de entregar a fase, então a conferência aparece dos dois lados.
Pra não depender de mim a cada fase, existe o modo autônomo. A dúvida que surge vira uma linha num arquivo de pendências, com o padrão mais conservador aplicado, e o trabalho segue. Nesta missão foram 45 dúvidas registradas assim, pra eu revisar de uma vez depois.
// onde eu errei
Fui dormir às duas da manhã pedindo pra ele rodar em loop e não pausar por dúvida. Meia hora depois ele parou: a conexão com o Figma tinha caído, e sem Figma o worker não mede nada. Voltei ao meio-dia e a missão estava no mesmo lugar. Modo autônomo resolve dúvida. Ferramenta fora do ar, não.
Paralelo, só com cuidado
A primeira vontade é rodar vários workers juntos. A Factory diz que execução em série, com paralelismo pontual, funcionou melhor que paralelismo amplo [2]. Eu tentei e vi por quê.
Num projeto em Laravel, deixei workers em paralelo na mesma árvore quando as fases não tocavam os mesmos arquivos. Mesmo assim, um handoff registrou a fonte computada mudando entre uma medição e outra, 4 a 7 px abaixo do Figma, provavelmente porque outro worker mexia no CSS. Daí veio a regra: cada fase lista os arquivos que vai tocar, e só roda junto com outra se as listas não se cruzam. Se houver dúvida, uma depois da outra.
Aqui no WordPress, até os validadores rodam em sequência: juntos, um suja o debug.log do outro. Onde o paralelo funcionou foi com milestones independentes. No fim deste site eu pedi pra acelerar, e quatro agentes, um por milestone que faltava, fecharam Projetos, Blog, Post e o resto em menos de uma hora.
Ainda vale em 2026?
Eu me perguntei isso antes de escrever. Sai modelo novo todo mês, e andaime de agente envelhece rápido. A própria Anthropic tirou peças do harness dela quando os modelos melhoraram: resets de contexto e sprints deixaram de ser necessários [3].
O miolo da ideia continua de pé. Factory, Anthropic, Cognition e Cursor publicaram sobre isso este ano e chegaram perto do mesmo formato: um agente escreve por vez, paralelo só pra ler e revisar, revisor separado com contexto limpo e um plano definido antes do código. O que caiu foi o enxame de agentes escrevendo juntos.
Pra tarefa de minutos, missão é exagero. Um ajuste de CSS, um bug com causa conhecida, uma tela pequena: eu peço direto, com um plano rápido e no máximo um subagente revisando no fim. Missão eu uso quando o trabalho dura horas, quando dá pra escrever o critério de pronto antes e quando um bug que passa custa mais caro que o token gasto.
Pra copiar e testar
Abaixo vai uma versão enxuta do que eu uso, sem nada de WordPress ou Figma. São cinco arquivos: a skill de orquestração em .claude/skills/mission/ e os quatro agentes em .claude/agents/. Cole no seu projeto, ajuste os comandos de lint, build e teste, e rode.
---name: missiondescription: Planeja, executa a próxima fase ou valida o milestone conforme o estado de docs/mission/. Use quando o usuário pedir /mission.---Você é o orchestrator. Não explore código nem implemente:só despache agentes, leia os retornos e atualize o plano.Argumento: $ARGUMENTSLeia docs/mission/plan.md e siga **um** caso:1. Sem plano: chame o `planner` com o objetivo. Se ele devolver perguntas, faça-as ao usuário e retome o mesmo planner com as respostas. Mostre o plano e pare.2. Plano em `Status: rascunho`: peça aprovação. Aprovado, troque para `Status: aprovado` e pare.3. Fase pendente: chame o `worker` com "Leia docs/mission/prd.md, plan.md e validation-contract.md. Faça a Fase <N>." Leia o handoff. Procedimento incompleto ou bloqueio: pare e reporte. Senão, marque `- [x]`. Se o milestone fechou, chame `scrutiny-validator` e depois `user-testing-validator`. Reprovado: crie fases de correção e pare. Se o milestone já reprovou duas vezes: pare e reporte.4. Tudo feito: troque para `Status: concluído` e resuma.---name: plannerdescription: Transforma um objetivo em PRD, plano de fases e contrato de validação. Devolve perguntas quando o escopo estiver ambíguo. Use via /mission.model: opus---Você planeja uma missão. Não implemente nada.1. Leia docs/escopo.md, se existir, e só o necessário do código.2. Se algo for ambíguo, pare e devolva só as perguntas (máx. 5, com a opção recomendada).3. Com o escopo fechado, escreva: - docs/mission/prd.md: objetivo, regras, fora do escopo, fluxos e critérios de aceite. - docs/mission/plan.md: `Status: rascunho`, milestones e fases `- [ ]`, cada fase pequena o bastante pra um agente só. - docs/mission/validation-contract.md: asserções verificáveis por milestone, escritas antes do código. É contra elas que os validadores conferem.4. Devolva um resumo do plano.---name: workerdescription: Implementa uma única fase de docs/mission/plan.md em contexto limpo e devolve um handoff. Use via /mission.model: opus---Implemente **só** a fase indicada no pedido.1. Leia prd.md, plan.md, validation-contract.md e os handoffs anteriores que tocam na sua fase.2. Implemente. Rode lint, build e testes.3. Salve docs/mission/handoffs/phase-<N>.md e devolva o mesmo conteúdo: Implementado, Ficou de fora (e por quê), Comandos executados (com exit code), Problemas descobertos, Arquivos alterados e Procedimentos (checklist do que rodou).4. Não commite. Problema fora da fase vai em "Problemas", não no código.---name: scrutiny-validatordescription: Valida um milestone com lint, build, testes e code review contra o contrato. Use via /mission.tools: Read, Grep, Glob, Bashmodel: sonnet---Você valida um milestone que **não** foi você quemimplementou. Não edite código.1. Leia o prd.md, o milestone no plan.md e os itens dele no validation-contract.md.2. Rode lint, build e testes. Anote o exit code de cada.3. Revise os arquivos listados nos handoffs do milestone.4. Confira cada item do contrato. Vale o contrato, não o que o código faz.Devolva: **Veredito:** APROVADO | REPROVADO, os checkscom exit code, o contrato marcado e os problemas, do maisgrave pro menos grave, com arquivo:linha.---name: user-testing-validatordescription: QA de um milestone: usa o produto ponta a ponta sem olhar o código. Use via /mission.model: sonnet---Você é QA. **Não leia o código-fonte.**1. Leia o prd.md, o milestone no plan.md e os itens dele no validation-contract.md.2. Suba o app e use como o usuário usaria: navegador, CLI ou API, o que o projeto tiver.3. Teste cada item do contrato e guarde a evidência (screenshot, saída do comando) em docs/mission/evidence/M<n>/.Devolva: **Veredito:** APROVADO | REPROVADO, item por itemdo contrato com a evidência, e os problemas com o passo apasso pra reproduzir.// a dica
Antes do /mission, eu rodo o /grill-me, uma skill do Matt Pocock (github.com/mattpocock/skills). Ela me entrevista em rodadas, cada pergunta com a resposta que ela recomenda, até não sobrar decisão no ar. No fim eu peço pra salvar as decisões em docs/escopo.md, e o planner começa com bem menos perguntas.
Com o escopo fechado e o plano aprovado, daí pra frente é automático. O /loop do Claude Code repete um comando, e sem intervalo o próprio agente decide quando rodar de novo. Com /loop /mission ele vai executando fase por fase e validando cada milestone, e eu só volto pra ler os vereditos. O fluxo inteiro cabe em três comandos, e entre o segundo e o terceiro você lê o plano e aprova.
/grill-me painel de pedidos com filtro e export CSV/mission painel de pedidos, decisões em docs/escopo.md/loop /missionPerguntas frequentes
Preciso de um agente pra cada papel?
E se o validador reprovar sempre?
Funciona em projeto sem tela?
Referências
- [1] Palestra · The Multi-Agent Architecture That Actually Ships, Luke Alvoeiro (AI Engineer) (abre em nova aba) youtube.com/watch?v=ow1we5PzK-o
- [2] Factory · Missions (abre em nova aba) factory.com/news/missions
- [3] Anthropic Engineering · Harness design for long-running apps (abre em nova aba) anthropic.com/engineering/harness-design-long-running-apps
- [4] Pesquisa · Chroma: Context Rot (abre em nova aba) trychroma.com/research/context-rot
Fontes conferidas em nov 2026.
// quem escreveu
Jefferson Oliveira
AI Engineer · Studio Visual (abre em nova aba) · São Paulo, SP
Trabalho há mais de 5 anos com PHP, Laravel e WordPress, construindo e-commerces, integrações e sistemas internos. Hoje lidero a adoção de IA na Studio Visual (abre em nova aba) e curso MBA em Engenharia de Software na FIAP.
- MBA em Engenharia de Software · FIAP (cursando)
- Análise e Desenvolvimento de Sistemas · FATEC Zona Leste
- Liderança e Gestão de Equipes · FGV
- PHP: Desenvolvimento Web e POO · 4Linux
