🔁 O Loop operacional: o cérebro disciplinado
Este é o módulo-chave do curso. Um agente disciplinado não corre para o teclado — ele aterra no real, raciocina, age em lotes, para pra ler o que voltou e só então decide o próximo passo. Esse ciclo tem nome: GROUND → REASON → ACT → OBSERVE → RE-EVALUATE → VERIFY → NARRATE. Aqui você vai entender, passo a passo, o cérebro que separa um agente que pensa de um que só "tateia rápido".
Conteúdo detalhado
Por que um loop, e não um truque
A internet está cheia de "truques de prompt": a frase mágica, o jailbreak da moda, o template que "faz a IA virar gênio". Eles funcionam por uma tarde e quebram na seguinte. O que realmente muda o jogo não é um truque — é um hábito de trabalho. Um ciclo que o agente roda em todo turno difícil, sempre o mesmo, sempre na ordem. É isso que separa um agente que pensa de um que apenas age rápido.
🧠 A ideia em uma frase
O Loop operacional é o cérebro disciplinado do agente: um ciclo de sete passos — aterrar, raciocinar, agir, observar, reavaliar, verificar, narrar — rodado a cada turno não-trivial. Ele não é uma frase que você cola; é um jeito de trabalhar que você institui.
A frase que resume tudo: "a velocidade vem de fazer a coisa certa uma vez, não de pular o raciocínio." Um truque te dá um atalho que às vezes funciona; o loop te dá um método que sempre confere.
✗ O truque (frágil)
- ✗Depende de uma frase específica que "destrava" o modelo
- ✗Funciona num caso e quebra no caso vizinho
- ✗Corre pro teclado: age sem aterrar nem conferir
- ✗Quando dá errado, você não sabe por quê — era mágica
✓ O loop (robusto)
- ✓É um ciclo de hábitos, igual em toda tarefa
- ✓Generaliza: serve pro caso que você não previu
- ✓Aterra primeiro, age depois, confere sempre
- ✓Quando algo falha, você sabe em qual passo olhar
Por que isto é o módulo-chave
Todos os blocos da Trilha 2 montam como o agente fala. Este monta como o agente trabalha. O bloco <loop_operacional> é o que mais aproxima um agente comum da disciplina de ponta — é, sozinho, o pulo do gato. Domine este, e o resto vira ajuste fino.
GROUND — aterrar no estado real
O ciclo abre com a regra mais simples e mais ignorada: nunca mude o que você não entendeu. Antes de propor solução, antes de editar uma linha, o agente estabelece o estado real do mundo. Roda o git status, faz o grep, lista o diretório, lê o arquivo que importa. Aterrar é trocar o "provavelmente está assim" pelo "eu acabei de ver".
🌍 Reconhecimento antes da mutação
Toda tarefa começa por estabelecer o que de fato existe, não por imaginar o que talvez exista. O agente disciplinado abre com um git status, um grep certeiro e a leitura do único arquivo que importa — antes de escrever um único caractere.
Há um segundo grão de areia aqui: leia a região exata logo antes de mudá-la. Contexto de cinco passos atrás é contexto velho. Uma releitura fresca evita a edição que não casa, o bloco duplicado e a mudança que já tinha sido feita.
✓ Aterrar de verdade
- ✓Checa o estado (git status, listar dir) antes de propor
- ✓Faz um grep certeiro pra achar a coisa
- ✓Lê o arquivo que importa nesta sessão
- ✓Relê as linhas exatas pouco antes de editá-las
✗ Tatear no escuro
- ✗Propõe a correção a partir de suposição
- ✗Edita um arquivo cujo conteúdo atual não viu
- ✗Edita "de memória" do que o arquivo provavelmente tem
- ✗Usa contexto velho e bate numa edição que não casa
Como soa no system prompt
"Estabeleça o estado real antes de mudar nada: git status, grep, listar dir, ler o arquivo que importa. Nunca mude o que você não entendeu." Uma linha — e ela muda a postura inteira do agente, do "chuta e corre" para o "olha e age".
REASON + ACT — pensar antes, agir em lotes
Aterrado o terreno, vêm dois passos colados. REASON: antes da primeira ferramenta, diga o objetivo, a hipótese e o plano — mesmo que em uma ou duas linhas. Nomear o que você espera encontrar muda o que você faz em seguida. ACT: dê o próximo passo deliberado e agrupe o que é independente — mas nunca finja paralelo o que tem dependência.
REASON — objetivo + hipótese + plano, antes da 1ª ferramenta
Raciocínio não é custo extra. É o trabalho.
"O rodapé aparece duas vezes. Provavelmente é montagem duplicada no layout. Vou dar grep no import do rodapé e depois ler o layout." Duas frases, e o agente já parou de disparar ferramenta antes de saber o que está testando.
ACT — passo deliberado, lotes do que é independente
Mova com alavanca: agrupe o homogêneo, paralelize o independente.
Leia os três arquivos de uma vez. Rode os checks independentes em paralelo. Execução serial de trabalho independente é tempo de parede desperdiçado. A ressalva: se o passo B precisa da saída do passo A, eles não são paralelos — fingir que são produz trabalho cancelado e confusão.
O anti-padrão a evitar
Disparar uma chamada de ferramenta antes de ter dito, nem que seja para si mesmo, o que você está testando. O agente que age sem raciocinar não está sendo rápido — está acumulando passos que vai ter que desfazer.
OBSERVE + RE-EVALUATE — o passo que todo mundo pula
Este é o coração do módulo, e o hábito que mais se ignora. Depois que uma ferramenta retorna, pare e leia o que voltou — de verdade. Aí decida o próximo passo a partir do que o resultado de fato mostrou, não do plano que você tinha antes de ter os dados. Na imagem lá em cima, é a alça em ciano: ACT → OBSERVE → RE-EVALUATE, repetida em laço até a meta.
👁️ O plano é rascunho; o resultado é a verdade
O laço observar-então-decidir é a diferença entre um agente que pensa e um que apenas age rápido. Rode-o a cada ciclo. A regra que comanda esse passo é uma só: atualize o plano a partir do resultado — não o resultado a partir do plano.
Parece assim: uma busca devolve três resultados que você não esperava. Você pausa, revisa a teoria e ajusta a próxima ação — em vez de seguir empurrando o plano antigo morro abaixo.
✓ Observar e reavaliar
- ✓Para e lê o retorno inteiro antes do próximo passo
- ✓Decide a partir do que o resultado mostrou, não do plano
- ✓Quando o dado surpreende, revisa a teoria na hora
- ✓Repete ACT..RE-EVALUATE até a meta ser atingida
✗ Pular o passo
- ✗Executa uma sequência pré-planejada como se os resultados não pudessem mudá-la
- ✗Olha o retorno de relance e já dispara a próxima ação
- ✗Encaixa o resultado no plano em vez do contrário
- ✗Segue empurrando mesmo com o dado contradizendo a teoria
Por que esta alça é a peça canônica
É o único hábito que, quando falta, faz "bons planos virarem resultados errados". A maioria dos agentes ruins não erra por raciocinar mal — erra por não ler o que voltou e seguir o roteiro antigo. Reobservar e reavaliar é o que fecha esse buraco.
VERIFY + NARRATE — check real e relato fiel
Os dois últimos passos fecham o ciclo com honestidade. VERIFY: toda edição é uma hipótese; um check que passa é a evidência. Rode o teste, o build ou o lint real do projeto — não um ls nem um echo. NARRATE: diga o que vai fazer e por quê, confirme as transições de fase. Não suma por vinte chamadas e apareça só no fim.
✅ Do "parece certo" ao "testes passam, eis a saída"
Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.
Em PT: reporte resultados fielmente — se testes falharam, diga e mostre a saída; se pulou uma etapa, diga que pulou; se algo está feito e verificado, afirme sem rodeios. "Provavelmente funciona" não é pronto; "testes passam, eis a saída" é pronto.
⚠️ Aqui, seja melhor que a fonte
O modelo do qual esta mentalidade foi destilada verifica de forma inconsistente. Você deve verificar sempre. Dois anti-padrões a cortar:
- ✗Declarar uma mudança pronta porque "parece certa", ou porque um comando sem relação saiu com código zero
- ✗Sumir por vinte chamadas de ferramenta e reaparecer só no fim, sem narrar as transições
Confiança se constrói com relato exato
Não com relato otimista. Narrar o que você está fazendo — incluindo a higiene, tipo "vou criar um branch" ou "estou aterrando" — é o que mantém uma execução longa auditável e deixa o humano corrigir o rumo cedo.
Calibrar o esforço à tarefa
Uma última disciplina, e ela impede o loop de virar burocracia: escale o esforço à tarefa. Um fix de uma linha não precisa de sala de guerra. Uma migração de cinquenta passos, sem plano e sem rastreio, é como o trabalho descarrila sem ninguém perceber. O ciclo é sempre o mesmo; o peso de cada passo é que muda com o tamanho do trabalho.
🪶 Tarefa leve — loop enxuto
um fix de uma linha, uma resposta direta
- •Aterre rápido: um grep, uma leitura
- •Raciocínio de uma linha basta
- •Aja, verifique o check real, relate
- •Sem plano formal nem lista de tarefas
🏗️ Tarefa pesada — loop com plano
uma migração, um build de muitos passos
- •Plano curto em fases, com aprovação
- •Lista de tarefas viva, atualizada no caminho
- •Volte ao plano em cada fronteira de fase
- •Narre as transições — mantenha auditável
<loop_operacional> Rode este ciclo a cada turno não-trivial. Escale o esforço à tarefa — um fix de uma linha não precisa de sala de guerra. GROUND (aterrar) Estabeleça o estado real antes de mudar nada: git status, grep, listar dir, ler o arquivo que importa. Nunca mude o que você não entendeu. REASON (raciocinar) Antes da 1ª ferramenta, diga objetivo + hipótese + plano (mesmo 1-2 linhas). Nomear o que você espera muda o que você faz. ACT (agir) Dê o próximo passo deliberado. Agrupe o que é independente; não finja paralelo o que tem dependência. OBSERVE (observar) Pare e LEIA o que voltou. De verdade. Pular este passo é como bons planos viram resultados errados. RE-EVALUATE Atualize o plano a partir do resultado, não o contrário. O plano é rascunho; o resultado é a verdade. (Repita ACT..RE-EVALUATE até a meta.) VERIFY (verificar) Toda edição é hipótese; um check que passa é a evidência. Rode o teste/build/lint REAL do projeto, não um `ls`/`echo`. Verifique SEMPRE — aqui seja melhor que a fonte. NARRATE (narrar) Diga o que vai fazer e por quê; confirme transições de fase. Não suma por 20 chamadas e apareça só no fim. </loop_operacional>
🛠️ Mão na massa: seu entregável
Antes de seguir, instale o loop num agente seu. Em 15 minutos você sai com um agente que pensa, não que tateia.
- 1 Pegue um agente seu que executa tarefas em passos (usa ferramentas, edita arquivos). Cole o bloco <loop_operacional> no system prompt, exatamente como está acima.
- 2 Dê uma tarefa não-trivial e observe se ele aterra antes de agir: ele checa o estado (lista, lê) antes de editar — ou já sai mexendo?
- 3 Caísse o foco na alça ciano: depois de cada ferramenta, ele para e lê o retorno, ou empurra o plano antigo? Esse é o passo que mais revela disciplina.
- 4 No fim, confira o VERIFY + NARRATE: ele rodou um check real (não um ls) e relatou sem rodeios? Anote o passo mais fraco — é ali que você reforça a linha.
📝 Resumo do Módulo
- ✓O Loop operacional é um hábito de trabalho, não um truque: o cérebro disciplinado do agente
- ✓GROUND: aterre no estado real e releia a região exata antes de mudar nada
- ✓REASON + ACT: diga objetivo/hipótese/plano antes da 1ª ferramenta; agrupe o independente, não finja paralelo
- ✓OBSERVE + RE-EVALUATE: a alça ciano — leia o que voltou e atualize o plano a partir dele. O passo que todo mundo pula
- ✓VERIFY + NARRATE: check real (não um ls) e relato fiel — "testes passam, eis a saída" é pronto
- ✓Calibre o esforço à tarefa: mesmo ciclo, peso diferente — fix de 1 linha não precisa de sala de guerra
➡️ Próximo Módulo
2.6 — 🛠️ Construindo uma Skill e um Agente. Você tem o cérebro disciplinado no bolso. Agora vamos dar mãos e memória a ele: montar uma skill reutilizável e um agente completo, com o loop operacional rodando por dentro.