Loading
Every source below was opened and read while the lessons citing it were written, on the date given. That matters more here than in the other courses on this site: the APIs described moved twice in the year before module one shipped, and several pages that rank well in search are generated reference snapshots that are no longer accurate. Where a page and your installed package disagree, the package wins.
The four pages module one is built on. All four are LangChain documenting its own framework.
WhyThe decomposition argument: a process becomes nodes, and state is “the shared memory accessible to all nodes… the notebook your agent uses to keep track of everything it learns and decides.” Primary source for the not-a-chain-of-calls lesson. Read for the mechanism; the “why you want this” framing is a vendor’s.
WhyThe load-bearing page for two lessons. Source of the superstep definition (“a single iteration over the graph nodes. Nodes that run in parallel are part of the same super-step”), the “nodes do the work, edges tell what to do next” framing, the default-overwrite reducer rule, and the current StateSchema / ReducedValue / MessagesValue / UntrackedValue sample. Also carries the per-node retry, cache, timeout and error-handler options the lessons only name in passing. Reused rather than re-cited by the not-being-dogmatic module’s reading-an-unfamiliar-stack lesson, which nominates it as the page to have open during that lesson’s four-step reading pass: three of the four questions the pass asks — state, routing, and the control-flow returns a node can make — are defined here. The pass itself appears in no source; it is this course’s own method.
WhyThe “Alternative state definitions” comparison table, which is the thing to actually read: it marks StateSchema as recommended and labels Annotation.Root, Zod v3 with .langgraph and the Zod v4 registry approach as Legacy, with the raw Channels API kept for advanced cases. Most LangGraph code you inherit will be written in one of the legacy styles, so the table is a translation key, not trivia. Primary source for the state-is-the-contract lesson.
WhyThe six JavaScript stream modes with their verbatim descriptions, the updates and messages chunk shapes, the [mode, chunk] tuple form for multiple modes, the subgraphs: true namespacing, and config.writer for custom data. Note the mode list differs between the JavaScript and Python variants of this page. Primary source for the stream-modes lesson.
WhyIncluded as a worked example of the problem, not as a source to use. This page is still live and publishes a different StreamMode union than the current documentation — it carries modes the current JS page does not list and omits one it does. Cited in the stream-modes lesson as the reason to check the installed package rather than the first search result.
One LangChain doc page carries three of this module’s four lessons, so it appears once here and is read three different ways. Every source in this group is LangChain documenting its own framework and selling the hosted platform those docs lead to; the comparison between an app-level review gate and a graph-level interrupt is this course’s own argument, not a claim from any of them.
WhyThe load-bearing page for this module, cited by three of its four lessons. Source of the two prerequisites (a checkpointer to persist state, a thread ID so the runtime knows which state to resume from), the __interrupt__ array of { id, value }, new Command({ resume }) as the only Command pattern intended as input to invoke or stream, the tool-review example and its resume-value-overrides-inputs line, and the rule the whole module turns on: “the runtime restarts the entire node from the beginning… any code that ran before the interrupt will execute again,” with three mitigations. Also repositions the older static interruptBefore / interruptAfter options as a debugging tool rather than the recommended way to do human-in-the-loop, which is what most 2025-era tutorials teach. Primary source for the interrupt-and-resume, decision-surface and mid-tool-call lessons.
WhyCited for one thing only: the signature interrupt<I = unknown, R = any>(value: I): R, and the description of both behaviours — it throws a GraphInterrupt carrying the value when no resume value is available, and returns the resume value once the graph is re-invoked with a Command. That untyped signature is what the decision-surface lesson leans on when it says the approve / edit / reject contract is yours to define and validate. This site publishes stale unions elsewhere and the current reference returns a not-found for this symbol, so treat the rest of it as out of date.
Three LangChain pages carry this whole module. All three are LangChain documenting the framework it wrote, and the docs lead to the hosted platform the same company sells — read the mechanics as authoritative and the framing as a vendor’s.
WhyPrimary source for two lessons in this module, and cited by two more besides. The definitions: a checkpoint is “a snapshot of the graph state saved at each super-step and is represented by a StateSnapshot object”; a thread is “a unique ID or thread identifier assigned to each checkpoint saved by a checkpointer. It contains the accumulated state of a sequence of runs.” Carries the full StateSnapshot field list — values, next, config, metadata, createdAt, parentConfig, tasks — the documented idiom for detecting a thread parked on a human via tasks[].interrupts, and the checkpointer packages (in-memory bundled; SQLite, Postgres, MongoDB and Redis as separate installs). Cited by checkpointers-and-threads for the field list, and by state-you-can-show for the one line that defines values as the state channel values at that checkpoint. Also cited by the interrupts module’s why-an-app-gate-cannot-resume lesson, for the same checkpoint and thread definitions — the naming that converts “I designed a review step” into “I wired a review step into an execution graph.” Field names are camelCase here where Python’s are snake_case, which is what the not-being-dogmatic module’s typescript-side-of-the-wire lesson cites this same page for. Read it also for what it does not contain: no filtering, redaction or browser-safe projection is documented anywhere on it.
WhyThin on its own, and it points at the checkpointers guide for the detail. Worth reading for one sentence — checkpointers are for “short-term, thread-scoped memory, including conversation continuity, human-in-the-loop workflows, time travel, and fault tolerance” — and for a silence: nothing on the page describes how a person comes back to a paused run. No notification, no inbox, no resume surface. That absence is the subject of the resuming-a-run-they-walked-away-from lesson. It also carries no Postgres or SQLite setup code, so take a constructor from the package you have installed rather than from any page. The interrupts module’s why-an-app-gate-cannot-resume lesson cites the same one-sentence quote as its primary source, for the argument that a resume surface built for a human pause is most of what crash recovery needs too — one mechanism, four uses.
WhyPrimary source for the time-travel-and-forking lesson, and the page that corrects the way replay is usually described. Replay is invoke(null, pastSnapshot.config), and the page is explicit that it is not a cache read: “Replay re-executes nodes—it doesn’t just read from cache. LLM calls, API requests, and interrupts fire again and may return different results.” Only the history before the target checkpoint is a pure read. Forking goes through updateState(pastSnapshot.config, values, { asNode }), which “does not roll back a thread. It creates a new checkpoint that branches from the specified point. The original execution history remains intact,” and returns the fork’s config. Also documents locating a checkpoint by its next array rather than hand-assembling a config, and the detail that interrupts are re-triggered during time travel. The interrupts module’s interrupting-a-tool-call lesson also cites this page, for that same re-execution line: it is the reason a model call sitting above an interrupt is dangerous even when no write is — the artefact a human approved is not necessarily the artefact that runs on replay.
The pages module four is built on, plus the one lesson that has no source because its method is this course’s own. Everything LangChain-published here documents a product LangChain sells; the MCP specification is normative text originated by Anthropic. No vendor comparison page is cited in either direction, deliberately.
WhyThe package boundary that moved: createReactAgent is deprecated in favour of createAgent, which lives in the langchain package rather than @langchain/langgraph. Primary source for the typescript-side-of-the-wire lesson, and the most likely thing to be copied wrong out of a 2025-era tutorial.
WhyThe line that stops you rewriting an inherited repo on sight: the existing Annotation and zod-based state API “continues to work unchanged.” Legacy is not removed. Cited in the typescript-side-of-the-wire lesson.
WhyThe tiebreaker when a page and the installed package disagree. As fetched: version 1.4.14, @langchain/core a required peer at ^1.1.48 rather than bundled, and engines.node declared >=18. That last field is the one to check yourself rather than take from a search snippet. Cited in the typescript-side-of-the-wire lesson.
WhyThe full run schema: inputs, outputs, start_time, end_time, run_type, error, status, tags, plus token and cost fields. Two corrections worth the visit on their own: there is no top-level metadata field (metadata is stored inside extra) and latency is not stored (derivable from the timestamps; first_token_time is a different, narrower measurement). Also the dotted_order / trace_id pair that turns a flat run list back into a tree. Primary source for the traces lesson.
WhyDefinitions of run (“a single unit of work executed by an agent, such as calling an LLM, formatting a prompt, or retrieving documents”) and trace (“a collection of runs for a single operation”), plus the sentence that makes the whole vocabulary portable to a stack that does not use LangSmith: a run can be thought of as a span. Cited in the traces lesson, which uses the schema and not the framing around it.
WhyThe rare case of a UI requirement written into a protocol specification: “there SHOULD always be a human in the loop with the ability to deny tool invocations,” plus three application-level SHOULDs (disclose which tools are exposed, indicate visually when one is invoked, present confirmation prompts). Also the Tool data type, the requirement that clients MUST treat tool annotations as untrusted unless the server is trusted, and the resultType / input_required flow in which a server embeds an elicitation/create request and the client retries with inputResponses and an opaque requestState token. Primary source for the mcp-as-the-tool-boundary lesson.
WhyTwo things 2025-era material gets wrong about MCP, both cited in the tool-boundary lesson: the protocol is stateless (no initialize handshake; capabilities travel as per-request metadata) and sampling and roots are deprecated as of this revision, which leaves elicitation as the client primitive — and therefore as the mechanism behind the input-required tool flow.
Agent frameworks move fast, and most of the documentation here is written by the vendor that sells the framework. Every claim on these pages links to the page it came from, with a date — if a source has moved on, check the resource list and tell your teaching agent. The API is expected to drift; the primitives are what the course is actually teaching.