DEV Community: KUNAL HORE

Post-0002. LangGraph Learning Journal — Day 02: An Edge Says "Go There." A Conditional Edge Says "Let Me Check First."

KUNAL HORE — Sat, 18 Jul 2026 16:03:06 +0000

Day 2 · by Kunal Hore (@KunalOnTech)

Quick Jump

Quick Recap of Day 1
Why I'm Learning This Publicly
Today's Map
1. The Router
2. The Conditional Edge
3. Build & Run — The Full Exercise
Kunal's Interview Corner
Today's Takeaway

Quick Recap of Day 1

On Day 1, we built our first LangGraph: a food-ordering workflow using state (the facts the graph remembers), nodes (functions that read and update the state), and edges (the fixed connections between nodes).

But that graph had one limitation — it could only follow one fixed path. Every run looked exactly the same:

Feel hungry → Open app → Browse restaurants → Pick dish → Place order

No matter what happened, the graph always followed that sequence.

Real-world workflows aren't that predictable. What if the restaurant is closed? Should the graph still try to pick a dish and place an order?

That's today's lesson: teaching the graph how to make decisions.

Kunal's one-liner: "An edge says go there. A conditional edge says let me check first."

New here? This is Day 2 of the series. Complete Day 1 first — today's lesson builds directly on the graph we created there.

Why I'm Learning This Publicly

I'm learning LangGraph from zero — one concept a day. No shortcuts, no pretending I already know it. Whatever I learn each day, I share the same day: the wins, the confusion, the "oh THAT'S what it means" moments, all of it.

My goal is simple:

One concept per day, explained with everyday analogies — no jargon walls
Real code every single day, because you learn by building, not by theory alone
Write it the way I wish someone had explained it to me

Your goal, if you learn alongside me: by the end of this series, we'll both be able to design and build stateful AI agents — the kind of systems that can decide, branch, retry, and loop, not just respond once.

And since I'm learning as I go, I might miss something or get a detail wrong. If you're reading and feel I've overlooked anything, drop it in the comments — it genuinely helps me grow, and it makes this series better for everyone following along.

No fluff. One bite a day.

Today's Map

The Router — the function that reads the current state and decides which path to take next.
The Conditional Edge — the mapping that connects the router's decision to the next node.
Build & Run — extend the graph from Day 1 by adding your first conditional branch.

1. The Router

Imagine standing at a crossroads with multiple paths ahead. Before moving forward, someone needs to look at the current situation and decide which direction the journey should take. That's exactly what a router does.

A router is simply a function that reads the current state, makes a routing decision, and returns a string label such as "restaurant_open" or "restaurant_closed". This label represents the decision and is used by the conditional edge to determine which node should run next.

The router's responsibility ends after making the decision. It does not update the state or perform the actual processing — that responsibility belongs to the nodes.

Role	Action
Router	Decides and returns a label
Conditional Edge	Uses that label to choose the next node
Node	Processes and updates state

# Router — reads state, returns a string label, never edits state
def route_by_availability(state):
    if state["is_restaurant_open"]:
        return "restaurant_open"
    return "restaurant_closed"

Remember this:

A router decides, but never edits. A router's only job is to read the current state, decide the path, and return a label. It should never modify the state itself. Keeping decision-making separate from state updates makes your graph easier to understand and debug. If a router starts changing values, it becomes unclear whether the router or a node caused that change.
The router runs fresh every time. Whenever execution reaches a conditional edge, LangGraph executes the router function again. It does not remember or reuse a previous decision. Instead, it reads the current state at that moment and makes a fresh routing decision based on the latest information available. This means if a previous node updated the state before reaching the conditional edge, the router automatically sees those changes and can return a different label, allowing the graph to follow the correct path.

2. The Conditional Edge

A conditional edge is simply a connection between the router's decision and the next node to execute. It uses a mapping dictionary that defines where each label should go. For example, the label "restaurant_open" maps to the "pick_dish" node, while the label "restaurant_closed" maps to the "notify_closed" node.

