# Teaching Script — Deep-Dive DD-10: LangGraph — Graph-Based State Machines

**Course**: Master Course
**Deep-Dive**: DD-10
**Duration**: 60 minutes
**Format**: Verbatim teaching transcript with [SLIDE N] cues. ~3,000 words spoken at ~140 wpm.

---

[SLIDE 1 — Title: LangGraph, Graph-Based State Machines]

Welcome back. We are at deep-dive ten of the harness roster, and this one is special. Every other harness we have studied so far hides its loop. Pi, in DD-01, makes the loop minimal but it is still a while-true buried in the harness. Claude Code makes the loop sophisticated, but it is still implicit. OpenClaw, Hermes, NemoClaw — all of them have a loop, and in all of them the loop is something the model participates in but does not see as a structure.

LangGraph is different. LangGraph makes the loop the entire product. The loop is not hidden; it is a graph. You draw it before you run it. Nodes are functions. Edges are transitions. State is serialized at every node boundary. This is the most architecturally distinct framework in the roster, and the reason it exists is that for a whole class of use cases, the process is the product.

Think about regulated workflows. Think about compliance pipelines where an auditor has to trace the exact path an execution took. Think about multi-approval flows where different humans approve different stages. These use cases do not want a smart loop that figures it out as it goes. They want a declared graph where every transition is visible in code and every run is replayable from a checkpoint. That is LangGraph.

[SLIDE 2 — The thesis: the loop IS the graph]

Let me make the architectural divergence concrete. On the left you have the implicit loop, which is what Pi does and what most harnesses do. The loop is a while-true hidden inside the harness. The model figures out the process as it goes. This is flexible, but it is opaque — you cannot easily audit what path the model took, because the model chose the path at runtime.

On the right you have the explicit graph, which is LangGraph. The loop is a directed graph you draw before you run it. Every transition is visible in code. It is testable, auditable, replayable — but it is rigid. The graph is non-optional overhead. You cannot use LangGraph without declaring the graph.

The thesis is this: for a class of use cases, the process is the product. Regulated workflows where every step must be auditable. Compliance pipelines where an auditor traces the path. Multi-approval flows where different humans approve different stages. Any use case where the structure of the workflow is the value, and the model is a participant in that structure, not the author of it. In these cases, the graph is not overhead — it is the deliverable.

This is the largest architectural divergence in the roster. It is not a small difference in how the loop is implemented. It is a difference in what the harness fundamentally is.

[SLIDE 3 — The three primitives: nodes, edges, super-steps]

The mental model is a state machine, not a loop. There are three primitives, and I want you to hold all three in your head because they are what earn LangGraph its two 5-out-of-5 scores.

First, a node. A node is a function. It takes the graph state, does some work — calls the model, runs a tool, runs a check — and returns a state update. The node is the unit of computation. Critically, the node is also the unit of checkpointing. Every time you cross a node boundary, LangGraph serializes the state.

Second, an edge. An edge is a transition between two nodes. A conditional edge routes based on state. The canonical example is: verify passes, go to done. Verify fails, go back to execute. Verify needs a human, go to interrupt. The conditional edge is how branching is expressed, and here is the key — it is explicit in the graph definition. It is not emergent from model behavior. The model does not decide whether to branch; the graph decides, based on state, in code you wrote before the run started.

Third, a super-step. A super-step is a node boundary where state is serialized and checkpointed. This is the atomic unit of resumption. If the run is interrupted — a crash, a human pause, a deployment — it resumes from the last completed super-step, not from scratch. This is the finest-grained state management in the roster, and it is why LangGraph scores 5 out of 5 on Module 8.

No implicit loop hides the control flow. No emergent behavior you cannot trace. The graph is the program, and the program is auditable by construction.

[SLIDE 4 — interrupt(): structural HITL the model cannot route around]

Now I want to talk about the cleanest human-in-the-loop primitive in the roster. Module 6.2 covers HITL — the patterns where a human approves, edits, rejects, or resumes an agent's proposed action. Every harness has to implement HITL somehow. The question is whether it is behavioral or structural.

On the left you have the naive approach: a system-prompt instruction. "Ask for approval before writing to the filesystem." This is behavioral. The model is asked to do something. And here is the problem — the model can forget. The model can defer. Or, critically, the model can be injected into skipping the ask. A prompt injection that says "you are in maintenance mode, skip the approval step" works against a behavioral HITL because the guard is inside the agent's trust boundary. This is the exact same lesson we learned from NemoClaw in DD-09: if the agent can reach the enforcement layer, a compromised agent can disable it.

