Conditional Edges

What you will be able to do

• ✓Explain the difference between a normal edge and a conditional edge
• ✓Write a router function that reads the state and returns the next node
• ✓Connect it with add_conditional_edges and a path map
• ✓Explain why the path map is important
• ✓Route on more than one field, and finish the run early with END
• ✓Use an LLM to classify a question, and plain code to route it

The idea, in plain English

In Lessons 3.1 and 3.2 every edge was fixed: after node A, always node B. Real workflows need choices. A question about money should go to the billing team. A question about an error should go to the technical team.

A conditional edge makes this possible. After a node finishes, LangGraph calls a small function - the router. The router looks at the state and answers one question: "Which node is next?" LangGraph then runs that node, and only that node.

In this lesson we build a support desk step by step, break it on purpose to see the common mistakes, and finally replace a simple keyword check with llama3. Everything was run with LangGraph 1.2.14 and llama3 through Ollama.

Worked example: A support desk: a question comes in, a classifier decides what kind it is, and a router sends it to the billing, technical or account team.

Words you will see in this lesson

A few words used again and again in this lesson.

An everyday example: a hospital reception

You walk into a hospital. Three people help you, and each one has one job:

• •The receptionist listens to your problem and writes the department on your token: "Cardiology". (This is the classifier node.)
• •The sign board at the corridor reads the token and points you to a door. It does not treat you and does not change your token. (This is the router.)
• •The doctor behind the door does the real work. (These are the worker nodes.)

Normal edge vs conditional edge

There are two ways to connect a node to the next one:

• •add_edge("classify", "billing") - after classify, ALWAYS go to billing. No choice.
• •add_conditional_edges("classify", route_request, ["billing", "technical"]) - after classify, call route_request(state), and go to the node it returns: billing OR technical.
• •Only the chosen node runs. A billing question never costs a call to the technical team.
• •The router can use anything in the state: a category, a yes/no flag, a tool result, a retry count.

Three jobs - keep them apart

The most important idea of this lesson is that deciding and doing are separate jobs. Give each job its own piece of code:

• •Classify (a node): work out WHAT the question is, and write it into the state - category = "billing".
• •Route (the router function): read the state and answer only WHERE to go next - return "billing". No other work.
• •Work (worker nodes): do the actual job - write the reply for a billing question.

Tip: Because each job is separate, you can change one without touching the others. Later in this lesson we replace the classifier with llama3, and the router and the workers stay exactly the same.

Example 1, step 1 - the state and the classifier

The state has three fields: the question, the category (filled in by classify), and the response (filled in by a worker).

classify is a normal node. For now it uses a simple keyword rule: if the question contains "charge" or "payment", the category is billing; otherwise technical. It returns a dict, and LangGraph writes that into the state.

Example 1, step 2 - the workers and the router

billing and technical are the worker nodes. Each one writes a response.

route_request is the router. Look at how small it is:

• •It receives the state - the same state the nodes see.
• •It reads one field: state["category"].
• •It returns a string: the NAME of the next node, "billing" or "technical".
• •It does not return a dict, and it does not change the state.

Example 1, step 3 - connect everything

Now we build the graph. Read the edges from top to bottom:

• •START -> classify: a normal edge. Every run starts with classify.
• •classify -> ?: a conditional edge. After classify, LangGraph calls route_request and goes to the node it names.
• •The third argument, ["billing", "technical"], is the path map: the only nodes the router may choose.
• •billing -> END and technical -> END: normal edges. After a worker, the run is finished.

Watch the choice happen

stream_mode="updates" prints what each node changed, in order. It shows the route clearly:

• •First update: classify wrote category = billing.
• •Second update: the billing node ran - because the router chose it.
• •There is no update from technical. It never ran.

The path map - three ways to write it

The path map tells LangGraph which nodes the router can choose. You can give it in three ways. All three worked the same in our test:

• •A list of node names: ["billing", "technical"]. The router returns a node name. This is the simplest.
• •A dict: {"BILLING_PATH": "billing", "TECHNICAL_PATH": "technical"}. The router returns a key, and the dict turns it into a node name.
• •A Literal return type on the router: -> Literal["billing", "technical"]. Then you do not pass a third argument - LangGraph reads the allowed names from the type.

Why you should always give a path map

The path map looks optional - the code runs without it. But we tested a small typo: the router returned "biling" (one l) instead of "billing".

• •Without a path map: NO error. LangGraph only wrote a warning to the log, ran nothing after classify, and returned a state with no response. In a real app, the customer would simply get no answer.
• •With a list path map: KeyError: ‘biling’. The mistake is reported at once.
• •With a Literal return type: also KeyError: ‘biling’.
• •The drawing also changes. Without a path map, get_graph() drew classify --> __end__, as if the teams did not exist. With a path map (or Literal) it drew classify -.-> billing and classify -.-> technical.

