🔬 The verifier is the bottleneck

In topic 5 of the previous module, you saw the step verify of the loop: discover/plan/act/verify/stop. This entire module is about this single step, because it defines what the loop pursues. The loop doesn't stop when it reaches what you wanted—it stops when the verifier approves. If the verifier accepts anything, the loop delivers anything.

What to look at: six attempts on top, a narrow slice below. It doesn't matter how many times the act loop runs — what comes out is determined by the bottleneck's width, not by the number of attempts. A wide verifier (accepts almost anything) lets junk through; a verifier that's too narrow stalls the loop forever.

There isn't just one verifier. There's a ladder: compile → lint → automated test → another model judging → human. Each step costs more and catches a different type of error— compiling catches syntax errors, tests catch logic errors, humans catch judgment errors no machine can see.

What to look at: the climb from left to right. Compile and lint are nearly free and deterministic—run them on every loop iteration. Model judgments and human reviews are expensive and slower; reserve them for cases that have already passed the cheaper steps. Deterministic > probabilistic whenever there’s an option—only move up the ladder when the step below can’t detect the error you’re looking for.

Same agent, same conversation, writes and then “reviews” its own work? It almost always approves it. It’s not laziness or malice—the entire reasoning that produced that result is still right there, in the same context window, nudging the judgment toward “this is good.” A real review requires clean context.

What to look at: the dashed divider in the middle. On the left, everything lives in the same box and the arrow loops back to itself—there’s no real separation between who produced the result and who judges it. On the right, only the result and the criteria cross the boundary; the reviewer never sees the draft or the reasoning. That separation—clean context, separate reviewer—is exactly what a graph delivers for free (each node with its own context) is what a single loop has trouble doing on its own. Track 3 gives the full comparison; here we'll just cover the reason.

Every verifier compares the result with something. That something is the reference: a passing test, a previously approved example, a written rule, a target number. Without a concrete reference, verification becomes opinion—and opinions change from one loop iteration to the next.

The verifier decays over time, even if no one touches it. Tests stop covering what has changed in the code. Example data gets stale. The definition of a metric changes under the hood in another system, and no one told the verifier. Verification slips from checking reality just to compare paper with paper — and the dashboard stays green the whole time.

Same idea as writing the test before the code. Write the agent prompt verifier first, and test it against a bad result on purpose. A verifier that never rejects anything isn't verifying—it's just rubber-stamping. That verifier later becomes a at the of your graph—Trail 4 shows how.

Antes de escrever qualquer prompt de agente, escreva o VERIFICADOR para a tarefa
<descreva a tarefa, ex: "resumir um artigo em ate 5 bullets">.

O verificador deve:
1. Ser um script/funcao deterministica sempre que possivel (nao outro modelo).
2. Definir a referencia por escrito: o que torna o resultado aprovado
   (ex: "tem no maximo 5 bullets", "cada bullet tem menos de 30 palavras",
   "nenhum bullet repete a frase de outro").
3. Retornar aprovado/reprovado + o motivo.

Depois, crie um CASO RUIM DE PROPOSITO: um resultado que claramente viola
a referencia (ex: 12 bullets, ou bullets repetidos). Rode o verificador
contra esse caso ruim.

So depois disso, escreva o prompt do agente que vai gerar o resultado de verdade.