When the router returns a label, the conditional edge looks up that label in the mapping dictionary and routes execution to the corresponding node. In other words, the router sends its decision in the form of a label, and the conditional edge uses that label to determine the next node in the graph.

graph.add_conditional_edges(
    "check_availability",           # Source node
    route_by_availability,          # Router function
    {
        "restaurant_open": "pick_dish",        # Branch 1
        "restaurant_closed": "notify_closed",  # Branch 2
    }
)

Remember this:

Mapping dictionary keys must exactly match the router's output. Every key in the mapping dictionary must be identical to the label returned by the router. If the router returns "restaurant_open", the mapping must also use "restaurant_open" — not "open" or "Restaurant_Open". Even a small typo or capitalization mismatch means the conditional edge cannot find a matching route, and the graph throws an error at runtime. The router's return values and the mapping dictionary's keys form a contract, so they must always match exactly.
Three arguments, in order. add_conditional_edges() always takes three arguments in a fixed order:
- Source node — where the routing decision happens.
- Router function — the function that reads state, makes the decision, and returns a label.
- Mapping dictionary — the lookup table that maps each label to the next node.

A simple way to remember it: Source → Router → Mapping

3. Build & Run — The Full Exercise

Problem statement: Extend the food-ordering graph from Day 1 by adding your first conditional branch. After browsing the menu, check whether the restaurant is open. If it's open, pick a dish and place the order. If it's closed, notify the user and end the workflow. One router, and two possible branches.

This series uses Python 3.11+ — NotRequired needs 3.11 or newer.

from langgraph.graph import StateGraph, START, END
from typing import TypedDict, NotRequired

# The backpack — state shared across the graph
class FoodOrderState(TypedDict):
    mood: str
    app_opened: bool
    restaurant: str
    dish: str
    order_placed: bool
    is_restaurant_open: NotRequired[bool]  # Created later by a node


# Nodes — each one reads state in, changes one field, returns state out
def feel_hungry(state):
    state["mood"] = "hungry"
    return state


def open_app(state):
    state["app_opened"] = True
    return state


def browse_restaurants(state):
    state["restaurant"] = "Biryani House"
    return state


def check_availability(state):
    # Imagine checking a real restaurant API here
    state["is_restaurant_open"] = False  # Change to True to test the other branch
    return state


def pick_dish(state):
    state["dish"] = "Chicken Biryani"
    return state


def place_order(state):
    state["order_placed"] = True
    return state


def notify_closed(state):
    print(f"{state['restaurant']} is closed. Can't order right now.")
    return state


# Router — reads state, returns a string label, never edits state
def route_by_availability(state):
    if state["is_restaurant_open"]:
        return "restaurant_open"
    return "restaurant_closed"


# Build the graph
graph = StateGraph(FoodOrderState)

# Register nodes
graph.add_node("feel_hungry", feel_hungry)
graph.add_node("open_app", open_app)
graph.add_node("browse_restaurants", browse_restaurants)
graph.add_node("check_availability", check_availability)
graph.add_node("pick_dish", pick_dish)
graph.add_node("place_order", place_order)
graph.add_node("notify_closed", notify_closed)

# Shared path
graph.add_edge(START, "feel_hungry")
graph.add_edge("feel_hungry", "open_app")
graph.add_edge("open_app", "browse_restaurants")
graph.add_edge("browse_restaurants", "check_availability")

# Conditional edge
graph.add_conditional_edges(
    "check_availability",
    route_by_availability,
    {
        "restaurant_open": "pick_dish",
        "restaurant_closed": "notify_closed",
    },
)

# Branch 1
graph.add_edge("pick_dish", "place_order")
graph.add_edge("place_order", END)

# Branch 2
graph.add_edge("notify_closed", END)

# Compile
app = graph.compile()

# Initial state — only includes values known before execution starts
initial_state = {
    "mood": "",
    "app_opened": False,
    "restaurant": "",
    "dish": "",
    "order_placed": False,
}

