TopolearnKnowing what LangGraph adds tells you when to use it instead of a prebuilt agent or plain code.
You know an agent is a model in a loop that calls tools until it reaches a goal. A simple loop is fine for demos. Real applications soon need more: fixed steps mixed with model decisions, pausing for a human to approve, resuming after a crash, remembering a conversation tomorrow, showing progress live.
LangGraph lets you draw your application as a graph: a set of boxes (steps) joined by arrows (what runs next). Think of a flowchart for handling a support email: read it, classify it, then either draft a reply or escalate to a person.
- Each box is a node: an ordinary Python function.
- Each arrow is an edge: it says which node runs next, possibly decided at run time.
- All nodes read and update one shared state: a dictionary-like object holding everything the run knows so far.
LangGraph is deliberately low-level. It doesn't hide prompts or impose an agent design. What it adds is a runtime (the engine that executes your graph) with production features: saving state after every step (persistence), streaming, interrupts for human input, memory, and recovery from failures.
It is part of the LangChain family but does not require LangChain. In practice many people use LangChain's model and tool classes inside LangGraph nodes, and LangChain's own create_agent is built on LangGraph. Rule of thumb: start with create_agent for a standard tool-calling agent; drop to LangGraph when you need a custom flow.
This curriculum covers LangGraph 1.x (1.2 as of October 2026). Version 1.0 kept the core graph API stable, so most 1.0 code still runs.
Remember
- A LangGraph app is a graph: nodes (functions), edges (what runs next), shared state
- It is low-level orchestration plus a runtime: persistence, streaming, interrupts, memory
- Works without LangChain, but pairs naturally with it
- Use create_agent for standard agents, LangGraph for custom control