The Graph Mental Model
state that flows through nodes

Imagine you wired up an LLM the obvious way: one function takes a question, calls the model, returns the answer. That works until the moment the task needs more than one step. The model wants to search the web, read the result, decide it needs to search again, and only then answer. Suddenly your one straight line of code has to loop, branch, remember what it already found, and sometimes pause for a human to approve something. Stuff a few if statements and while loops around the model call and within a week you have a tangle nobody can follow.

LangGraph exists to give that tangle a shape. Instead of control flow buried inside one giant function, you describe your agent as a graph: small steps (nodes) connected by arrows (edges), all reading and writing to one shared piece of data (state). The framework then runs the graph for you, step by step, and it can save progress, resume after a crash, stream partial output, and stop to ask a human, all because the work is broken into named, inspectable pieces.

If you have used LangChain before, here is the honest framing: LangChain gives you the building blocks (models, tools, prompts). LangGraph gives you the orchestration, the part that decides what runs next and carries state between steps. You can use LangGraph completely on its own; it does not require the rest of LangChain.

One character, one project, carried through all four modules. Sahil wants to build a research assistant: you give it a question, it thinks, it looks things up, and it writes you a short answer. By Module 04 this becomes a small team of cooperating agents. Right now, in Module 01, it is the simplest possible version: a question goes in, the model answers, done.

Sahil's first instinct is a single function. It is worth writing the naive version once, because seeing its limits is the whole reason the graph idea will feel necessary rather than ceremonial.

# Sahil's first attempt. Fine for one shot, painful the moment it needs to loop.
def answer(question):
    reply = llm.invoke(question)     # one model call
    return reply.content

# Now try to add: "if the model asks to search, search, then call it again".
# You start nesting if/while around the call. State lives in scattered local
# variables. There is no way to pause, save, or replay. This is the wall.

Hold one picture in your head and most of LangGraph follows from it. An agent is a graph made of three things:

The runtime walks the graph: it starts at a special START marker, runs whatever node the edges point to, applies that node's update to the state, looks at the edges again to find the next node, and repeats until it reaches the special END marker. That walk is the entire execution model. Everything else in this whole track is a richer version of these three pieces.

Before you can build a graph you have to answer one question: what does this agent need to remember while it runs? That answer is your state schema. In Python you usually declare it as a TypedDict, which is just a dictionary with named, typed fields. It is a contract: these are the slots on the whiteboard.

from typing_extensions import TypedDict

# The schema is just "what fields exist and what type each is".
class ResearchState(TypedDict):
    question: str          # what the user asked
    answer: str            # what we will fill in
    # Module 02 will add findings, message history, and more.

When the graph runs, the state starts as whatever you pass in, and each node returns a small dictionary saying which fields to change. You never mutate the state object directly. You return an update, and the runtime merges it. That return-an-update rule is what lets LangGraph snapshot every step later, which is the entire basis of persistence and time travel in Module 02.

A node is the least mysterious thing in the framework: it is a plain function. It takes the current state and returns a dict of updates. That is the whole interface. If you can write a function that reads a value and returns a new one, you can write a node.

def research_node(state: ResearchState) -> dict:
    # read from state ...
    q = state["question"]
    reply = llm.invoke(q)            # ... do the work ...
    return {"answer": reply.content}  # ... return ONLY what changed

Edges are the wiring between nodes. There are two kinds, and the difference matters for the rest of the track:

Two special markers bookend every graph. START is where execution begins; you draw an edge from it to your first node. END is the exit; when an edge leads there, the run finishes and you get the final state back.

Now the four moves you will repeat for the rest of your LangGraph life. Read them as a recipe: create the builder, add nodes, add edges, compile. Sahil's one-node agent is the smallest thing that exercises all four.

from langgraph.graph import StateGraph, START, END

builder = StateGraph(ResearchState)        # 1 · builder over the schema

builder.add_node("research", research_node)  # 2 · register the step

builder.add_edge(START, "research")         # 3 · where to begin
builder.add_edge("research", END)           #     where to stop

graph = builder.compile()                  # 4 · freeze into a runnable

# Run it: pass the initial state, get the final state back.
final = graph.invoke({"question": "What is LangGraph?"})
print(final["answer"])

That is a complete, working LangGraph application. One node, two edges. It is intentionally trivial, because the point of Module 01 is the shape, not the size. Notice the symmetry of invoke: you hand the graph an initial state dict and it hands you the final state dict. Same in, same out.

A straight line of nodes is just a pipeline. What makes something feel like an agent is the ability to look at the current state and decide what to do next, including doing the same step again. That decision lives in a conditional edge: you give it a small router function that reads state and returns the name of the next node.

def should_continue(state) -> str:
    # Look at state, decide. Return a node name or END.
    if state["needs_more_research"]:
        return "research"   # loop back, run research again
    return END               # good enough, finish

builder.add_conditional_edges("research", should_continue, ["research", END])
# the list is just the set of possible destinations, for validation

Read what that buys you: the research node can now point back at itself. The runtime keeps walking the loop until the router returns END. This is exactly how the classic agent loop works, think, act, look at the result, think again, and you built it from nothing but a function that returns a string.

Almost every agent's state needs to hold a growing list of chat messages: the human's turn, the model's reply, tool results, and so on. This is so common that LangGraph ships a ready-made state schema for it called MessagesState. It has a single field, messages, and that field is special: when a node returns new messages, they are appended to the list rather than replacing it.

from langgraph.graph import StateGraph, START, MessagesState

def chat_node(state: MessagesState) -> dict:
    reply = llm.invoke(state["messages"])   # model sees full history
    return {"messages": [reply]}            # appended, not overwritten

builder = StateGraph(MessagesState)
builder.add_node("chat", chat_node)
builder.add_edge(START, "chat")
graph = builder.compile()

graph.invoke({"messages": [{"role": "user", "content": "hi"}]})

That append behaviour is not magic; it comes from a reducer attached to the messages field. A reducer is a small rule that says "when a node returns a value for this field, combine it with the old value like this". For messages the rule is "add to the list". You will define your own reducers in Module 02; for now just know that MessagesState is the batteries-included version, and reaching for it saves you boilerplate in most agents.

Do not move to Module 02 until you have actually run a graph. Set up a fresh environment, install the package, and build the loop with your own fingers. The skeleton below is deliberately incomplete in the places that matter, so you have to think.

# a clean venv keeps your machine sane
python -m venv .venv && source .venv/bin/activate
pip install langgraph langchain                # core + model helpers
# pick ONE model provider you have a key for, e.g. langchain-openai or langchain-anthropic

from langgraph.graph import StateGraph, START, END
from typing_extensions import TypedDict

class State(TypedDict):
    topic: str
    joke: str
    rounds: int

def tell_joke(state):
    # TODO 1: call your llm with state["topic"], return {"joke": ...,
    #         "rounds": state.get("rounds", 0) + 1}
    ...

def good_enough(state):
    # TODO 2: return END if rounds >= 3, else "tell_joke" (loop)
    ...

builder = StateGraph(State)
builder.add_node("tell_joke", tell_joke)
builder.add_edge(START, "tell_joke")
# TODO 3: add a conditional edge from "tell_joke" using good_enough

graph = builder.compile()
print(graph.invoke({"topic": "databases", "joke": "", "rounds": 0}))

• You created a StateGraph over a TypedDict and compiled it without errors.
• You ran graph.invoke(...) and got a final state dict back.
• Your conditional edge made the graph loop and then stop on its own.
• You can explain, out loud, what state / node / edge each mean in your own words.

A small taste here; the full bank lives in Module 05. Cover the answer, say yours out loud, then expand. = must-know cold.