# Run
final_state = app.invoke(initial_state)

print("\nFinal State:")
print(final_state)

Output:

Final State:
Biryani House is closed. Can't order right now.
{'mood': 'hungry', 'app_opened': True, 'restaurant': 'Biryani House', 'dish': '', 'order_placed': False, 'is_restaurant_open': False}

Notice that dish is still empty and order_placed is still False. That's because the graph never entered Branch 1. The check_availability node set is_restaurant_open to False, the router read that value and returned the label "restaurant_closed", and the conditional edge routed execution down the closed branch.

Now change is_restaurant_open to True inside the check_availability node and run the graph again. The graph itself doesn't change — only the state produced by that node does. This time, the router returns a different label, the conditional edge follows the open branch, and the graph picks a dish before placing the order. That's the power of conditional routing.

Kunal's Interview Corner

Four questions someone might actually ask about today's lesson — the kind that surface gaps a quiet read-through never does. These aren't definitions to memorise. Each one comes with an answer framework — the structure an interviewer wants to hear. Try answering before you tap.

Q1. What's the difference between a normal edge and a conditional edge?

· Answer Framework: Contrast the two → Give a mental picture

· Answer: A normal edge always follows the same path — after one node finishes, the next node is fixed. A conditional edge chooses the next path at runtime based on the current state. Think of a normal edge as a fixed roadmap, and a conditional edge as a GPS that picks the best route based on the current situation.

Q2. What is a router function in LangGraph?

· Answer Framework: Define its job → State the golden rule

· Answer: A router is a plain function that reads the current state, decides which path to take, and returns a string label. Its only job is to make the routing decision. Think of it as a navigator — it tells you where to go, but it never drives the car.

Q3. Can a router modify state?

· Answer Framework: Direct answer → Why → The consequence

· Answer: No. A router should only read the state and decide the next path. Updating the state is the responsibility of nodes. Mixing those responsibilities makes it difficult to understand where a value changed and makes debugging much harder.

Q4. What happens if the router returns a label that's not in the mapping dictionary?

· Answer Framework: State the fact → Explain the behaviour

· Answer: The graph can't determine where to go next, so execution fails with an error. The router's return value must exactly match one of the keys in the mapping dictionary. Even a small typo or difference in capitalization breaks the route.

"If you can answer these four questions without checking your notes, Day 2 has truly stuck."

Today's Takeaway

If you remember only three things from today, remember these:

Term	Meaning
Router	Reads the current state, decides which path the graph should take, and returns a label that the conditional edge uses to route execution.
Conditional Edge	Calls the router, looks up the returned label in the mapping dictionary, and routes execution to the correct node.
Mapping Dictionary	A lookup table inside the conditional edge that maps router labels to nodes. Every key must exactly match a label the router can return.

Day 1 gave your graph a body — a fixed sequence of steps.

Day 2 gave it a brain — the ability to read its current state and choose the next path.

Next up → Day 3: Loops — When Graphs Revisit Previous Nodes

Remember the one-liner from Day 1?

"Code that can loop back, can think."

We've taught our graph how to choose a path. Next, we'll explore how graphs can revisit earlier nodes to model real-world workflows.

Following along? Connect with me on LinkedIn · YouTube: @kunalontech

Post-0001. LangGraph Learning Journal — Day 01: Code That Only Moves Forward Can't Think

KUNAL HORE — Fri, 17 Jul 2026 06:55:21 +0000

Day 1 · by Kunal Hore (@KunalOnTech)

Quick Jump

Why I'm Learning This Publicly
Today's Map
1. State
2. Nodes
3. Edges
4. Build & Run — The Full Exercise
Kunal's Interview Corner
Today's Takeaway

Most code runs top to bottom, once, with no memory of where it's been. Real decisions don't move in a straight line — sometimes you loop back, sometimes you branch depending on what just happened. A script can't pause mid-run and reconsider. A graph can.

That single difference — code that can stop, decide, and circle back instead of just executing — is the entire reason LangGraph exists.

