LangGraph Beginner to Advanced: Part 1 — Introduction to LangGraph and Some Basic Concepts

Welcome to this LangGraph Beginner to Advanced series. LangGraph is one of the most popular frameworks for building agentic AI applications. With agentic AI, the application has a lot more scope and tasks to accomplish by navigating various flows and autonomously invoking various agents to fulfill a task completely. LangGraph is built within the LangChain system to act as an orchestration framework to build a multi-step flow for each task execution. Unlike a linear chain of events that you build with LangChain, with a multi-step flow, the orchestration can have logical conditions that decide which agent to invoke, it can make decisions, use various tools, and maintain the state of the conversation throughout the flow.

If you’ve ever wanted to build AI agents and design graph-based conversational workflows, this course-style blog series is for you.

LangGraph is a powerful Python library designed for building advanced conversational AI workflows. By the end of this series, you will be equipped to create robust, scalable conversational applications that leverage the full potential of large language models (LLMs).

Hey, my name is Talib, and I’m an AI engineer. In this series, we’re going to walk through LangGraph step by step — from fundamentals to coding real AI agents.

Before diving into the complex stuff, let’s get started with some basic concepts:

Prerequisites

Before continuing, you should have:

• Basic knowledge of Python
• Understanding of dictionaries, classes, and functions
• Familiarity with type annotations (optional but helpful)

Why Type Annotations?

When we eventually start coding AI agents and graphs in LangGraph, type annotations will appear everywhere. If you’ve never worked with them before, they might look confusing. That’s why we’ll go through them first.

Dictionaries in Python

movie = {
    "name": "Avengers Endgame",
    "year": 2019
}

Dictionaries are powerful and flexible. But there’s a problem that they don’t enforce structure. You could mistakenly pass wrong data types, and in large projects, this creates logical errors that are painful to debug.

Type Dictionaries

A type dictionary enforces structure. In Python, you can define this using a class:

from typing import TypedDict

class Movie(TypedDict):
    name: str
    year: int

movie: Movie = {
    "name": "Avengers Endgame",
    "year": 2019
}

Benefits:

• Type safety → fewer runtime errors
• Readability → easier debugging
• Scalability → used extensively in LangGraph to define states

Union

The Union type lets you define multiple acceptable data types.

from typing import Union

def square(x: Union[int, float]) -> float:
    return x * x

• square(5) → works
• square(1.23) → works
• square(“hello”) → fails

LangChain and LangGraph both use Union extensively.

Optional

The Optional type means a value can either be of a type OR None.

from typing import Optional

def nice_message(name: Optional[str]) -> str:
    if name:
        return f"Hi there {name}"
    else:
        return "Hey random person"

Works with “Bob”

•  Works with None
• Doesn’t allow integers or booleans

Any

The Any type allows literally anything.

from typing import Any

def print_value(x: Any):
    print(x)

print_value("Hello")
print_value(123)
print_value([1, 2, 3])

Lambda Functions

Lambda functions are small, anonymous functions.

Example 1: Squaring a Number

square = lambda x: x * x
print(square(10))  # 100

Example 2: Mapping Over a List

nums = [1, 2, 3, 4]
squared = list(map(lambda x: x * x, nums))
print(squared)  # [1, 4, 9, 16]

Advanced programmers often use lambdas + map() for efficiency instead of writing full loops.

These will keep showing up in LangGraph, so having a good grasp now will save you from confusion later.

Now, it’s time to dive deeper into the building blocks of LangGraph:

• States (memory)
• Nodes (tasks)
• Graphs & Edges (workflow connections)
• Start & End points
• Tools & Tool Nodes
• State Graph (blueprint)
• Runnables (building blocks)
• Messages (communication between humans, AI, and tools)

To make this easier to follow, let’s understand with a factory assembly line analogy.

Think of LangGraph as a smart, automated factory where:

• The state = the shared whiteboard of the factory (tracking progress)
• The nodes = workstations (each does one specific job)
• The edges = conveyor belts between stations (deciding flow)
• The tools = machines used at workstations
• The tool nodes = operators controlling the machines
• The graph = blueprint of the entire factory
• The runnables = modular Lego-like parts for assembling workflows
• The messages = conversations between workers, machines, and managers

Let’s break this down step by step.

State : The Factory’s Memory

A state is a shared data structure that holds the current information of your application.

Imagine a whiteboard at the entrance of a factory. Every time something is updated — like materials arriving, work being done, or outputs ready — it’s recorded here.

This ensures every worker (node) knows the latest status.

from typing import TypedDict

class FactoryState(TypedDict):
    item: str
    progress: str

Here, FactoryState defines what information our factory tracks: the item being worked on and its progress.

Nodes:  The Workstations