Watch out: A wrong node name without a path map fails silently. Always pass the path map (a simple list is enough) or give the router a Literal return type.

Two more silent mistakes

These two also gave no error at all - only a missing response:

• •Forgetting add_conditional_edges: the router function exists, but nobody calls it. The run ended after classify.
• •A router that returns a dict like {"category": "billing"} instead of a node name: LangGraph ignored it with the warning "wrote to unknown channel". A router cannot change the state - only nodes can.

Tip: A router is a plain function of the state, so it is the easiest part of a graph to test: make a small state dict, call the router, and check the name it returns.

Example 2 - several rules, and finishing early

A router can check more than one field. And a conditional edge can also start right at START. In this version:

• •check_question runs first, from START. If the question is empty, it returns END - the run finishes at once, and nothing else runs.
• •route checks authenticated FIRST. A user who is not logged in goes to the login node, whatever the question is.
• •Only logged-in users are routed by category.
• •Both routers have a Literal return type, so no path map argument is needed. Note "__end__" - that is the name END stands for.

Reading Example 2

• •Not logged in + a payment question -> "Please log in first." The login rule won, even though classify said billing.
• •Logged in + a payment question -> billing team.
• •Logged in + a crash -> technical team.
• •An empty question -> the state came back unchanged: no category, no response. check_question returned END before classify could run.
• •A conditional edge can also point back to a node that already ran. That makes a loop - the topic of Lesson 3.4.

Example 3 - the model classifies, the graph routes

The keyword rule is the weak part of our support desk. People describe the same problem with many different words. So we replace only the classify node with llama3:

• •Category is a Pydantic model whose field is Literal["billing", "technical", "account"]. with_structured_output(Category) forces llama3 to answer with exactly one of these three words.
• •This is what keeps the graph safe: the model can never invent a category that the router does not know.
• •classify_with_llm returns {"category": ...} - exactly like the old classify. The router and the workers do not change at all.
• •temperature=0 makes the answers as repeatable as possible.

When to use a model, and when plain code

The keyword rule got 3 of 8 right. "billed", "refund" and "card declined" mean billing, but they do not contain "charge" or "payment". And it has no account category at all. llama3 got all 8 right, in about half a second each.

But a model is not always the right tool. A simple rule:

• •Use a model when the input is free text that must be understood: what does the customer want?
• •Use plain code when the answer is already in the state: is the user logged in? Is the retry count above 3? Is the question empty?
• •Plain code is free, instant and always gives the same answer. A model costs time (and often money) and can be wrong.
• •Even with a model, keep the router as plain code. The model fills in category; the router only reads it.

Why not one node with if / else?

You could write one big node: if billing: ... elif technical: ... That works for two cases. As the app grows, conditional edges are better:

• •You can SEE the decisions in the graph drawing, instead of hiding them inside one function.
• •Each team is its own node, so you can test, stream and trace it on its own.
• •Adding a new team is one new node and one new name in the path map.

The recipe

Every conditional edge you write follows the same four steps:

• •1. A node writes the decision into the state (category = "billing").
• •2. A router function reads the state and returns the name of the next node - nothing else.
• •3. add_conditional_edges("node", router, ["option1", "option2"]) - always with the path map, or a Literal return type.
• •4. Every option is a node that does the work, followed by its own edge.

Conditional edges at a glance

builder.add_edge("billing", END)

add_conditional_edges("classify", route, ["billing", "technical"])

def route(state): return "billing"

["billing", "technical"]

{"BILLING_PATH": "billing"}

-> Literal["billing", "technical"]

return END

add_conditional_edges(START, check_question)

Try it yourself

The code does not change. Swap the content string and the program does something else entirely.

What usually goes wrong

✗ builder.add_conditional_edges("classify", route_request)

✓ builder.add_conditional_edges("classify", route_request, ["billing", "technical"])

✗ def route(state):
    call_billing_api(state)
    return "billing"

✓ def route(state):
    return "billing"

def billing(state):
    return {"response": call_billing_api(state)}

Quick check before you move on

1. 1.

   The router returns "biling" and there is no path map. What happens?

   Show answer
2. 2.

   Why did the keyword classifier send "I was billed twice" to technical?

   Show answer
3. 3.

   What changed in the graph when llama3 replaced the keyword classifier?

   Show answer
4. 4.

   A user who is not logged in asks about a payment. Where does Example 2 send them, and why?

   Show answer
5. 5.

   Can a conditional edge create a loop?

   Show answer

Interview questions