Lecture 10. When a Graph Is the Wrong Tool

Illustrative composite. A one-person team asked for help fanning out their weekly expense-report review — twelve receipts a week — into a graph with parallel extraction nodes, a router, a verifier, and durable state. Every technique in this course, applied correctly. It took three days to build and it processed twelve receipts a week that a single agent, run once, in one context window, had already been handling correctly in under two minutes.

Nothing about that graph was wrong. It was well-designed. It was also solving a problem that didn't exist yet — twelve receipts a week never needed independence, verification, or crash recovery. This lecture is the one this course has been building toward without saying it outright: knowing when to reach for everything in Lectures 01 through 09 is a different skill from knowing how, and it's the one that actually saves time.

Keep One Agent in One Loop When

• The task is short. A single run finishes in a context window with room to spare.
• A single context holds everything relevant. Nothing needs to be discovered by a separate branch that the main thread doesn't already have.
• There are no independent branches. Every step genuinely reads the last one's output — the reads/writes audit from Lecture 02 comes back empty.
• Failure is cheap. A wrong answer costs a quick re-run, not a compliance incident.
• A person can check the result in a minute. The verifier from Lecture 07 exists to replace a check nobody has time to do by hand — if a human glance already does the job, the extra node is solving a problem you don't have.

Decide now: score the opening's expense-report case against these five criteria before reading on.

The twelve-receipts-a-week case fails all five in the wrong direction: short task, everything fits in one context, no independent branches worth fanning, a wrong categorization is a two-minute fix, and the person doing it was already glancing at the output anyway. A loop was always the right tool. Building the graph anyway cost three days of engineering for a task a loop was already finishing correctly in under two minutes a week — that's the price of picking the rejected option.

Reach for a Graph When

• Work can genuinely run in parallel — the audit from Lecture 02 finds real independent branches, not just steps that happen to be unrelated in passing.
• Different nodes need different tools or permissions. One node reads contracts, another files them somewhere with write access — separating those is a safety boundary, not just an architecture preference.
• Outputs need independent verification. Lecture 07's fresh-context check matters because the stakes of being wrong are real.
• The run has to survive an interruption. A three-hundred-contract overnight batch (Lecture 08) can't restart from zero every time something crashes.
• Cost and authority need to be controlled by route. Lecture 06's classify/route split and Lecture 09's short paths only pay off when different inputs genuinely deserve different handling.

"Complex" doesn't mean "many steps." A twenty-step linear pipeline where every step reads the last one doesn't need a graph — that's a well-audited chain, and Lecture 04 already covers what to do with it: leave it as a chain. A five-node structure with a real fan, a real rollback, and a real human-approval gate needs a graph even though it's smaller. The deciding factor is never step count. It's whether real branches, real verification needs, and real interruption risk are present.

diagramsource

drawing

The Five Layers, in Order

Everything in this course sits on top of four other layers, and none of them go away once a graph exists — a graph's nodes still carry all four underneath them.

Layer	Controls	Answers
Prompt engineering	The instruction	How do we tell the model what to do?
Context engineering	The information	What should the model know before it decides?
Harness engineering	The machinery	What runs around the call — environment, verification, state?
Loop engineering	The runtime	How does one unit of work improve through feedback until it's done?
Graph engineering	The system	How do multiple nodes, loops, and evaluators coordinate?

Read this course's own running example against the table: extract liability's prompt (prompt layer) reads a specific clause type from a specific slice of context (context layer), runs inside a harness that gives it the contract text and a way to signal clause_not_found (harness layer, and this course's companion — see below), retries up to twice on failure before escalating (loop layer, the controlled cycle from Lecture 04), and sits as one node among many others, coordinated by a route table and joined into a batch report (graph layer — this course).

The model is one node in that picture. Everything that makes the whole system reliable, fast, and affordable — the instructions, the information, the machinery, the retry logic, and the coordination between all of it — is the system built around the model, one layer at a time.

Going From One Prompt to a Hundred Agents

Is not a matter of spawning more. It's a matter of knowing which arrows in your diagram were never real — the question this course opened with in Lecture 01, and the one every lecture since has been one way of answering. A hundred independent, well-contracted, verified, durable, correctly-priced branches earn their existence when the task is genuinely wide. The twelve-receipts-a-week task never needed a hundred of anything. Knowing the difference is the actual skill this course teaches.

For the harness and loop layers underneath graph engineering, this academy's own Harness Engineering course covers both in depth — start there if a task in front of you turns out to need a loop, not a graph.

Faded case

Skip to the open case if this is familiar. A different team wants a graph for reviewing incoming vendor invoices: forty a day, arriving in batches, each one needing three checks — does the amount match the purchase order, is the vendor on the approved list, has this invoice number already been paid before. Nobody looks at an invoice that passes all three; a person only opens the ones that fail, a handful on most days, in a couple of minutes each. One invoice most weeks arrives corrupted and needs a manual re-scan, and nothing else in that day's batch depends on that one invoice finishing first. Decide now: loop or graph, and which specific criterion from this lecture actually decided it for you, not just your gut?

Open case

Exercise 1 below asks you to score a task you're genuinely unsure about against both sets of criteria. Use a task from your own queue instead of a hypothetical one, and let the count of criteria cleared decide it instead of your first instinct.

Key Takeaways

• A well-built graph solving a problem you don't have is still the wrong tool. The five "keep it a loop" criteria — short, single-context, no independent branches, cheap failure, human-checkable in a minute — catch this before three days go into a graph a loop would have handled in an afternoon.
• Step count is not the deciding factor. A long, genuinely sequential chain stays a chain. A small structure with real branches, real verification stakes, or real interruption risk earns a graph.
• Five layers stack, they don't replace each other. Prompt → context → harness → loop → graph — a graph's nodes still carry a prompt, context, a harness, and a loop underneath them.
• When one node misbehaves, check its own layers before redesigning the graph's shape. A correctly-wired graph can't compensate for a node broken at the prompt, context, or harness level.

What You Have Now

A one-page decision note: does a specific task of yours earn a graph, or does it stay a loop, with the five layers placed in order underneath it. It sits at the front of your design document as the judgment call everything else in the course assumed you'd already made. It closes the loop this course teaches — Map, Contract, Route, Verify — with the one check that decides whether to run it at all.

Save it as graph/lecture-10.md; the lab's checker looks for that file at that path.

Exercises

1. Score a real candidate. Take a task you're genuinely unsure about "graphifying." Score it against the five loop-criteria and the five graph-criteria in this lecture. If it clears more loop criteria than graph criteria, that's your answer — don't build the graph anyway.
2. Place one failing node in the five layers. Find a node in a graph you run (or plan to run) that's currently producing bad output. Walk it through the five-layer table and name, specifically, which layer is actually broken before touching the graph's shape.

Check your understanding