You already know what a node, edge, state, verifier, and cost ceiling are — that's what the whole course covered. This module doesn't teach a new concept. It packages everything into six copy-run prompts, each one solving a specific piece of graph engineering work. Use the table below to quickly find which prompt fits what you’re working on right now.
| Prompt | Use when | What it returns |
|---|---|---|
| 1. Draw the graph | You have a process described in plain text, with no structure | JSON with nodes, edges, and ambiguity questions |
| 2. A graph becomes a script | You already have a grafo.json and want the code that runs it | A script that traverses the graph with limits on cost and number of rounds |
| 3. Audit the graph | You want to find defects before running in production | List of the five structural flaws, one by one |
| 4. Collision between loops | You have several automated objectives running at the same time | Tension pairs, metric-side effect, missing constraint |
| 5. State schema | Two neighboring nodes, and you don’t know what passes between them | Edge contract in JSON Schema, including what MUST NOT pass |
| 6. Verifier first | An agent that delivers poor work and you don’t know how to measure it | Verifier + bad test case, then the agent prompt |
What to look at: the top box has only five outputs—you always start with what you HAVE (text, grafo.json, a list of objectives, two nodes, or a bad output), not what you want to produce. Also notice that two branches (grafo.json) lead to different prompts: one audits, the other executes. They’re separate steps.
Detailed content
🗺️ Draw my process graph
Objective: you describe a process in your own words, in plain text, the way you’d explain it to a new colleague. The agent returns the first structured version — nodes, edges, and a list of what was ambiguous. Use this when no graph exists yet, just the mess in your head.
Voce e um engenheiro de grafos. Vou colar a descricao de um processo em texto
corrido. Sua tarefa:
1. Identifique os NOS — cada unidade de trabalho, decisao ou papel envolvido.
2. Identifique as ARESTAS — o que liga um no a outro, e QUANDO essa aresta e
seguida (nunca escreva uma aresta sem a condicao "quando").
3. Devolva SOMENTE um JSON no formato abaixo, sem comentario fora do JSON:
{
"nos": [
{ "id": "<nome-curto>", "papel": "<o que esse no faz>",
"modelo_sugerido": "<ex: gpt-4o-mini, claude-haiku, humano>",
"ferramentas": ["<ferramenta 1>", "<ferramenta 2>"] }
],
"arestas": [
{ "de": "<id do no de origem>", "para": "<id do no de destino>",
"quando": "<condicao exata, nunca 'sempre' se houver alternativa>",
"passa": "<o que atravessa essa aresta — que dado>" }
],
"perguntas": [
"<o que ficou ambiguo na minha descricao e precisa de resposta minha>"
]
}
Processo: <cole aqui a descricao em texto corrido do seu processo>
arestas and look at the value of
quando for each one. If ALL of them say "always," the agent has drawn a linear pipeline,
not your actual process — almost every process with more than three steps has at least one decision.
Ask it to try again: "identify where there are real decisions — where the path changes depending on a condition".
🆕 New here? Two words before you continue
- Orphan input: a possible situation that no edge covers — the flow gets there and doesn’t know where to go. It appears again in prompt 3.
- Cardinality: how many things need to arrive at (or leave) a node for it to move forward — “all,” “any one,” or “at least N.” Appears in prompt 3.
Key concepts
Unstructured prose
JSON: nodes, edges, questions
Every “when” = always
Becomes grafo.json for prompt 2/3
⚙️ Turn the Graph Into a Script
Objective: this is the second step of the two-step method — first you
draw the graph (prompt 1), then you generate the code that actually runs it. Use this when you already have a
grafo.json approved and wants to move from concept to running.
Aqui esta o grafo.json de um processo (colado abaixo). Escreva um script em <Python ou Node, escolha> que: 1. Carregue esse grafo.json. 2. Percorra os nos a partir de "<no-inicial>", respeitando a condicao "quando" de cada aresta antes de segui-la. 3. Para cada no, execute a acao descrita em "papel" (pode ser uma chamada de LLM, uma funcao, ou um print de placeholder se ainda nao tiver a implementacao real). 4. Aplique um TETO DE CUSTO total (em <tokens ou dolares>, defina um valor) — se ultrapassar, pare e reporte onde parou. 5. Para toda aresta de volta (uma aresta cujo destino ja foi visitado antes no mesmo caminho), exija um campo "max_voltas" no grafo.json e FALHE explicitamente se esse campo nao existir naquela aresta. 6. Logue cada no executado com: nome do no, duracao em ms, custo estimado, timestamp. grafo.json: <cole aqui o conteudo do seu grafo.json>
max_voltas
of a single edge back and run the script again. It MUST fail on purpose, with a clear message
pointing out which edge is missing a cap. If it runs the same way (or enters a silent loop), the script
didn’t implement the safeguard — explicitly ask for this check.
💡 Practical tip
Always request a structured log (name, duration, cost, timestamp), even in a draft. It’s the seed of your observability (module 4.3) — without a per-node log, you’ll never know which step ate up the budget when the graph grows.
Key concepts
Design, then execute
Stop and report when exceeded
Required on a return edge
Duration, cost, timestamp
🔍 Audit my graph
Objective: looks for five specific structural defects in a grafo.json before it goes into production. Use this before running anything with real costs — and before showing the graph to the team as if it were ready.
Audite o grafo.json abaixo. Procure especificamente estes cinco defeitos — nao pule nenhum, mesmo que o grafo pareca limpo: 1. CICLO SEM TETO DE VOLTAS — alguma aresta de volta (destino ja visitado) sem campo "max_voltas"? 2. ARESTA CONDICIONAL SEM "QUANDO" — alguma aresta com valor generico tipo "sempre" ou "quando" ausente, saindo de um no que tem mais de uma aresta de saida? 3. ENTRADA ORFA — existe alguma combinacao de condicoes que NENHUMA aresta cobre? (ex: no de decisao com "aprovado"/"reprovado" mas falta o caso "sem resposta") 4. JUNCAO SEM CHECAGEM DE CARDINALIDADE — algum no recebe de multiplas arestas (fan-in) sem dizer se precisa de TODAS chegarem, QUALQUER UMA, ou um numero minimo? 5. NO SEM TETO DE CUSTO — algum no (principalmente os que chamam LLM ou ferramenta externa) sem limite de custo/tokens/tempo definido? Para cada defeito encontrado, aponte: o id do no/aresta exato, por que e um problema, e uma correcao sugerida em uma frase. Se nao encontrar nenhum defeito de um tipo, diga explicitamente "nao encontrado" para aquele tipo — nao pule a categoria. grafo.json: <cole aqui o conteudo do seu grafo.json>
✓ Auditing used well
- ✓Run it before each major change to the graph, not just for the first version
- ✓Periodically test the prompt against a graph that was deliberately broken
- ✓Store “not found” explicitly—it becomes a record of what was checked
✗ Auditing used poorly
- ✗Run it once and never again, even as the graph changes every week
- ✗Accepting “looks fine” without going through all five categories
- ✗Run it only on the graph itself — never test against a known broken case
Key concepts
Cycle, condition, orphan, cardinality, cost
Case not covered by any edge
All × any × minimum N
Against a deliberately broken graph
💥 Find the collision between loops
Objective: you list the automated objectives (loops or agents) already running in your operation, and the agent points out which ones put pressure on each other, which metric from one is a side effect of the other, and which constraint between metrics is missing. Use this when you have more than one loop running at the same time — the scenario from module 2.3, applied to your case.
Aqui esta a lista de objetivos automatizados (loops ou agentes) que rodam na minha operacao hoje: 1. <objetivo 1 — ex: "loop de suporte: fecha ticket em menos de 2h"> 2. <objetivo 2 — ex: "loop de vendas: maximiza conversao do funil"> 3. <objetivo 3 — ex: "loop de qualidade: reduz taxa de reembolso"> Para cada PAR desses objetivos, responda: 1. Eles se PRESSIONAM MUTUAMENTE? Ou seja, otimizar um piora o outro? 2. Existe alguma METRICA que e efeito colateral direto de outro loop? (ex: "tempo de fechamento" cai, mas "reincidencia" sobe) 3. Que RESTRICAO entre metricas esta faltando no meu sistema hoje? (ex: "fechar rapido, MAS reincidencia abaixo de X%") Nao me diga que nao ha colisao nenhuma sem antes checar cada par explicitamente, um por um, e escrever o resultado do par.
⚠️ The agent agrees with you by default
This is why every “how to verify” section exists in this module: a language model tends to validate your question, not challenge it. If you ask “is there a collision?” in a way that sounds like you’re already expecting “no,” it will probably answer “no” even when there is one. Phrase the prompt to force an explicit check—as we did here, asking for pair-by-pair comparisons—instead of accepting a single overall verdict.
Key concepts
Explicit check, not a general verdict
A metric for one that reacts to the other
The missing “but” in your system
There’s always tension in some pair
📐 Write the state schema between two nodes
Objective: given two neighboring nodes, this prompt defines the exact contract for the edge between them — field names, format, what’s required, and what explicitly must NOT pass through. Use this when two nodes “don’t understand each other” — one sends too much data, too little data, or data in the wrong format.
🆕 New here? One word before you continue
- State schema: the formal definition of what passes along an edge—like a contract between two nodes, specifying exactly which fields, in what format, and what’s excluded. Without it, each node interprets the data differently.
Dados estes dois nos vizinhos do meu grafo: NO A (origem): <nome e o que ele faz> NO B (destino): <nome e o que ele faz> Escreva o STATE SCHEMA da aresta entre eles — o contrato exato do que atravessa essa ligacao. Devolva: 1. CAMPOS — nome de cada campo que passa de A para B. 2. FORMATO — tipo de cada campo (string, numero, enum, lista, objeto) e um exemplo de valor. 3. OBRIGATORIO x OPCIONAL — quais campos B nao funciona sem, quais sao so contexto extra. 4. O QUE EXPLICITAMENTE NAO DEVE PASSAR — liste pelo menos 3 coisas que A NAO deve mandar pra B (ex: raciocinio bruto do modelo, saida crua de ferramenta, historico completo da conversa) e por que cada uma incharia ou confundiria o no B. Devolva em JSON Schema simplificado, pronto pra colar como validacao.
Key concepts
What passes through, its format, and whether it is required
There’s always something—never an empty list
Format ready for code validation
One pair at a time, not the whole graph
✅ Write the verifier before the prompt
Objective: reverses the normal order of work. Instead of writing the agent's prompt and only then thinking about how to evaluate the output, you write first how you’ll know it worked — with a bad test case included — only then ask for the agent prompt. Use this when an agent is already delivering poor results and you realize you never truly defined what "good" means in that context.
🆕 New here? One word before you continue
- Bad test case: an example of output that looks good at first glance but is wrong—the real test of a verifier isn’t approving the good case, but rejecting the deceptive one.
Antes de escrever o prompt do agente, quero o VERIFICADOR primeiro. O no vai fazer: <descreva a tarefa do no, ex: "resumir um ticket de suporte em ate 3 frases">. 1. Escreva uma funcao ou checklist de verificacao que recebe a SAIDA do no e devolve aprovado/reprovado com o motivo. 2. Inclua pelo menos um CASO RUIM DE TESTE — um exemplo de saida que PARECE boa a primeira vista mas esta errada (ex: resumo de 3 frases que omite a informacao mais importante do ticket), e o verificador tem que reprovar esse caso. 3. SO DEPOIS escreva o prompt do agente que gera essa saida. Devolva nesta ordem: (a) verificador, (b) caso ruim de teste + resultado esperado do verificador nesse caso, (c) prompt do agente.
⚠️ This is the most important prompt in the library
All the “how to verify” items in this module exist because an agent tends to agree with you when the prompt is loose—and a verifier written after the agent, without a bad case, inherits that same looseness. Writing the verifier first, with a case that tricks it, is the only way to know whether it’s actually measuring anything or just validating what you already expected to see.
Quick check (nothing is blocked): You wrote a checker, tested it against the bad case, and it approved the bad case anyway. What does that mean?
Key concepts
Verifier before the prompt
Looks good, but it’s wrong
Approves the bad case = failure
The loop doesn’t get past the verifier
📌 Module Summary
🎯 End of the course — what stays with you
A loop already is a graph — a graph whose path returns to a previous node. You don't graduate from loops to graphs; you composes loops in graphs when one loop is no longer enough—and pays for it in new prompts, state schema, and failure modes. Get the loop right first. Only then is it worth composing.
And the course’s final takeaway: anyone who knows what a node and an edge are can absorb the next buzzword in five minutes — read the announcement, find the node and edge beneath the new name, and keep working. Anyone who doesn’t know gives everything up to study again every week. AI is a lever for what you already know — not a substitute for knowing the basics.