Nodes are individual functions that perform one specific job.

In a car factory, one station might install the wheels, another paints the body, and another inspects quality. Each station = a node.

def paint_node(state: FactoryState) -> FactoryState:
    state["progress"] = f"Painting {state['item']}"
    return state

Each node:

• Takes the current state as input
• Does its job (e.g., painting)
• Updates the state
• Returns the updated state

Graph:  The Blueprint of the Factory

A graph is the overarching structure — the blueprint of the workflow.

Just like an architect draws a factory floor plan, a graph maps out which workstation (node) connects to which, and in what sequence.

from langgraph.graph import StateGraph

graph = StateGraph(FactoryState)

This creates a workflow blueprint for how tasks will flow through the factory.

Edges:  The Conveyor Belts

Edges are the connections between nodes. They define the flow of execution.

Conveyor belts carry car parts from one workstation to another. Without belts, workers would be isolated.

graph.add_edge("painting", "inspection")

This means once painting is done, the item automatically moves to inspection.

Conditional Edges

Some conveyor belts have switches that decide where an item should go. Think of a railway track switch. Depending on the condition, a car may go left (to polishing) or right (to repairs).

if state["progress"] == "damaged":
    next_node = "repair"
else:
    next_node = "finish"

This is like a traffic light deciding the next move.

Start and End Points

• Start point = the factory entrance (where raw materials arrive)
• End point = the exit gate (finished product shipped out)

graph.set_entry_point("painting")
graph.set_finish_point("inspection")

The start point doesn’t do any work itself — it just marks where execution begins.

Tools:  The Machines

Tools are specialized utilities that nodes can use. A workstation worker might use a drill, paint gun, or screwdriver to complete their task. These are tools.

For example:

• A fetch_data tool → gets information from an API
• A calculator tool → performs math operations

Tool Nodes:  The Operators

A tool node is a node whose only job is to run a tool. The operator at the paint station doesn’t paint by hand — they just control the painting machine.

def api_tool_node(state: FactoryState) -> FactoryState:
    data = fetch_from_api()
    state["progress"] = f"Fetched data: {data}"
    return state

The operator (tool node) runs the machine (tool), then updates the whiteboard (state).

State Graph:  The Factory’s Master Blueprint

The state graph manages all:

• Nodes (workstations)
• Edges (conveyor belts)
• State (the whiteboard)

Think of it as the master blueprint of a skyscraper. It doesn’t do the work but defines structure and flow.

graph = StateGraph(FactoryState)
graph.add_node("paint", paint_node)
graph.add_node("inspect", inspection_node)

Runnables: Lego Blocks

Runnables are modular, standardized components. Think of Lego bricks. Each brick is small, but they can be snapped together to build castles, cars, or spaceships. Similarly, runnables let you assemble sophisticated AI workflows.

Messages: The Conversations

Messages are how humans, AI, and tools communicate in LangGraph. In our factory, workers shout instructions, machines beep when done, and managers give guidelines. These are messages.

Types of messages:

1. Human message → input from the user (e.g., “Build a red car”)
2. AI message → response from the AI (e.g., “Okay, painting car red”)
3. System message → manager’s instruction (e.g., “Always ensure safety first”)
4. Tool message → output from a tool (e.g., “Wheels attached”)
5. Function message → result of a function call

Example:

from langchain.schema import HumanMessage, AIMessage, SystemMessage

conversation = [
    SystemMessage(content="You are a helpful assistant."),
    HumanMessage(content="Build me a chatbot"),
    AIMessage(content="Sure, I’ll design the workflow.")
]

Summary of Core Elements

• State → Whiteboard (memory of the app)
• Node → Workstation (specific task)
• Graph → Blueprint (overall structure)
• Edge → Conveyor belt (flow of execution)
• Conditional edge → Railway switch (if/else flow)
• Start/End → Factory entrance and exit
• Tool → Machine at the workstation
• Tool node → Operator who runs the machine
• State graph → Master blueprint of factory workflow
• Runnable → Lego brick (modular execution unit)
• Messages → Communication between humans, AI, and tools

Now that you understand the core elements of LangGraph, you’re ready to move from theory to practice.

With these concepts mastered, you are now ready to build actual AI workflows.

Catch the whole LangGraph Series here: LangGraph Reading List.

Thank you for reading!

Other Readings You Might Be Interested In

• Where did multi-agent systems come from?
• Summarising large documents with GPT-4o
• How does LlamaIndex compare to LangChain in terms of ease of use for beginners
• Pre-training vs. fine-tuning [with code implementation]
• Costs of Hosting Open Source LLMs vs Closed-Sourced (OpenAI)
• Embeddings: The Backbone of LLMs
• How to Use a Fine-Tuned Language Model for Summarization