PTENES
Skip to content
MODULE 3.2

⚖️ The Real Comparison

Agentic, loop, and graph aren’t a ranking — they’re three different structures for three problem sizes. This is the module you keep: the same case, built in all three forms, so you can see for yourself where each one wins and what it costs.

6
Topics
45
Minutes
Central
Level
Comparison
Type
Progress in this module
0%0 of 6
1

🧭 Understand “agentic”: an agent with tools and judgment

"Agentic" describes a way to use a model, not an architecture. You describe the goal, provide a set of tools (search, terminal, file editor), and let the model decide, step by step, what to do next. There is no predefined path diagram—the path is discovered in real time, within the conversation itself.

🆕 New here? Two words before you continue

  • Model’s judgment: the decision about "what to do now" happens inside the model’s head, token by token—there’s no line of code that says "after this, do that."
  • Output test: an explicit, verifiable condition that says when the work is done (e.g., “the tests passed”). Purely agentic systems rarely have one; they stop when the model “thinks” it’s done.

This isn't a defect; it's the defining feature. It's exactly right for open-ended, exploratory tasks — “investigate this strange bug,” “read this repository and tell me what it does” — one-off tasks where you don't know in advance which steps you'll need. Trying to draw the flowchart first would be a waste of time: you don't know the flow yet.

✓ Agentic works well when

  • ✓The task is exploratory — you don’t know the steps in advance
  • ✓Runs once or a few times, under human supervision
  • ✓The cost of a wrong step is low and reversible

✗ Agentic is costly when

  • ✗The task repeats every day — you explain the same objective again and again
  • ✗Needs a guarantee that “this will always happen in this order”
  • ✗No one can predict token costs because the path changes every round

Key concepts

Decision

Lives in the model's head

Tools

You provide it; the model chooses whether to use it

No cycle drawn

Path discovered on the fly

Open task

Run it once, for exploration

2

🔁 Understand “loop”: the cycle drawn with an exit test

In a loop, you stop writing prompts and start designing cycles. Instead of trusting the model to remember to check its own work, you write that in code: discover → plan → act → verify → stop. The structure leaves the model's head and becomes something you can read, version, and test.

💡 The stopping condition is what changes everything

A loop only becomes a real loop when there is a output test explicit — something you can run that returns yes/no: "the tests passed," "the schema validated," "the reviewer's score is greater than 8." Without this test, you just have an agentic with one more turn.

  • •The model still decides what to do within each stage, but no longer decides the order of the steps
  • •You gain reproducibility: the same process runs the same way on Monday and Friday
  • •You pay in engineering: someone has to write and maintain this cycle

Works for repeatable tasks with verifiable success criteria: generate a report every morning, fix a bug until the tests pass, write a piece until it passes a quality checklist. If you run the same thing more than once and can tell when it worked, the loop is the right structure.

Key concepts

Drawn cycle

Discover/plan/act/verify/stop

Output test

Verifiable condition, not "a hunch"

Structure in code

Out of your head, into an artifact

Repeatable task

Runs every time, with clear criteria

3

🕸️ Understand “graph”: compound loops with explicit edges

A graph (in this sense of agent architecture) is several loops connected by written-out edges before to run. Each node in the graph is itself a loop — with its own model, its own tools, its own permissions, and its own instructions. The path between the nodes are what the graph adds.

graph — the path between the nodes is written before running in node A loop in node B loop in node C loop each box is still a loop — what changes is the edge BETWEEN them, written before you run it

What to look at: the dashed box is new, but its contents aren’t— each node still has its own little loop (the word "loop" written inside it). The graph doesn’t replace the loop; it composes loops. And what the next topic will build with a real case.

Key concepts

Node = loop

Each node has its own cycle

Prewritten edge

The path exists before it runs

Isolation

Model, tools, and permissions specific to each node

Composition

Graph composes the loop; it doesn't replace it

4

📰 Build the same case in all three formats

The case is a daily research summary: every morning, the system reads a few sources on a topic, writes a one-page summary, and checks that it’s accurate before sending it. We’ll build this same system three times—and compare what happens in each version.

