Course map · Module 1 of 6

Node and Edge Engineering

Central question: What work is actually dependent?

The craft module. You learn to see work as bounded nodes and honest edges, to type the state that travels, and to make endings explicit — the four skills every later module assumes.

Tool labs · Pydantic Graph, LangGraph   Expert lenses · Samuel Colvin, Harrison Chase
LESSON 1.1

Nodes as bounded responsibilities

Core idea

A node is one unit of work with one job: bounded input, bounded output, nothing smuggled through side channels. A node earns its existence only through a real specialty — a different model, a different toolset, or a genuinely separate role like a read-only reviewer. Steps you could inline into an existing node are not nodes.

Expert lens

Samuel Colvin's whole ecosystem is this lesson in code: a Pydantic model is a boundary you can trust, and Pydantic Graph extends the same typing discipline to execution.

Tool lens

In Pydantic Graph a node is a class whose run() signature declares exactly what it consumes; in LangGraph it's a function over a typed state. Both make the boundary syntactic — the compiler becomes your first reviewer.

Build

Write the contract for a three-node pipeline (extract → assess → summarize) as three Pydantic models. No field may appear in two models unless it genuinely travels.

Verify

Feed a malformed input; the failure must happen at the boundary with a validation error naming the field — not three nodes later as garbage output.

Connect

Adds node = bounded responsibility, the anchor for every pattern in the Studio.

LESSON 1.2

Edges are data dependencies — hunt the false ones

Core idea

An edge exists only when data actually crosses it. 'And then' in your plan is not an edge; it's often just the order you happened to type things. False edges are the single biggest source of slow agents: they serialize work that could run at once and chain failures that should be independent.

Expert lens

Harrison Chase's framing: the move from chains to graphs is precisely the move from implied order to explicit dependency.

Tool lens

LangGraph makes edges explicit calls — add_edge('a','b') — so every dependency is a reviewable line of code, not an accident of prompt order.

Build

Take a five-step linear agent (yours or the provided starter). For each of the four arrows, write down the exact variable that crosses. Delete every arrow with no variable; redraw the graph with the survivors.

Verify

The redrawn graph must have at least two nodes with no path between them — proof you found real parallelism. Run both versions; the graph version must produce the same output.

Connect

Adds the false-edge test — reused in Module 2's fan-out and Module 6's simplification.

LESSON 1.3

Structured state and typed contracts

Core idea

Shared state is where graphs rot. The fix is boring and absolute: give state a typed schema, decide which nodes may write which fields, and validate on every hop. A sloppy write in node two otherwise becomes a confident input to node five, and nobody notices until the output is wrong.

Expert lens

The 12-factor agents rule 'unify execution state and business state' — your progress tracking and your data live in one schema, so a crash loses nothing.

Tool lens

Pydantic Graph validates state transitions at runtime and detects invalid ones; LangGraph reducers control exactly how parallel writes merge. Both are the same idea: writes are governed, never free.

Build

Define the full state schema for the Module 1 project before writing any node. Mark each field read-only, write-once, or append-only.

Verify

Attempt an illegal write from the wrong node. The run must fail loudly at the write, not silently downstream.

Connect

Adds typed-state; Module 3 extends it into state that outlives the run.

LESSON 1.4

Explicit stopping and finite-state-machine thinking

Core idea

Every graph needs to know how it ends. FSM thinking makes termination a first-class design element: enumerate the states, make every transition explicit, and make 'done' a state you can only reach through a verifying transition — never a feeling the model reports.

Expert lens

Colvin's Pydantic Graph documents itself as a finite-state-machine library first; the graph drawing is a byproduct of naming your states honestly.

Tool lens

In Pydantic Graph, a node's return type IS the edge — return End(result) and termination is visible in the type system. Mermaid output renders your FSM for free.

Build

Convert the fragile linear starter agent into a typed four-to-six-node graph: distinct states, return-type edges, one bounded retry cycle, one explicit End.

Verify

Render the Mermaid diagram from code. It must match your napkin drawing from Module 0 — and the retry cycle must provably terminate (max-attempts test passes).

Connect

Completes the Module 1 cluster; your learning graph now has a verified build edge, not just understand.

LESSON 1.5

The classical toolbox: what graph theory gives the graph engineer

Core idea

Workflow graphs obey theorems written decades before LLMs. A runnable workflow is a DAG, and every DAG admits a topological order — that order is your scheduler, and any two nodes with no path between them can run in parallel. The longest weighted path through the DAG is your critical path: the floor on latency and cost, and the first place optimization pays. Cycles are only legal inside declared loop boundaries; everything else must sort.

Expert lens

William Fiset’s Graph Theory algorithms course (freeCodeCamp, 6¾ hours, from a Google engineer, with working source code): DFS and BFS, topological sort, DAG shortest and longest paths, Dijkstra, Bellman–Ford, Floyd–Warshall, bridges and articulation points, Tarjan’s strongly connected components, TSP, Eulerian paths, and minimum spanning trees. The highest-value stretch for this module: topological sort at 56:23 and DAG paths at 1:09:52.

Tool lens

Every framework in this course runs these algorithms under the hood. LangGraph’s execution order is a topological sort with joins. Pydantic Graph’s invalid-transition detection is reachability checking. A workflow engine’s parallel fan-out is simply the set of nodes your dependency order leaves unordered.

Build

Take your Module 1 project graph and compute by hand: one valid topological order; the batches of nodes with no path between them (your parallel waves); and the critical path, assuming a latency for each node.

Verify

Run two classical checks. Tarjan’s: every strongly connected component with more than one node is a cycle — name its stop condition or redraw. Articulation points: any node whose removal disconnects the graph is a single point of failure — decide deliberately whether it earns a retry policy, a replica, or a redesign.

Connect

Adds classical-toolbox beneath nodes-and-edges. Module 2’s routing and fan-out are these theorems wearing production clothes.

Unlock the rest of Module 1

Lesson 1 of every module is open. The full module — all lessons, the tool lab, and the graded project — unlocks with any plan.

Try Free — 30 Days (no card) Own the course — $6.93 Compare plans

Purchased already? Sign in with your checkout email.

Tool lab

Pydantic Graph + LangGraph, side by side

Build the same four-node graph twice: once in Pydantic Graph (return-type edges, FSM validation, Mermaid render) and once in LangGraph (typed state, add_edge, checkpointer). You will feel where each framework puts the guarantees — types at rest vs. structure at runtime.

Module project · graded by evidence

Convert a fragile linear agent into a typed graph

You receive a working but fragile 120-line linear agent (research → draft → cite → format, all in one loop). Ship it back as a typed four-to-six-node graph.

Acceptance criteria — all must be demonstrably true:

  • Every node has a typed input/output contract; malformed data fails at the boundary
  • At least one false edge from the original is gone — two nodes now run in parallel
  • One bounded repair cycle exists and provably terminates
  • The Mermaid diagram is generated from code and matches the design drawing