Building real apps: LangChain & LangGraph

1 Why use a framework at all?

In Session 3 you called a model's API "by hand": you built a request, sent it, read the reply, and wrote your own loop to handle tool calls. That works! But as your app grows, you keep writing the same plumbing over and over. A framework is a library that packages those repeated patterns into reusable parts. LangChain is the most popular framework for building apps on top of LLMs.

The pain a framework removes

2 LangChain's core building blocks

LangChain is made of a few small, reusable parts. Once you know these four, almost everything else is just combinations of them.

A — Prompt templates

A prompt template is a fill-in-the-blanks version of a prompt. Instead of gluing strings together by hand, you write the prompt once with {placeholders} and fill them in later. This connects straight to the prompt-engineering ideas from Session 2 — your carefully crafted prompt becomes a reusable, versionable template.

from langchain_core.prompts import ChatPromptTemplate

# A reusable recipe with one blank: {topic}
prompt = ChatPromptTemplate.from_template(
    "Explain {topic} to a complete beginner in 2 sentences."
)

# Fill the blank in later, as many times as you like
prompt.invoke({"topic": "embeddings"})

B — Models / LLMs

The model (or "chat model") is the object that actually talks to the LLM. LangChain wraps each provider behind a common interface, so they all share the same .invoke() method. This is the model-swapping superpower from Topic 1.

from langchain_anthropic import ChatAnthropic

model = ChatAnthropic(model="claude-sonnet-4-5")

# Swapping providers is a one-line change — the rest of your code is identical:
# from langchain_openai import ChatOpenAI
# model = ChatOpenAI(model="gpt-4o")

model.invoke("Say hello in one word.")

C — Output parsers

A model returns a message object, but you usually want something cleaner — just the text, or a Python dictionary, or a validated structure. An output parser takes the raw model output and converts it into the shape your code wants, and can complain if the shape is wrong.

from langchain_core.output_parsers import StrOutputParser

parser = StrOutputParser()   # pulls the plain text string out of the model's reply

There are fancier parsers too — e.g. one that forces the output into a typed object so you reliably get {"name": ..., "age": ...} instead of a paragraph you'd have to scrape.

D — Runnables (the secret that ties it all together)

Here's the clever bit. Prompt templates, models, and parsers all follow one shared contract called the Runnable interface. A runnable is simply "any LangChain piece you can call with .invoke(input) and get an output." Because every piece speaks this same language, they all snap together like LEGO bricks — which is exactly what makes the next topic possible.

prompt_value = prompt.invoke({"topic": "tokens"})  # fill the template
message      = model.invoke(prompt_value)              # ask the model
text         = parser.invoke(message)                  # extract clean text
print(text)

3 Chains & LCEL — composing with the pipe |

A chain is several runnables joined into a pipeline so the output of one becomes the input of the next. LangChain lets you build chains with a wonderfully simple syntax called LCEL (LangChain Expression Language), using the pipe operator | — the same symbol you may know from the Unix command line, where cat file | grep x pipes one program's output into the next.

Building a chain

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_anthropic import ChatAnthropic

prompt = ChatPromptTemplate.from_template(
    "Explain {topic} to a beginner in 2 sentences."
)
model  = ChatAnthropic(model="claude-sonnet-4-5")
parser = StrOutputParser()

# Join them with | — read it left to right like a sentence:
# "fill the prompt, then run the model, then parse the output"
chain = prompt | model | parser

# Now the whole pipeline is itself ONE runnable you call once:
chain.invoke({"topic": "attention"})
# -> "Attention lets a model weigh which words matter most..."

Compare this to the manual version at the end of Topic 2 — same result, but the plumbing vanished. And because a chain is itself a runnable, you can pipe a chain into another chain, building bigger pipelines out of smaller ones.

summarise = summary_prompt | model | parser
tweetify  = tweet_prompt   | model | parser

pipeline = summarise | tweetify     # the summary flows into the tweet step
pipeline.invoke({"text": long_article})

4 Tool calling in LangChain

Back in Session 3 you met tools: functions the model can ask to run when it can't (or shouldn't) answer from memory alone — like looking up live data, doing exact math, or calling another system. LangChain makes wiring tools to a model very tidy.

Step 1 — Define a tool

A tool is just a normal Python function plus a clear description, so the model knows what it does and when to use it. The @tool decorator turns a function into a LangChain tool. Note how important the docstring is — that text is what the model reads to decide whether to call it (a direct echo of the "describe your tools clearly" lesson from Session 3).

from langchain_core.tools import tool

@tool
def get_weather(city: str) -> str:
    """Get the current weather for a given city."""
    # In real life this would call a weather API.
    return f"It is 22C and sunny in {city}."

Step 2 — Bind the tool to the model

Binding means "tell the model these tools exist." After binding, the model can choose to request a tool call in its reply instead of answering directly.

model_with_tools = model.bind_tools([get_weather])

response = model_with_tools.invoke("What's the weather in Paris?")

# The model doesn't run the function itself. It REQUESTS it:
print(response.tool_calls)
# -> [{'name': 'get_weather', 'args': {'city': 'Paris'}, 'id': '...'}]

from langchain_core.messages import HumanMessage

messages = [HumanMessage("What's the weather in Paris?")]
ai_msg   = model_with_tools.invoke(messages)
messages.append(ai_msg)                          # the model's tool request