1

As a single overloaded loop

One agent does everything in a single window: searches for sources, writes, reviews.

It opens the sources one by one — because a loop is sequential by design — and dumps the raw HTML for each one into the same context (the window of text the model is "seeing" at that moment). By the time it reviews, that context has become a swamp: raw HTML, half-written prose, and earlier reasoning all floating together. And worst of all, it reviews in the same context where it wrote—so it tends to rubber-stamp its own work.

2

As a small graph

Three nodes, state flowing between them, each with its own context.

Researcher opens in N sources in parallel — that’s fan-out: breaking a task into several branches at once. It delivers only the notes (not the raw HTML) to the writer, which receives a clean context — without the search clutter, only what's needed to write. The writer hands the draft to reviewer, which also has new context: it sees only the text and the quality criterion, with a “rejected” edge back to the writer if it doesn’t pass.

f1 f2 fN researcher fan-out across N sources notes writer clean context draft reviewer new context rejected + critiques (back to the writer) sends

What to look at: three things cross the edges— notes, draft e criticism — and none of them is the raw HTML from the sources. That’s what separates the graph version from the single-loop version: each node receives only what it needs, never the entire transcript from the previous node. (Transcript = the complete history of a conversation/run, including all intermediate reasoning—useful for debugging, too heavy to pass along as input.)

Dimension agentic loop graph
Who decides the next stepthe model, with each tokenthe model, within a fixed cyclethe model, inside each node; routing between nodes is fixed
Where the structure liesin the model's headin code, a cyclein code, a diagram of nodes and edges
Parallelismnone nativenone—the loop is sequential by designfirst-class fan-out/fan-in
Contexta single window, growing without limita window around the cycleone clean context per node
How you debugreading the entire transcriptreading the transcript of each iterationreading the diagram + the state on each edge
Maintenance costlow (prompt only)medium (cycle + stopping condition)high (N prompts + state schema + routing)
When to useopen task, runs oncerepeatable task, one agent is enoughrepeatable task that needs real specialization/parallelism

Key concepts

Same case

Daily brief in all three formats

Fan-out

Split one task into N branches

Clean context

Each node sees only what it needs

Back edge

A failure sends you back to the writer

5

✨ Learn what the graph genuinely makes possible

These are three concrete things, not a vibe of “more advanced.” First: in parallel specialized nodes with clean, separate contexts — the researcher doesn’t carry the reviewer’s vocabulary, and the reviewer doesn’t carry the search noise. Second: fan-out and fan-in as a first-class movement — split a task into N branches, run them at the same time, and combine the result. Third: explicit and auditable control flow — the path is a diagram you can read, not something you reconstruct by reading a 40-thousand-token transcript.

DEPTH — the loop at the at the at the end BREADTH — the graph plan ag1 ag2 agN result

What to look at: the two sides solve "doing more" in opposite ways. The loop grows to low — more iterations in the same node. The graph grows to outside — more nodes running at the same time. You can’t do a true fan-out inside a single loop; it only knows how to repeat, not split.

Overview in four stages showing the evolution from agentic to loop and then to graph, with a horizontal band comparing loop (single cycle, sequential) and graph (parallel nodes connected by edges with fan-out and fan-in).
What to look at: the band separating loop from graph in this overview is the same divider as in the SVG above—depth on one side, breadth on the other. The four stages aren’t a maturity ranking; they’re four answers to different questions about the same problem.

Key concepts

Specialized node

Clean, separate context

Fan-in

Join the N branches back together

Auditable

A diagram you can read, not reconstruct

Breadth x depth

Graph grows outward; loop grows downward

6

💸 Know what the graph costs

None of this is free. You now have to maintain three prompts instead of one — each node has its own instructions, and the three need to evolve together without breaking the edges between them. You need to define a state schema: the exact format of what the researcher delivers to the writer, and what the writer delivers to the reviewer. Without this written contract, the nodes start disagreeing about what “notes” or “draft” mean.