Over the next few days I'll cover all the topics to make you familiar with LangGraph. This is my first day of learning, and I'll share whatever I learn along the way. Today it's the three basics — what a graph remembers (state), what counts as one step (a node), and how those steps connect (an edge). We won't just talk about them — we'll build a small hands-on exercise with real code, because I've always believed you learn by building, not by theory alone.

Kunal's one-liner: "Code that only moves forward can't think. Code that can loop back, can."

That's the whole pitch for today. Everything else — TypedDict, function signatures, edge syntax — is just the mechanics of making that one idea real in Python.

Why I'm Learning This Publicly

My goal is simple:

One concept per day, explained with everyday analogies — no jargon walls
Real code every single day, because you learn by building, not by theory alone
Write it the way I wish someone had explained it to me

And since I'm learning as I go, I might miss something or get a detail wrong. If you're reading and feel I've overlooked anything, drop it in the comments — it genuinely helps me grow, and it makes this series better for everyone following along.

No fluff. One bite a day.

Who this is for: Anyone comfortable writing plain Python functions who's curious how agent frameworks actually work under the hood. No prior LangChain or LangGraph experience assumed — we start from zero.

Do I need to know LangChain first? No. LangGraph is its own thing — a graph engine for stateful workflows. Familiarity with LangChain helps but isn't required for any page in this series.

Today's Map

State — the fact; what your graph is allowed to remember
Nodes — one action; a function that updates the state
Edges — the order actions happen in; what runs after what
Build & Run — wiring it together, compiling, and running your first graph

1. State

It's 8 PM. You feel hungry. That's the first thing on your mind right now: hungry. Your brain thinks, let me open the food app — now it knows one more thing: the app is open. You browse a bit, pick a restaurant. One more thing your brain is holding onto: which restaurant. You pick a dish — another thing added. You place the order — one more.

By the time you're done, your brain isn't holding one thought anymore — it's holding five, all at once: that you're hungry, that the app's open, which restaurant, which dish, and whether the order's placed.

That collection of things your brain is keeping track of — that's state.

It isn't a loose pile of facts. It has a fixed shape: a fixed list of fields, each with a fixed type — defined in code as a class, using TypedDict.

from typing import TypedDict

class FoodOrderState(TypedDict):
    mood: str
    app_opened: bool
    restaurant: str
    dish: str
    order_placed: bool

Remember this:

What TypedDict actually does — TypedDict is a way to describe the shape of a dictionary using a class. It doesn't create a new kind of object — at runtime, your state is still a plain dictionary. What TypedDict adds is a contract: it tells Python (and you) exactly which keys must exist and what type each one holds.
Why that matters here — Every node uses the same shape for state. So TypedDict helps your editor and LangGraph check two simple things before the code runs: that you are not reading a field that does not exist, and that you are not putting the wrong type of value into a field.

2. Nodes

Your brain was holding five facts — hungry, app open, restaurant, dish, order placed. None of those facts filled themselves in. Each one was the result of something you did: you felt hungry, you opened the app, you picked a restaurant.

Each of those actions is what we call a node — a function that takes the current state in, changes one thing about it, and hands the updated state back out.

A node, in code:

def feel_hungry(state: FoodOrderState) -> FoodOrderState:
    state["mood"] = "hungry"
    return state

Registering it:

graph.add_node("feel_hungry", feel_hungry)

Remember this:

add_node takes two arguments — The first is a label, a string used to refer to this node when wiring edges. The second is the actual function that runs. They don't have to match, but keeping them identical is the convention, purely for readability.
A node is the only thing allowed to change state — A node can do anything a Python function can do — print, call an API, or write to a file. But the graph only passes along the state your node returns. Anything you don't include in that returned state isn't available to other nodes.

3. Edges

The order those actions happened in — feel hungry, then open app, then browse — that sequence is the edge. An edge connects one node to another and defines the path the graph follows after a node finishes. If there are multiple possible paths, a routing step decides which edge to take before the graph moves forward.

An edge, in code:

