In LangGraph, what steps build a minimal StateGraph from schema to invoke?

## The shape of the API LangGraph splits building from running. `StateGraph` is a mutable *builder*: you add nodes and edges to it in any order. `compile()` freezes that builder into a `CompiledStateGraph`, which is the thing you actually execute. Keeping the two apart lets LangGraph validate the topology once, at compile time, instead of discovering a dangling edge halfway through a run. ## Step 1 — the state schema Every graph is built around one shared, typed state object. The usual spelling is a `TypedDict`: The schema does three jobs. It documents what flows between nodes; it tells LangGraph which *channels* to create (one per key); and it lets your editor and type checker catch typos in `state["topic"]`. A dataclass or a Pydantic `BaseModel` works too — the choice changes validation behaviour, not the graph mechanics. ## Step 2 — nodes `builder.add_node("plan", plan_fn)` registers a callable under a name. The name is the identifier used by edges, by streamed update events and by the drawn diagram, so pick something readable. The callable receives the current state and returns a **partial** update — a dict of just the keys it changed. If you pass only the function, `add_node(plan_fn)` uses the function's `__name__` as the node name. A node can be a plain function, an async function, or any LangChain runnable. Nothing about a node is special-cased for LLMs: calling a model is just what most node bodies happen to do. ## Step 3 — edges, START and END Edges declare order. `add_edge(START, "plan")` marks `plan` as an entry point — `START` is a sentinel constant meaning "the virtual node that runs before everything". `add_edge("plan", END)` marks a terminal point. Both are imported from `langgraph.graph`; you never register them with `add_node`. A graph with no edge from `START` fails at compile time, because there is nothing to run first. An edge added with `add_edge` is *unconditional*: when the source finishes, the target is scheduled. Edges whose target depends on the state are a separate construct. ## Step 4 — compile `graph = builder.compile()` returns the runnable. Compilation checks the graph: every node must be reachable, edge endpoints must name registered nodes, and an entry point must exist. `compile()` is also where run-wide options are attached — a checkpointer, interrupt points, a run name. Calling it twice on the same builder is legal and gives you two independent compiled graphs. A compiled graph also exposes `get_graph().draw_mermaid()`, which is the fastest way to see whether the topology you wired is the one you meant. ## Step 5 — invoke `graph.invoke({"topic": "reducers"})` seeds the state channels from the dict you pass and runs the graph. Execution proceeds in *supersteps*: LangGraph runs the scheduled nodes, applies their returned updates to the state, then schedules whatever their outgoing edges point at, and repeats until nothing is left to run. `invoke` returns the final state as a dict. `stream()` returns the same run as an iterator of intermediate results, and `ainvoke`/`astream` are the async forms. Because the compiled graph implements the same runnable interface as other LangChain-ecosystem components, a graph can be composed into a larger pipeline, or another graph, without adapters. ## Where beginners trip The most common error is treating the node's return value as the whole new state — it is a *partial* update merged into what already exists. The second is forgetting `compile()` and calling `invoke` on the builder, which does not have it. The third is adding `START` or `END` with `add_node`. The fourth is defining a node that reads a key the schema never declared: with a `TypedDict` schema, that key simply isn't a channel, and the read raises a `KeyError` at runtime rather than being caught by the type checker.