⚠️ Failure modes that only exist in the graph

  • A merge that silently swallows a source — the fan-in joins 5 branches, one failed, and no one noticed that a source was missing from the final summary.
  • Routing that keeps going back and forth forever — the “rejected” edge sends it back to the writer, who writes again and is rejected again, with no limit on attempts.
  • State leaking from one node to another — the context that should be clean carries junk from the previous node because the state schema wasn’t followed.

✓ Overhead improves quality when

  • ✓The task runs every day — the fixed cost of building the graph pays off over repeated runs
  • ✓There is real parallelism to explore (N sources, N branches)
  • ✓Specializing each node really does improve the result (reviewer with independent criteria)

✗ Overhead is pure tax when

  • ✗The task runs once — you never recoup the cost of setting up three prompts
  • ✗There's nothing to parallelize—it's a genuinely sequential process
  • ✗A single node with all the tools and all the instructions — that’s a loop reinvented; the graph structure isn’t doing anything

🧪 Practical example: degenerate graph vs. real graph

Objective: compare the same thing grafo.json of the daily brief in two formats—the “single-node graph” (graph name, loop body) and the three-node version (a real graph)—and see the difference in the file itself.

// grafo.json — VERSAO DEGENERADA (1 no, todas as ferramentas, todas as instrucoes)
{
  "nodes": [
    { "id": "faz-tudo", "model": "<seu-modelo>",
      "tools": ["buscar", "escrever", "revisar"],
      "prompt": "Busque as fontes, escreva o resumo e revise ate ficar bom." }
  ],
  "edges": []
}
// isto NAO e um grafo funcional — e um loop com nome de grafo.
// zero arestas = zero coisa que a estrutura de grafo esta fazendo.

// grafo.json — VERSAO DE TRES NOS (grafo de verdade)
{
  "nodes": [
    { "id": "pesquisador", "model": "<modelo-rapido>", "tools": ["buscar"],
      "prompt": "Para cada fonte em paralelo, extraia so os fatos relevantes ao tema." },
    { "id": "escritor", "model": "<modelo-de-escrita>", "tools": [],
      "prompt": "Com base APENAS nas notas recebidas, escreva um resumo de 1 pagina." },
    { "id": "revisor", "model": "<modelo-critico>", "tools": [],
      "prompt": "Compare o rascunho com as notas originais. Aprove ou reprove com criticas especificas." }
  ],
  "edges": [
    { "from": "pesquisador", "to": "escritor", "carrega": "notas" },
    { "from": "escritor", "to": "revisor", "carrega": "rascunho" },
    { "from": "revisor", "to": "escritor", "quando": "reprovado", "carrega": "criticas", "limite_voltas": 2 }
  ]
}

How to verify: count the edges. If the "graph" version of your project has zero edges or a single node with all the tools, it's the degenerate version— a disguised loop. If it has edges with carrega defined (what passes from one node to another), it’s a real graph.

Bias test: ask Claude Code to judge one of your tasks and say whether it calls for agentic, loop, or graph — requiring it to justify why the other two don't work. If it answers "graph" for a task that runs <uma vez so>, that’s hype bias. Ask about the maintenance cost: how many prompts, what state schema, and what new failure mode it introduces.

Quick check (nothing is blocked): You have a graph with ONE node that has all the tools and all the process instructions. What is it, really?

Key concepts

State schema

The contract between us

N prompts

One per node, evolving together

New failures

Merge, routing loop, leak

Degenerate node

1 node with everything = disguised loop

📌 Module Summary

✓
Agentic — decision-making inside the model’s head, with no drawn cycle; works for an open-ended task that runs once.
✓
Loop — a cycle drawn with an explicit exit test; works for repeatable tasks with verifiable criteria.
✓
Graph — compound loops, with explicit edges written before running; each node is its own loop.
✓
What is truly new — specialized nodes with clean context, fan-out/fan-in, auditable flow.
✓
What is just a new name — the word "graph"; state machines and orchestration existed before.
✓
The sentence that holds up — “a loop is a node in the graph.” You don’t graduate from loops to graphs; you compose loops into graphs when one loop is no longer enough.

Next Module:

3.3 — Myth vs. fact: separating what graph engineering promises from what it actually delivers.