# Run each tool the model asked for, and feed results back:
for call in ai_msg.tool_calls:
    result = get_weather.invoke(call["args"])
    messages.append(get_weather.invoke(call))    # a ToolMessage with the result

final = model_with_tools.invoke(messages)        # now it can answer for real
print(final.content)   # -> "It's currently 22C and sunny in Paris."

5 LangGraph — modelling agents as graphs

Chains (Topic 3) are linear: A → B → C, always in that order, always once. But agents need to loop (try again), branch (decide what to do next), and remember. For that, LangChain has a sibling library: LangGraph. It models your app as a graph — a set of steps connected by arrows that can point anywhere, including backwards.

The three pieces of a graph

What "state" really means

The state is the heart of a LangGraph app. It's a single object (often a dictionary or a typed structure) that holds everything the agent knows right now: the conversation so far, any retrieved documents (Sessions 4 & 5), intermediate results, counters, flags. Each node receives the current state and returns an update, which LangGraph merges back in. Remember from Session 1 that the model itself is stateless — the graph's state object is how we give the app a memory.

from typing import Annotated
from typing_extensions import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages

# The shared notepad: here it just holds a growing list of messages.
class State(TypedDict):
    messages: Annotated[list, add_messages]   # new messages get appended

def chatbot(state: State):
    # a node: read state, call the model, return an update
    return {"messages": [model.invoke(state["messages"])]}

graph = StateGraph(State)
graph.add_node("chatbot", chatbot)   # add a square
graph.add_edge(START, "chatbot")     # start here
graph.add_edge("chatbot", END)       # then finish

app = graph.compile()
app.invoke({"messages": [("user", "Hi!")]})

6 Conditional branching & routing

The first real superpower of graphs is the conditional edge (also called routing). Instead of always going to a fixed next node, a conditional edge runs a little function that looks at the current state and returns the name of the node to visit next.

How it works

You write a plain Python function — the router — that reads the state and returns a string. LangGraph then jumps to whichever node matches that string. This is where the agent's "decisions" live.

from langgraph.graph import StateGraph, START, END

def route(state: State) -> str:
    # Look at the latest model message and decide where to go.
    last = state["messages"][-1]
    if last.tool_calls:            # model asked to search the docs
        return "retrieve"
    return "answer"             # it can answer directly

graph.add_conditional_edges(
    "model",          # from this node...
    route,            # ...run this function to pick the next node...
    {"retrieve": "retrieve", "answer": "answer"},  # map result -> node
)

7 Multi-step reasoning & cycles

The second superpower of graphs is the cycle — an edge that points back to an earlier node, creating a loop. This is impossible in a linear chain, and it's exactly what turns a one-shot model call into a real, multi-step agent (Session 3).

The ReAct loop, in a graph

The classic agent pattern from Session 3 is ReAct (Reason + Act): the model reasons about what to do, acts by calling a tool, sees the result, and reasons again — over and over until it has enough to answer. In LangGraph that's just two nodes with a loop between them.

def should_continue(state: State) -> str:
    # If the model asked for a tool, run it; otherwise we're done.
    if state["messages"][-1].tool_calls:
        return "tools"
    return END

graph.add_node("model", call_model)
graph.add_node("tools", run_tools)

graph.add_edge(START, "model")
graph.add_conditional_edges("model", should_continue)
graph.add_edge("tools", "model")   # THE LOOP: after a tool, go back to the model

app = graph.compile()

8 Agent persistence & checkpointing

Remember the most important fact from Session 1: the model is stateless — it has no memory between requests. The graph's state (Topic 5) gives memory during a single run, but once the run ends, that state vanishes. Persistence (saving) and checkpointing fix this by saving the state so it survives across turns, sessions, even restarts.

How checkpointing works

You attach a checkpointer when you compile the graph. After every node, LangGraph automatically saves a snapshot of the state — a checkpoint. Each conversation gets a thread_id (think: a save-slot name). When you run the graph again with the same thread_id, it loads the saved state and continues from there.

from langgraph.checkpoint.memory import MemorySaver

checkpointer = MemorySaver()                 # a simple in-memory save store
app = graph.compile(checkpointer=checkpointer)

# A "save slot" name for this conversation:
config = {"configurable": {"thread_id": "user-42"}}

app.invoke({"messages": [("user", "My name is Medha.")]}, config)
# ...later, even after a restart, same thread_id:
app.invoke({"messages": [("user", "What's my name?")]}, config)
# -> "Your name is Medha."  (it loaded the earlier state!)

★ Putting it all together

You just went from "calling the API by hand" to "building looping, branching, remembering agents." Here's the one-paragraph story that connects all 8 topics:

Quick self-check

📚 References & Further Reading

Class material

• 📄 Original course notes / handout (source sheet) — open the shared GenAI class material for this session.
• Class handout: "LangChain Fundamentals & LangGraph".

Papers, docs & deep dives

• 📘 LangChain documentation — Introduction — the framework, core building blocks, and getting started.
• 📘 LCEL (LangChain Expression Language) — the pipe operator and composing runnables (Topic 3).
• 📘 LangGraph documentation — state, nodes, edges, routing, cycles, and checkpointing (Topics 5–8).