🛠️ Hands-on practice
The path where you build. Migrate a real loop case to a graph using clear criteria (and know when NOT to migrate), model the graph for your own business and backlog, and leave with a library of ready-to-use prompts to design, generate, and audit graphs.
What to look at: the first question already eliminates most cases— if a loop can still handle it, the right answer is to improve the loop, not migrate. "Build the graph" is the rarest leaf on this tree: it’s the exception, not the rule. Many problems that seem to require a graph can be solved with a better checker, which is cheaper and faster to build.
Learning path map
Detailed content
🔀 From loop to graph
The step-by-step migration of the daily summary, with the signals that justify migrating and what to measure before and after.
Three legitimate reasons to migrate: you need to run parts at the same time; you need a reviewer who can’t see how the work was done; the context is turning into a swamp and the agent is losing the original instruction.
If none of the three is present, improve the loop. Migrating without one of these signals means taking on complexity for free.
The three signals sum up everything tracks 2 and 3 have already shown: parallelism, clean context, and context swamp.
Record cost per run, total time, and a quality measure you can verify — before changing anything.
Migrating without a baseline is faith, not engineering. Without before numbers, you’ll never know whether the graph was worth it.
The three measures—cost, time, and quality—are the same ones you’ll compare again in topic 6.
Break the loop where responsibility, the tool, or the required context changes. In the daily summary, that gives you three natural nodes: who searches, who writes, who checks.
Cutting in the wrong place gives you a graph with artificial nodes that only complicate things. Cutting in the right place gives you nodes that were already there, hidden in the loop.
A change in responsibility, tooling, or context—any one of the three justifies a split.
Before coding, define what each edge carries: the researcher delivers notes (not raw HTML), the writer delivers a draft, and the reviewer returns approval plus criticism.
Without an explicit contract, each node ends up sending whatever is left in its own context—and the swamp comes back through the back door.
This is the state schema in miniature: field name, format, and whether it's required.
The reviewer sends a rejection back to the writer, with at most N cycles and a progress criterion.
Without a cap, the bill is infinite—the same problem as a loop without a stopping condition, now inside a graph node.
Iteration cap + progress criteria, not just an iteration cap. Without measured progress, N iterations spend N times on the same mistake.
Run both in parallel for a few days with the same inputs and compare against the baseline from topic 2.
If the graph didn't improve any of the three measures, go back to the loop: you took on complexity without getting a return.
Acknowledging that it wasn’t worth it is part of the work, not a failure. Migration is a tested hypothesis, not a belief.
📊 Business and task graphs
Model what you already have. The business funnel with multiple metrics and the backlog with dependencies and blockers — two graphs that already exist in your company, even if no one has drawn them.
Campaign, traffic, landing page, signup, activation, retention, LTV, churn; nodes are customer states and edges are conversion rates.
The funnel is already a graph—people just don’t usually draw it that way. Drawing it makes it visible where the customer actually drops off.
Each edge is a measurable conversion rate, not a decorative arrow.
Churn and acquisition cost feed back into the start of the funnel, closing a cycle in the business graph.
This is the feedback loop that gives the system behavior of its own — and what a short-sighted agent, looking only ahead, doesn’t see.
A funnel without the return edge is a snapshot; with it, it’s a dynamic system.
"LTV over CAC needs to be greater than 3" is a relationship between two metrics, not a standalone metric.
A loop with a single objective can’t even express this relationship — it only sees the metric you gave it.
A constraint between nodes is another form of edge—invisible to anyone thinking in terms of a single metric.
The backlog has three types of edges: decomposition (an epic contains a story, which contains a task), dependency (must finish first), and blocking (prevents work from starting).
Confusing the three makes the backlog turn into a misleading tree. Only the first is a hierarchy; the other two turn the tree into a real graph.
Decompose ≠ depend ≠ block. A backlog tool that treats all three the same hides information.
Count how many tasks are ready at the same time — the width of the backlog graph level.
This is how you size teams or agent groups for real, instead of guessing how many will “fit” in the sprint.
Level breadth is the same idea as fan-out — how many independent nodes exist at that point in the graph.
With the business or backlog graph written out, an agent can propose an allocation, identify the bottleneck, and simulate the side effects of a change.
Without the graph, the agent only comments on the metric you cited—it can’t see the system, only the point you pointed out.
The written graph is what turns “ask the agent” into “give the graph to the agent.” The difference is enormous.
📋 Prompt library
Six ready-to-use prompts, tested in the format objective + copyable block + how to verify. The module you’ll come back to for reference.
You describe a process in plain text, and the agent returns nodes, conditional edges, and what passes along each edge, in JSON.
And the fastest starting point for moving from “process in your head” to “process drawn out.”
JSON of nodes and edges is the common format that the next prompts in this list assume as input.
The second step in the two-step method: draw any graph, then ask the agent to generate the script that runs it.
This is how you go from diagram to code without writing the orchestration by hand — the agent translates, you review.
Designing and generating are intentionally separate steps: designing is human thinking; generating is mechanical work.
Look for cycles with no exit, edges without conditions, nodes with no cost ceiling, joins that don’t check cardinality, and state that leaks between nodes.
These are the same flaws that track 4 taught you to recognize — now automated in a single checking prompt.
Graph auditing and graph verification—the same principle from module 2.2 applied to the structure, not the result.
Given a set of automated objectives, identify which ones put pressure on each other and which metric’s side effect the other is.
A collision between loops (track 2, failure 3) only shows up when someone — or something — looks at the whole picture. This prompt automates that review.
A collision becomes visible when you draw the edge between two loops — and that's the edge the prompt looks for.
Given two neighboring nodes, define the contract for the edge between them: field names, format, what’s required, and what explicitly must NOT pass through.
What must NOT pass is the part everyone forgets—and the part that keeps the context from turning into soup again inside the graph.
State schema formalizes the contract that topic 4 of module 5.1 already asked you to write by hand.
Reverse the order: first decide how you'll know it worked, with a bad test case; only then write the agent prompt.
And the close of the entire course in a single habit: verifier first, always — loop, node, or entire graph.
The same principle from module 2.2, now packaged as a ready-to-use prompt for any new node you create.