Central question: Learn not to use a graph automatically.
The gateway module, open to everyone. Before you learn to build graphs, you learn to refuse them: five shapes of work, three kinds of graph, one ruthless rule, and the napkin habit that enforces it.
Every task you hand to AI has a natural minimum shape: a prompt (one instruction, one response), a function (deterministic code, no model needed), a loop (one agent iterating with feedback), a workflow (fixed ordered steps), or a graph (multiple coordinated units with real dependencies). Most production failures start by picking a bigger shape than the work requires.
Andrew Ng's agentic curriculum builds the same ladder from first principles: reflection, tool use, planning, then multi-agent patterns — each added only when the previous rung stops being enough.
Every framework in this course can express all five shapes. That's the trap: LangGraph will happily wrap a single prompt in a StateGraph. The tool never tells you the shape is wrong — the discipline must.
Take five tasks from your actual work week. Label each with its minimum shape and one sentence of justification. No task may be labeled 'graph' unless you can name two units of work that genuinely depend on each other's output.
Show your five labels to a colleague (or a fresh AI session with no context). If they can't defeat any label with a simpler shape, you pass.
This lesson becomes the root node of your Personal Learning Graph: classify-before-build.
The word 'graph' hides two different machines. A workflow graph moves work: nodes execute, edges carry results, the graph ends. A knowledge graph stores meaning: nodes are entities, edges are typed relationships, the graph persists and grows. Confusing them produces agents that either forget everything or never finish.
Emil Eifrem's career-long argument: relationships are first-class data. Harrison Chase's: orchestration must be explicit and inspectable. Both are graphs; they answer different questions.
LangGraph and Pydantic Graph build workflow graphs. Neo4j builds knowledge graphs. Module 3 wires them together — an agent (workflow) that reads and writes durable memory (knowledge).
Draw both graphs for one scenario — 'research a company': the workflow graph of the run (plan → search → verify → write) and the knowledge graph it should leave behind (Company —CEO→ Person, Company —competes-with→ Company).
Your two drawings must have different node types and different lifetimes. If they look the same, redraw.
Adds the edge workflow-graph ≠ knowledge-graph to your learning graph.
Lesson 0.2’s two machines have a sibling. A learned graph — a graph neural network — treats relationships as signal: node features propagate along edges, and the neighborhood, not the node, becomes the predictor. Some domains are relational at their core: a stock moves because its largest customer cut orders, its sector repriced, or a shared holder liquidated a correlated book. The answer is not in the node’s own time series — it is in the web around it. Knowing this third meaning keeps you from forcing agent graphs onto problems that are actually prediction-over-relationships problems.
Venus (@RitOnchain)’s Graph Engineering for Quants masterclass: traditional models collapse relational structure into sector dummies and correlation matrices; GNNs read it directly. The production numbers are real — 78.9% directional accuracy on CSI 300 constituents (+23.5% over traditional methods), a 94% MCC improvement for GNN systemic-risk classifiers, and BlackRock running turnover-constrained GNNs across $50B in ETF assets.
PyTorch Geometric versus Neo4j. In graph learning, GCN averages a node’s neighborhood, GAT learns which edges deserve attention, and temporal GNNs let the graph itself evolve. A knowledge graph stores relationships you can inspect and explain; a GNN learns from relationships to predict. Inside an agent system, a trained GNN is just another deterministic tool node — the workflow graph calls it, it answers.
For one prediction problem you care about, draw the graph: what are the nodes, which edges exist (sector, supply chain, correlation, shared ownership), and where does the signal live — in the node’s own history, or in its neighborhood? If the neighborhood, you have a graph-learning problem, not an agent problem.
Apply the article’s hygiene rule — no graph-structure look-ahead bias: an adjacency matrix built from data may use only information inside its own training, validation, or test window. If the graph is derived from data, the graph is part of the model and must pass the same tests.
Extends 0.2’s edge to workflow ≠ knowledge ≠ learned. Route coordination to workflow graphs, durable meaning to knowledge graphs, prediction-over-relationships to graph learning.
A single agent burns roughly 4× the tokens of a chat interaction; multi-agent systems roughly 15×. Every node you add multiplies cost, latency, and failure surface. The rule this course repeats until it hurts: find the simplest solution possible, add complexity only when the task demonstrably demands it. If you can't draw the graph on a napkin, it's too complex; if collapsing two nodes loses nothing, they were never two nodes.
Anthropic's 'Building Effective Agents' says it plainly: start with simple prompts, optimize with evaluation, add multi-step systems only when simpler solutions fall short. Jeremy Howard's fast.ai method is the pedagogical twin — build the working simple thing first.
Even LangGraph's own docs concede: if your agent is a straightforward loop with tools, LangGraph is overkill. Frameworks profit from complexity; your job is to spend it only where it buys reliability.
Take a multi-agent system you've seen (or built). Challenge every node: what breaks if this merges into its neighbor? Write the answer per node. Delete every node with no good answer.
The surviving graph must be strictly smaller — and you must be able to say what each remaining node protects.
Adds minimum-necessary-architecture — the most-cited node in every later module.
The napkin drawing is not documentation — it is the design act itself. Drawing forces the three questions that code hides: which arrows carry actual data (real edges), what state travels along them, and where the graph stops. Ten minutes of boxes and arrows routinely deletes half an architecture.
The viral practitioner curricula of 2026 all converged on the same test: for every 'and then' in your plan, ask — does the next step read the previous step's output? No = no edge = run them in parallel or cut one.
Mermaid renders your napkin into versionable text. Pydantic Graph generates Mermaid from real code — in Module 1 your diagram and your program become the same artifact.
Take the ten-problem diagnostic on the course map page. Then draw, in Mermaid or on paper, the full system for the one problem you classified as 'graph'.
Your drawing passes when every edge is labeled with the data that crosses it, and there is at least one explicit stop condition drawn.
Completes orientation. Your Personal Learning Graph now has its first verified cluster; Module 1 attaches node-and-edge engineering to it.
Architecture selection has a one-line test: name the bottleneck you need to externalize. A loop externalizes iteration and evaluation. A chain externalizes task order. Parallel workers externalize search. A commit DAG externalizes experiment lineage. A knowledge graph externalizes shared facts and cross-session memory. If you cannot name the bottleneck a structure removes, you do not need that structure.
Karpathy’s autoresearch: ~630 lines of code, ~700 ML experiments in two days, ~20 optimizations kept — a ratchet loop that works because the output is verifiable, the action is reversible (git reset), the horizon is short (five-minute runs), and the environment is bounded. His next move, AgentHub (“GitHub is for humans; AgentHub is for agents”), keeps every failed branch as evidence: no main branch, no merges — the commit DAG is the search graph. Mapped onto Anthropic’s playbook in J. Parajan’s July 2026 synthesis.
Git as substrate versus orchestration frameworks: commits as nodes, parent links as edges — lineage with no framework at all. At the other end, Anthropic’s Dynamic Workflows make orchestration itself a generated script that spawns fresh-context sub-agents under concurrency caps and budgets. Same question either way: which bottleneck is this structure paying for?
For your current project, write one line per layer: “my iteration bottleneck is ___; my ordering bottleneck is ___; my search bottleneck is ___; my lineage bottleneck is ___; my memory bottleneck is ___.” Build structure only for the lines with real answers.
Run the ratchet test on any loop you plan to automate: verifiable output? reversible action? short horizon? bounded environment? Four yeses, or no autonomy.
Adds externalize-the-bottleneck — the selection twin of minimum-necessary-architecture: name the bottleneck, then build the smallest structure that removes it.
The module ends with the full diagnostic: ten real problems, each classified as prompt, function, loop, workflow, graph, or human process — with a verifier that argues back when a simpler shape would do.
Acceptance criteria — all must be demonstrably true: