L25- Conditional Edges in LangGraph | Router Function, add_conditional_edges & Restaurant Classifier

Lecture 25 of the AI for Software Engineers series — Bipin Kumar adds branching logic to LangGraph. Conditional edges let the LLM decide which path to take at runtime — making your workflows truly intelligent, not just sequential. 🧠 What's Covered: Solid vs Dotted Edge — What's the Difference: Solid lines in a LangGraph workflow mean the connection always runs — no decision needed. Dotted lines mean the path is conditional — which branch to take is decided at runtime based on the LLM output. This is what add_conditional_edges creates. Router Function — The Decision Maker: To create a conditional branch, you write a separate router function. This function takes the State as input and returns a value — for example "veg", "non-veg", or "dessert". This returned value is then matched to a mapping dictionary that says which node to go to next. Important: the router function only returns a value, it does not update any State key. It is also not added as a node. add_conditional_edges — 3 Arguments: Argument 1 is the source node — where the conditional branching starts. Argument 2 is the router function — which inspects the State and returns a routing value. Argument 3 is a mapping dictionary — each possible return value maps to a destination node label. Restaurant Classifier Demo — Built in Class: State: order_text, category, assigned_to, confirmation. Workflow: START → classify_order → conditional branch → veg_kitchen / non_veg_kitchen / dessert_counter → confirm → END. classify_order node sends the order text to the LLM and gets back exactly one word — veg, non-veg, or dessert — stored in the category key. The router function reads category and returns it. The mapping routes veg to veg_kitchen, non-veg to non_veg_kitchen, and dessert to dessert_counter. Each kitchen node assigns the order. confirm node adds the confirmation message. Live test: "2 masala dosas and filter coffee" → classified as veg → routed to veg_kitchen correctly. "Chicken biryani for four people" → classified as non-veg → routed to non_veg_kitchen correctly. The State Overwrite Problem: By default, every time a State key is updated, the previous value is replaced. For most workflows this is fine. But for chat history or audit logs, you want to keep all previous values — not just the latest one. Reducer — The Solution: By annotating a State key with Annotated[list, operator.add], that key appends new values instead of overwriting. This is called a reducer. Every new update adds to the list rather than replacing it. This is essential for building chatbots where conversation history must be preserved. What Is Coming Next: Memory — persisting State across multiple workflow runs. Human-in-the-Loop — pausing the workflow before a high-stakes action, waiting for human confirmation, then resuming. Interrupts, sub-graphs, multi-agent coordination. Workflow Design Practice Advice from Bipin: Before writing any code, design the workflow on paper first. Identify every step, every condition, and every variable that flows between nodes. Define the State carefully — all variables that any node needs must be declared there. Once the design is clear, implementation becomes straightforward. LangGraph is the foundation for all complex GenAI systems — adding RAG, tools, multiple agents, and memory all happens within the same node-edge-state structure. ⏭️ Next Lecture (Lecture 26): 👉 LangGraph Memory, Reducers, and Human-in-the-Loop 💬 Questions about the router function or State reducers? Drop them in the comments — Bipin replies! 📌 Subscribe so you never miss a class. #LangGraph #ConditionalEdges #RouterFunction #AgenticAI #LangChain #StateReducer #AIforEngineers #BipinKumar #WorkflowDesign #GenerativeAI #Python #HumanInTheLoop #AIInterview #RestaurantClassifier