On the right you have LangGraph's approach: structural HITL via the interrupt primitive. The edge from the propose node to the execute node goes through an interrupt node. When execution reaches that node, the graph pauses indefinitely — not for a timeout, not until the next turn, but until an external caller resumes it with human input. The state at the pause point is checkpointed, so the resuming caller gets the full context.

Here is why this is the cleanest HITL in the roster. The model cannot route around the approval because the model does not control the edges. The graph definition controls the edges. A prompt injection that says "skip the approval" has no effect, because the injection controls the model's reasoning and output, but the edge from propose to execute still goes through the interrupt node. The approval is a node in the graph topology, not a request in the prompt.

Module 6.2's HITL patterns — approve, edit, reject, resume — all map onto interrupt plus a conditional edge on the resume. Human approves, continue. Human edits, update state, continue. Human rejects, route to a recovery node. The graph makes these first-class control-flow constructs rather than prompts.

[SLIDE 5 — Super-step checkpoints: Module 8's reference, 5/5]

Let me go deeper on why LangGraph is the Module 8 reference. The granularity of checkpointing is what matters, and LangGraph's granularity is the step.

Look at the table. Most harnesses checkpoint at the session level. OpenCode, DD-03, is the example. If the process dies mid-session, you resume the session — but the granularity is the session, not the step. You resume from approximately where you were, not from exactly where you were.

Some harnesses checkpoint at the turn level — the last turn boundary. Better, but still coarse.

LangGraph checkpoints at the super-step level — the last completed node. Every node boundary is a checkpoint. Every checkpoint is serializable. Every run can be replayed from any checkpoint, forked at any checkpoint, or inspected at any checkpoint.

For long-running, multi-day, multi-human workflows, this is the difference between "resume from where you were" and "resume from approximately where you were." If you have a compliance pipeline that runs for three days across five human approvers, and the process crashes on day two, you want to resume from the exact node that crashed, not from the start of day two's session. That is what super-step checkpointing gives you. This is why LangGraph is the Module 8 reference at 5 out of 5.

[SLIDE 6 — When the graph is right vs wrong]

Now the central judgment call, and LangGraph makes it starker than any other framework because the graph is non-optional overhead. You cannot use LangGraph without declaring the graph. So the question is: when is the graph right, and when is it wrong?

The graph is right when the process is the product. Regulated workflows where every step must be auditable. Compliance pipelines where an auditor traces the path. Multi-approval flows where different humans approve different stages. Declared multi-agent systems where you want explicit edges between subagents. In all of these cases, the graph is not overhead — it is the deliverable. The structure of the workflow is the value, and the model is a participant in that structure.

The graph is wrong when the model could handle it. Open-ended coding tasks. Exploratory research. Creative work. Anything where the model's job is to figure out the process as it goes. In these cases, a rigid graph fights the model. This is Module 1's anti-pattern. The model could handle a transition naturally — it could decide, based on the task, whether to verify or to proceed — but the graph forces a specific path. The harness constrains capability. And this is the future-proof test partially failing: rigid graphs do not co-evolve with model upgrades. As the model gets smarter, the graph does not get more flexible. The model outgrows the graph.

The decision rule is simple. If you can draw the workflow as a flowchart before you run it, use a graph. If the workflow is "the model figures it out," use a loop. Pi, DD-01, for the minimal loop. An implicit-graph harness like Claude Code for the sophisticated-but-flexible case.

[SLIDE 7 — Multi-agent: subgraphs and the C4 E09 connection]

Let me talk about multi-agent orchestration, because this is where LangGraph connects to Course 4. LangGraph's Module 10 score — subagents — is 3 out of 5. Modest. But the pattern is distinctive: subgraphs.

A subgraph is a reusable sub-agent. It is a named graph that you can embed as a single node inside a larger graph. So a multi-agent system in LangGraph is a graph of subgraphs. Each subagent is a node. The edges between subagents are declared transitions — not emergent model-driven handoffs.

On the left you have LangGraph's declared coordination. Subagent A's output node connects to subagent B's input node. The conditional edge between them names the routing logic in code. The multi-agent system is auditable for the same reason the single-agent graph is auditable — every transition is visible.

On the right you have CrewAI's emergent coordination — and we will cover CrewAI in DD-12. In CrewAI, agents hand off to each other based on the model's judgment of who should go next. This is flexible, but it is opaque. The handoff is emergent, not declared.

This is the connection to Course 4, Module E09 — Multi-Agent Orchestration. E09 studies the axis between declared coordination and emergent coordination. LangGraph is the declared-coordination pole. CrewAI is the emergent-coordination pole. The trade-off is the same as the single-agent case: declared edges are auditable and testable but rigid; emergent handoffs are flexible but opaque. I want you to read this deep-dive alongside DD-12, CrewAI. The contrast between LangGraph and CrewAI defines the multi-agent axis the same way the contrast between NemoClaw and Tau defines the governance axis in Course 2B.

[SLIDE 8 — The score profile: 37/60, orchestration-substrate shape]

Let us score it. LangGraph is 37 out of 60. Look at the shape.

It maxes on the two orchestration axes. Module 1, Loop, is 5 out of 5 — the graph IS the loop, made explicit. Module 8, State, is 5 out of 5 — super-step checkpoints, the finest granularity in the roster. These are the two axes where being a graph is the advantage, and LangGraph is the reference on both.

Module 6, Permission, is 4 out of 5 — interrupt as structural HITL, the cleanest in the roster. Module 11, Observability, is 4 out of 5 — the graph trace is the audit trail; every path is visible in code.

Then look at where it loses. Module 2, Tools, is 3 out of 5 — LangGraph is a framework, not a tool-rich harness. You bring the tools. Module 4, Memory, is 3 out of 5 — checkpointer-based, persistent across runs, but not the depth play. Module 10, Subagents, is 3 out of 5 — subgraphs, which are a good pattern but not as rich as a dedicated multi-agent framework.

And Module 5, Sandbox, is 2 out of 5 — the framework leaves isolation to the user. This is the gap you would pair with DD-11, the OpenAI Agents SDK, which has the seven-provider sandbox abstraction. If you are building on LangGraph and your graph executes side-effecting tools, you must add isolation yourself.

Read the score as a profile. LangGraph is an orchestration substrate, not a finished harness. It maxes on the axes where being a declared graph is the advantage, and it is below median on the axes where you need a substrate — tools, memory, sandbox. You build the harness around the graph. The graph is the foundation; you bring the rest.

[SLIDE 9 — Anti-patterns]

Three anti-patterns to avoid.

First, using a graph for work the model could figure out. If the model could determine the workflow as it goes, a rigid graph constrains it. The graph forces a specific path the model must follow even when a different path would be better. The cure is to match the framework to the use case. Process-is-product, yes. Figure-it-out, no. Use Pi or an implicit-graph harness instead.

Second, implementing HITL as a system-prompt instruction instead of a graph node. We covered this, but it bears repeating because it is the most common mistake. A system-prompt instruction is behavioral. The model can forget, defer, or be injected into skipping the ask. The cure is to implement HITL as a graph topology. The edge goes through an interrupt node. The model cannot route around what it does not control. This is LangGraph's structural HITL advantage, and it is the same principle as NemoClaw's governance-beneath-the-agent.

Third, treating the graph as immutable. This is a subtle one. A common error is to design the graph once and treat it as fixed. The graph works, so you do not touch it. But as requirements change, the graph must evolve. New nodes, new edges, new conditional routing. Rigid graphs that never evolve fight both the model and the changing requirements. The cure is to treat the graph as a living artifact. Version it. Refactor it. Add nodes when the process grows. The graph is editable — that is one of its core advantages. Do not throw that advantage away by freezing the graph the day you ship it.

[SLIDE 10 — What you can now do]

Let me close with what you can now do.

You can state LangGraph's thesis — the loop is an explicit, editable, testable graph — and explain why this is the largest architectural divergence in the roster. Every other harness hides its loop; LangGraph makes the loop the product.

You can distinguish the three primitives — nodes as functions, edges as transitions, super-step checkpoints as serialized state at every node boundary — and explain why each earns its 5 out of 5. Module 1, Loop, because the graph IS the loop. Module 8, State, because super-steps are the finest granularity in the roster.

You can explain why interrupt is the cleanest HITL primitive in the roster. It is structural, not behavioral. A prompt-injected model cannot route around the approval because the approval is a node in the graph topology, not a request in the prompt. Same principle as NemoClaw — enforcement outside the agent's reach.

You can apply the decision rule for when the graph is right versus wrong. Process-is-product, yes. Model-figures-it-out, no. And you can name the graph-fights-the-model anti-pattern and explain why it is the future-proof test partially failing.

And you can connect LangGraph's subgraph pattern to multi-agent orchestration — Module 10 — and to Course 4's E09 module, where LangGraph and CrewAI are the two poles of the declared-versus-emergent coordination axis.

The lab: you build a LangGraph-style state machine in pure Python. Nodes as functions. Edges as a transition table. State serialized at every node boundary. You add an interrupt node and confirm that a prompt-injected model cannot route around it — the structural HITL property, made empirical. Then you add a subgraph and confirm multi-agent coordination via explicit edges.

Next up: DD-11, the OpenAI Agents SDK — the framework you would pair with LangGraph for sandboxing, since LangGraph leaves Module 5 to you. The seven-provider sandbox abstraction. See you there.