# after feel_hungry finishes, run open_app next
graph.add_edge("feel_hungry", "open_app")

4. Build & Run — The Full Exercise

Problem statement: Model a person ordering food as a graph — a shared state tracking five facts, five nodes that each update one fact, and edges running them in a fixed sequence, from feeling hungry to the order being placed.

Here's the exact path our graph will walk:

START
  │
  ▼
Feel Hungry
  │
  ▼
Open App
  │
  ▼
Browse Restaurants
  │
  ▼
Pick Dish
  │
  ▼
Place Order
  │
  ▼
 END

# Imports — the graph builder and the typed-dict base class
from langgraph.graph import StateGraph, START, END
from typing import TypedDict

# The backpack — five fields the whole graph shares and updates
class FoodOrderState(TypedDict):
    mood: str
    app_opened: bool
    restaurant: str
    dish: str
    order_placed: bool

# Nodes — each one reads state in, changes one field, returns state out
def feel_hungry(state):
    state["mood"] = "hungry"
    return state

def open_app(state):
    state["app_opened"] = True
    return state

def browse_restaurants(state):
    state["restaurant"] = "Biryani House"
    return state

def pick_dish(state):
    state["dish"] = "Chicken Biryani"
    return state

def place_order(state):
    state["order_placed"] = True
    return state

# Build the graph — create it, then register every node
graph = StateGraph(FoodOrderState)
graph.add_node("feel_hungry", feel_hungry)
graph.add_node("open_app", open_app)
graph.add_node("browse_restaurants", browse_restaurants)
graph.add_node("pick_dish", pick_dish)
graph.add_node("place_order", place_order)

# Edges — wire the nodes in the order they should run
graph.add_edge(START, "feel_hungry")
graph.add_edge("feel_hungry", "open_app")
graph.add_edge("open_app", "browse_restaurants")
graph.add_edge("browse_restaurants", "pick_dish")
graph.add_edge("pick_dish", "place_order")
graph.add_edge("place_order", END)

# Compile — locks the blueprint into something runnable
app = graph.compile()

# Run — start with an empty backpack and walk the graph end to end
initial_state = {
    "mood": "",
    "app_opened": False,
    "restaurant": "",
    "dish": "",
    "order_placed": False,
}

final_state = app.invoke(initial_state)
print(final_state)

Output:

{
    'mood': 'hungry',
    'app_opened': True,
    'restaurant': 'Biryani House',
    'dish': 'Chicken Biryani',
    'order_placed': True
}

Every node updated one piece of the shared state. Nothing magical happened — the graph simply walked through the nodes one by one, carrying the same dictionary from start to finish.

Kunal's Interview Corner

Q1. What's the difference between a LangGraph workflow and a normal Python script?

· Answer Framework: Contrast the two → Give a mental picture

· Answer: In a normal Python script, things run one after the other in a straight line. With LangGraph, it's more flexible — think of it like a flowchart, where you can jump around and execute tasks in different orders.

Q2. What is State in LangGraph?

· Answer Framework: Plain-words definition → What it enables

· Answer: State is basically a shared notebook that all the nodes can access and update. It helps them talk to each other and remember what's going on.

Q3. What is a Node in LangGraph?

· Answer Framework: Define its job → Describe its behaviour

· Answer: A node is just a small task that does one specific thing. It looks at the current state, does its job, and then updates the state if needed.

Q4. What is an Edge in LangGraph?

· Answer Framework: Give the analogy → State what it controls

· Answer: An edge is like an arrow that connects two nodes. It determines the order in which they run.

"If you can answer these four without checking your notes, Day 1 actually stuck."

Today's Takeaway

If you remember only three things from today, remember these:

Term	Meaning
State	What your graph remembers
Node	One unit of work that changes state
Edge	The connection that says which node runs next

Everything else in LangGraph builds on these three ideas. Master them once, and the rest becomes much easier.

Next up → Day 2: Conditional Edges

Following along? Connect with me on LinkedIn · YouTube: @kunalontech