Módulo 7: Gauntlet Loop e Graph Engineering

Gauntlet Loop é revisão contínua com nome bonito

Gauntlet loop é repetição até atingir um grau de qualidade determinado. Mais precisamente: até bater a especificação que você definiu no módulo anterior.

O ciclo é este:

1. Você define o que quer, as especificações.
2. Um agente produz o artefato, o resultado.
3. Um revisor checa se aquilo bateu os critérios.
4. Se não bateu, volta com a lista de correções.
5. Repete até passar.

O que isso traz de novo é a ideia de subagentes: dois robozinhos diferentes, com papéis diferentes, que se complementam. Um executor e um revisor.

Por que você não pode usar o mesmo agente para as duas coisas

Este é o erro mais comum de todos. Você pede para o Claude criar o roteiro. Depois pede, no mesmo chat e com o mesmo modelo, para revisar aquele roteiro.

Ele vai aprovar o próprio trabalho sem senso crítico nenhum. Não porque seja burro, mas porque não existe critério contra o qual julgar, e porque ele está enviesado pelo próprio texto que acabou de escrever.

Critério subjetivo não funciona

O que é um roteiro bom? Se você deixar isso em aberto, não tem loop que salve. Tem gente que gosta de curto, tem gente que gosta de longo, tem gente que quer susto, tem gente que quer arquétipo.

Você precisa de critérios objetivos e específicos, com pontuação. Por exemplo:

Critério	Como medir	Pontos
Extensão	Roteiro tem 10 mil palavras	10
Gancho	No máximo duas frases, até 15 palavras	20
Estrutura	Blocos na ordem definida	…
Nota de corte	Soma mínima para aprovar	80

A IA consegue contar 10 mil palavras. Ela consegue contar 15 palavras no gancho. É por isso que o critério precisa ser mensurável.

Se a soma passa de 80, segue para a próxima etapa. Se não passa, volta para o executor com a lista específica do que corrigir: “o gancho está grande demais”, “faltam três mil palavras”, “está faltando emoção no bloco dois”.

E, obrigatoriamente, um critério de parada. Bater todas as notas mínimas ou um teto de iterações, tipicamente três. Sem isso, ele roda para sempre e queima o seu token à toa. Se parar por ter estourado as três tentativas, ele não pode aprovar sozinho: ele te avisa e você olha na mão.

Graph Engineering começa com uma ponte

A teoria dos grafos nasceu de um problema chamado as sete pontes de Königsberg, resolvido por Leonhard Euler, o mesmo do logaritmo natural.

A cidade era dividida em quatro regiões conectadas por sete pontes. A pergunta: uma pessoa consegue sair de uma região, passar por todas as pontes e voltar ao ponto de partida sem repetir nenhuma ponte?

Resposta: não. O problema não tem solução, e é possível provar isso.

O que interessa não é a resposta, é a mudança de olhar. Euler jogou fora o mapa e desenhou uma pessoa no centro de cada região, perguntando apenas quantas conexões existem entre elas. Aquelas bolinhas são nós (nodes), e as ligações são arestas. Isso é um grafo.

Do grafo para o orquestrador

Vira o desenho na horizontal e repare: o nó que se conecta a todos os outros pode ser o orquestrador, e cada bolinha ao redor um subagente.

• Antes: você conversa com um agente único, que faz tudo.
• Agora: você fala só com o orquestrador, que comanda os subagentes, tem a visão do todo e distribui as tarefas em paralelo.

O orquestrador sabe o que cada subagente está fazendo. Os subagentes não sabem uns dos outros, e na maioria dos casos é assim que deve ser.

Colocando nome nas bolinhas: agente de roteiro, agente de thumbnail, agente de SEO. Eles trabalham em paralelo porque roteiro não depende de thumbnail nem de SEO. Você digita o seu pedido só para o orquestrador, que já foi treinado para demandar a tarefa certa ao agente certo.

E dá para descer mais um nível. O agente de roteiro pode ter três subagentes por idioma (português, inglês, espanhol), porque cada mercado tem ângulo e público diferentes. E dentro de cada um deles mora o loop do começo deste módulo, com executor e revisor ligados pelas duas arestas.

Ou seja: o loop é uma simplificação de um grafo.

As duas vantagens que pagam a conta

1. Janela de contexto limpa. Cada agente tem a sua própria janela. Quando você pede algo ao orquestrador, ele gasta pouquíssimo token, talvez 20 mil, só para distribuir tarefa. O agente de roteiro também não faz a pesquisa inteira, ele delega. O resultado é mais preciso porque a etapa de roteiro não sabe nada de thumbnail nem de SEO, e não precisa saber.

2. Você diversifica os modelos. Cada agente pode usar um modelo diferente, e essa é a resposta para a objeção óbvia de que loop gasta mais token.

Sim, loop gasta mais token. Mas quando o processo está bem definido, você não precisa do melhor modelo de fronteira em todo lugar:

• Orquestrador: aqui vale o modelo caro e a janela grande, porque ele recebe todas as respostas de volta. Um Opus ou Fable.
• Roteiro: um Sonnet já é mais do que suficiente. Um DeepSeek escreve muito bem e custa uma fração.
• Thumbnail e etapas auxiliares: modelos menores e mais baratos dão conta.

A analogia que fecha o raciocínio: pensa no estagiário da sua empresa. Ele sabe pouco, é a parte mais fraca. Mas se existe onboarding, se as pastas estão organizadas, se os processos estão claros, ele não vai ter dificuldade. Não é o estagiário que é bom, é a empresa em volta dele que é boa. É exatamente por isso que você pode colocar modelos mais fracos em etapas do processo, desde que gaste tempo estruturando o sistema.

As decisões precisam ser humanas

Isso não é discurso bonito, é limite técnico e editorial.

Não existe automatizar um canal do início ao fim, a não ser que você esteja fazendo um canal realmente ruim. Tem que existir um momento em que a revisão é sua e a decisão é sua. É justamente isso que diferencia o seu canal dos outros e o que te tira da vala comum do slop.

Na prática, isso vira gates humanos na pipeline: etapas marcadas como humanas, e etapas automatizadas que ainda assim dependem de aprovação. Quando o sistema detecta qualquer desvio das especificações, ele para e avisa, mesmo sendo automático. Uma etapa pode inclusive declarar que nenhum agente tem permissão de assinar aquela decisão.

Artefatos e contratos

A consequência natural de tudo isso é parar de copiar texto do chat.

Toda vez que uma etapa produz uma saída, ela produz um arquivo estruturado. Um roteiro vira roteiro.json. Uma pesquisa vira pesquisa.json.

Por que JSON? Porque é estruturado, tem regras a seguir, e agentes performam melhor com estrutura, já que são muito bons em seguir ordens quando elas estão bem definidas.

Esse arquivo é o contrato entre as etapas. Você não pode produzir um roteiro sem ter feito a pesquisa antes, porque o roteiro precisa ler pesquisa.json para existir. Se o arquivo não está lá, a etapa não roda. Simples e eficiente.

Próximo módulo

No Módulo 8 a gente sobe mais um nível: os agentes que operam a sua vida, não só o seu projeto.