Forem: Damilola Oyedunmade

A Beginner’s Guide to Handling Errors in LangGraph with Retry Policies

Damilola Oyedunmade — Mon, 29 Dec 2025 09:36:38 +0000

When you start building real applications with LangGraph, things will break. APIs time out. Tools fail. Models return unexpected outputs. Network calls behave unpredictably. This is not a sign that you built something wrong. It is the reality of production systems.

The real problem is not that errors happen. It is what happens after they do.

Before we dive in, here’s something you’ll love:
Learn LangChain in a clear, concise, and practical way.
Whether you’re just starting out or already building, LangCasts offers guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

Without proper error handling, a single failed node can halt your entire graph, disrupt user experience, and leave you with little insight into what went wrong. In production environments, this is unacceptable. Your graph needs to be resilient, predictable, and capable of recovering from temporary failures on its own.

This is where LangGraph’s Retry Policies come in. Instead of manually wrapping nodes in try–except blocks or rebuilding failed flows, LangGraph provides a structured, graph-native way to retry failed operations intelligently. You decide how many times a node should retry, how long it should wait, and when it should finally give up.

In this article, we’ll explore how LangGraph treats errors at the graph level, how retry policies work, and how to use them to build systems that recover gracefully without complicating your code.

By the end, you’ll understand how to let your graph handle failure intentionally, so your agents feel reliable instead of fragile.

How LangGraph Thinks About Errors

In LangGraph, every node is an execution unit. A node receives state, performs work, and returns an update to that state. From the graph’s perspective, this is just another step in execution. There is no distinction between “safe” nodes and “risky” ones. Everything runs under the same model.

By default, when a node fails, the graph stops. The error surfaces immediately, and execution halts. This behaviour is intentional. LangGraph does not guess how you want failures handled. It does not silently retry, skip steps, or recover on your behalf.

This design makes failures explicit. Instead of patching errors later with scattered try–except blocks, LangGraph treats failure as a first-class part of the graph lifecycle. Nodes can fail for many valid reasons. A tool might time out. An API might return malformed data. A model might produce unexpected output. These are not edge cases. They are expected realities.

Retry policies exist because LangGraph assumes that some failures are temporary and recoverable. Rather than hiding errors or reacting unpredictably, LangGraph gives you structured control over how the graph should respond. That mindset is what makes retry policies powerful and safe, not magical or dangerous.

Understanding Retry Policies in LangGraph

A retry policy defines how LangGraph should respond when a node fails. Instead of ending execution immediately, the policy tells the graph whether the node should try again and when to stop.

At a high level, a retry policy controls how many retry attempts are allowed, under what conditions retries should occur, and when failure should be treated as final. This turns failure from a dead end into a managed process.

Some failures are temporary. A network request might fail due to a timeout or a brief service outage. Retrying the same operation after a short delay often resolves the issue. Other failures, such as invalid input or logic errors, should not be retried endlessly. Retry policies help you draw that line clearly.

What makes retry policies especially powerful in LangGraph is that they are part of the graph itself. Retry behaviour is not hidden inside node code or wrapped in custom logic. The graph understands that a node may fail, that retries may occur, and that there is a defined stopping point. This keeps execution predictable, debuggable, and intentional.

In short, retry policies give your graph patience without sacrificing control.

Adding a Retry Policy to a Node

Retry policies are attached directly to nodes, which makes sense because nodes are the execution units of your graph. Reliability concerns stay close to where work happens, while node logic remains clean.

Here’s a simple example:

from langgraph.graphimport StateGraph
from langgraph.pregelimport RetryPolicy

deffetch_data(state):
return {"data":"result"}

retry_policy = RetryPolicy(
    max_attempts=3
)

graph = StateGraph()

graph.add_node(
"fetch_data",
    fetch_data,
    retry=retry_policy
)

In plain English, this says:

If fetch_data fails, LangGraph will retry it up to three times before giving up.

There are no loops, no try–except blocks, and no manual counters. The retry behaviour lives in the graph configuration, not inside your node. This separation keeps your logic focused and your system easier to reason about as it grows.

A Simple Example: Retrying a Failing Tool Call

Imagine a node that calls an external API. Sometimes the API works. Sometimes it fails due to network issues, timeouts, or rate limits. You don’t want your entire graph to collapse because of a temporary hiccup.

Here’s what that looks like:

from langgraph.graphimport StateGraph
from langgraph.pregelimport RetryPolicy

deffetch_data(state):
    response = unstable_api_call()
return {"data": response}

retry_policy = RetryPolicy(
    max_attempts=3
)

graph = StateGraph()

graph.add_node(
"fetch_data",
    fetch_data,
    retry=retry_policy
)

If the API fails, LangGraph retries the node automatically. If it succeeds on a later attempt, the graph continues normally. Your node does not change. Your flow remains clean.

This is exactly how retries should work in agent systems. Invisible when things go right. Graceful when things go wrong.

What Happens When Retries Are Exhausted

Retries do not continue forever. When a node exceeds its retry policy, LangGraph stops retrying and treats the failure as final.

What happens next depends on your graph design. If there is no alternate path, execution halts, and the error is surfaced clearly. Nothing fails silently, and you are not left guessing what happened.

If your graph includes fallback nodes, conditional routing, or recovery logic, execution can continue gracefully. You might return a helpful message to the user, route to a recovery node, or record an error state for inspection. The key idea is that failure is explicit and controlled.

LangGraph does not encourage pretending failures will not happen. Instead, it gives you the tools to decide what should happen when they do.

Errors are inevitable in real-world AI systems. Networks fail. Tools time out. APIs behave unpredictably. What matters is not avoiding failure, but handling it intentionally.

LangGraph’s retry policies make reliability a first-class concern. Instead of crashing your graph or scattering error-handling logic everywhere, retries become part of the graph itself. Nodes can fail and recover. Temporary issues can resolve themselves. And when retries are exhausted, failure is clear and deliberate, not silent or confusing.

Once you adopt this mindset, error handling stops being an afterthought and becomes part of your design. That is the difference between a demo graph and a production-ready one.

A Beginner’s Guide to Dynamic Routing in LangGraph with Command()

Damilola Oyedunmade — Mon, 22 Dec 2025 08:13:37 +0000

When you build agents, not every request should follow the same path. Some inputs require tools, others require reasoning, and some simply need a quick response. Hard-coding all these paths quickly becomes messy. This is where dynamic routing comes in.

Dynamic routing means your graph decides what to do next at runtime, based on the current state. Instead of fixed edges that always lead to the same node, the graph can change direction depending on user intent, tool results, or intermediate reasoning.

LangGraph supports this kind of flexibility naturally, but the real enabler is the Command() API. With Command(), a node can explicitly tell the graph which node to run next and, optionally, update the state at the same time. You’re no longer just returning data; you’re returning instructions.

Think of Command() as giving your node a voice. Instead of silently handing off control, it can say, “Go here next,” “Stop now,” or “Route this to a different path.” That’s the foundation of dynamic routing in LangGraph, and once you understand it, your graphs become far more expressive and intelligent.

What Is Dynamic Routing in LangGraph?

Dynamic routing is the idea that your graph does not have to follow a fixed path. Instead of always moving from Node A to Node B, the next step can change at runtime based on what just happened.

In LangGraph, this means your agent can look at the current state, make a decision, and then choose where to go next. One user input might lead to a search node, another might trigger a tool call, and a third might end the conversation entirely. The flow adapts as it runs.

This is different from static routing, where edges are defined upfront and the graph always follows the same structure. Static routing is predictable, but limited. Dynamic routing is flexible, expressive, and much closer to how real agents behave.

LangGraph supports dynamic routing through the Command() object. Instead of returning just state updates, a node can return instructions that tell the graph exactly what to do next. This is what allows your agent to branch, reroute, loop, or exit intelligently, all at runtime.

Once you understand this concept, you stop thinking of LangGraph as a pipeline and start seeing it as a decision-making system.

How Command() Enables Dynamic Routing

This is where things get interesting.

In LangGraph, Command() is what allows a node to decide what happens next at runtime. Instead of relying on predefined conditional edges, a node can return a Command that explicitly tells the graph which node to run next and what state updates to apply.

Think of Command() as the node saying, “I’ve looked at the situation, and this is where we should go.”

When a node returns a Command, it can specify two important things. First, the next node to jump to. Second, any state updates that should be applied before moving on. This makes routing flexible, expressive, and easy to reason about.

What makes this powerful is that the decision logic lives inside the node itself. The node can inspect user input, model output, tool results, or any part of the state, and then dynamically choose the next step. No extra edge definitions. No complex routing tables. Just clear intent.

Dynamic routing with Command() shines when your agent needs to adapt on the fly. Maybe the user asks a follow-up question, maybe a tool call fails, or maybe the model decides it needs more information before continuing. Instead of forcing all possibilities into static edges, Command() lets your graph respond naturally.

At this point, LangGraph stops feeling like a rigid workflow engine and starts behaving like a living system that can change direction when needed.

Command(): The Engine Behind Dynamic Routing

In LangGraph, Command() is what allows a node to decide what happens next at runtime. Instead of relying only on pre-defined edges, Command() lets a node return instructions that tell the graph both where to go next and how to update state in one move.

At a high level, a Command contains:

the next node (or nodes) the graph should execute
the state updates that should be applied before moving forward

This means routing decisions are no longer fixed in the graph structure alone. They can be made dynamically, based on logic, tool results, or LLM output inside the node itself.

How Command() Enables Dynamic Routing

With Command(), routing logic lives inside the node function. A node can inspect the current state, make a decision, and return a Command that tells the graph exactly what to do next.

Here’s what happens when a node returns a Command:

the node evaluates the current state
It decides which node should run next
It updates the state if needed
The graph immediately follows the instruction

Because state updates and routing happen together, the flow stays predictable and clean. There’s no need for extra router nodes or complex conditional edges.

A Simple Example: Routing Based on User Intent

Let’s make this real with a small example.

We’ll build a router node that looks at user intent and decides where the graph should go next.

The idea

A user sends a message.

If the message looks like a question, we go to a question handler.

If it looks like a command, we go to a command handler.

The routing decision happens inside the node using Command().

Example Code

from langgraph.graph import StateGraph
from langgraph.types import Command

def router(state):
    text = state["input"].lower()

    if "how" in text or "what" in text:
        return Command(
            goto="question_node",
            update={"intent": "question"}
        )

    return Command(
        goto="command_node",
        update={"intent": "command"}
    )

def question_node(state):
    return {"response": "This looks like a question."}

def command_node(state):
    return {"response": "This looks like a command."}

graph = StateGraph()

graph.add_node("router", router)
graph.add_node("question_node", question_node)
graph.add_node("command_node", command_node)

graph.set_entry_point("router")

app = graph.compile()

What’s happening here

The router node inspects the user input.
Instead of returning plain state, it returns a Command.
The goto field tells LangGraph which node to run next.
The update field safely updates the shared state at the same time.
The graph follows the instruction immediately, no conditional edges needed.

This is dynamic routing in its simplest form.

The decision lives inside the node, and the graph just follows orders.

Why this matters

With Command():

routing logic stays close to the reasoning
graphs become easier to read
dynamic flows feel natural, not forced

Once you understand this pattern, you can build agents that adapt on the fly without turning your graph into a maze of conditionals.

Best Practices for Dynamic Routing with Command()

Keep routing logic simple and easy to reason about. A node should decide where to go next based on clear signals, not complex chains of conditions.
Separate decision-making from heavy computation. Let one node focus on choosing the route, and let downstream nodes do the actual work.
Always update state intentionally. Only include the data the next node needs to continue correctly.
Use meaningful node names. This makes your routing logic easier to read, debug, and visualize.
Visualize your graph early. Dynamic routing becomes much clearer when you can see the possible paths your graph can take.

Dynamic routing is what turns a LangGraph app from a fixed pipeline into a truly intelligent system. With Command(), a node can make decisions, update state, and choose the next step all at once — cleanly and explicitly.

Instead of hardcoding paths or relying on fragile conditionals, you let each node say, “Here’s what I learned, and here’s where we should go next.” That clarity is what makes LangGraph powerful, predictable, and scalable.

Once you understand Command(), you stop thinking in straight lines and start designing flows that adapt naturally to user intent and runtime context.

And that’s when your graphs really come alive

Map-Reduce with the Send() API in LangGraph

Damilola Oyedunmade — Mon, 15 Dec 2025 09:50:52 +0000

If you’ve ever looked at a big task and thought, “There has to be a faster way to do this,” you were already thinking in Map-Reduce.

Before we dive in, here’s something you’ll love:

Learn LangChain in a clear, concise, and practical way.
Whether you’re just starting out or already building, LangCasts offers guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

Map-Reduce is a powerful pattern for processing large amounts of data efficiently. In essence, it breaks a big task into smaller chunks (the map phase), processes them independently, and then combines the results (the reduce phase). This approach is widely used in data analytics, machine learning, and large-scale computing.

However, implementing Map-Reduce manually can be tricky. You often have to manage parallel execution, coordinate tasks, and handle intermediate results—all of which can become messy and error-prone.

This is where LangGraph comes in. With its intuitive graph-based architecture and the Send() API, LangGraph makes Map-Reduce workflows cleaner, faster, and more maintainable. Nodes represent tasks, edges define data flow, and Send() enables true parallel execution with minimal boilerplate.

In this article, we’ll explore how to implement Map-Reduce in LangGraph using the Send() API, from the basics to a practical example, showing how this modern approach simplifies one of the most important patterns in data processing.

Before diving into Map-Reduce, it’s helpful to recall some core LangGraph concepts. At its heart, LangGraph organizes computations as a graph of nodes and edges, with nodes performing tasks, edges defining data flow, and state storing intermediate results.

Nodes are the building blocks—each represents a discrete unit of work. If you missed it, check out our previous guide on getting started with nodes in LangGraph.
Edges connect nodes and guide how data flows through your workflow. For a refresher, see our article on edges.
State lets nodes hold temporary results, which is especially handy in patterns like Map-Reduce.
Send() enables parallel execution, letting multiple tasks run simultaneously without manual thread management.

In short, nodes, edges, state, and Send() are the perfect toolkit for building scalable workflows. If you’re familiar with our previous beginner guides, this will feel like a natural next step toward implementing Map-Reduce in LangGraph.

Where Map-Reduce Fits in LangGraph

LangGraph’s design makes it a natural fit for the Map-Reduce pattern. By combining nodes, edges, state, and the Send() API, you can build scalable parallel workflows without the usual complexity.

1. Map Phase – Nodes as Workers

Each node can act as a mapper, processing a piece of data independently. Because nodes are isolated, multiple map tasks can run concurrently, producing intermediate results without interfering with each other.

2. State – Storing Intermediate Results

As nodes process data, they can store outputs in their local state or shared runtime context. These intermediate results are what the reduce phase will later aggregate.

3. Edges – Shuffling Data

Edges guide how intermediate outputs flow from map nodes to reducer nodes. You can fan out results to multiple reducers or aggregate them into a single node, replicating the “shuffle” step in traditional Map-Reduce.

4. Send() – Unlocking True Parallelism

While nodes can run sequentially, the Send() function allows a parent node to dispatch tasks to multiple child nodes at the same time. This is the missing piece that enables full parallel execution: all map tasks can run simultaneously, and their outputs are efficiently routed to reducer nodes.

In Summary:

Nodes = map tasks
State = intermediate storage
Edges = data flow
Send() = parallel execution

With these components, implementing Map-Reduce in LangGraph becomes straightforward, scalable, and easy to maintain.

Practical Example: Word Count with Send()

Let’s bring Map-Reduce to life in LangGraph with a classic example: counting word frequencies in a set of documents.

1. Map Nodes – Processing Each Document

Each document is sent to a separate node using Send(). Map nodes tokenize the text and emit key-value pairs like ("word", 1) for every word found. Because we’re using Send(), multiple documents can be processed in parallel, making the workflow fast and efficient.

def map_node(document, runtime):
    words = document.split()
    counts = [(word, 1) for word in words]
    return counts

2. State – Storing Intermediate Results

Each map node can store its output in local state or a shared runtime context. These intermediate results are collected and passed to reducer nodes for aggregation.

3. Reduce Nodes – Aggregating Results

Reducer nodes take the intermediate key-value pairs and sum the counts for each unique word. This completes the “reduce” step of Map-Reduce.

def reduce_node(intermediate_data, runtime):
    word_count = {}
    for word, count in intermediate_data:
        word_count[word] = word_count.get(word, 0) + count
    return word_count

4. Edges – Guiding Data Flow

Edges connect map nodes to the reducer node(s), forming the shuffle stage. LangGraph handles the routing automatically, ensuring all intermediate results reach the correct reducer.

5. Send() – Parallelizing the Workflow

The Send() API dispatches all map nodes simultaneously. Once all map nodes complete, the results flow to the reducer node(s) without blocking execution. This is how LangGraph achieves true parallel Map-Reduce.

Key Takeaways:

Send() enables parallel mapping across nodes.
Node state holds intermediate outputs.
Edges define how data moves to reducers.
Reducer nodes aggregate results efficiently.

Advantages of Using Send() for Map-Reduce

Using LangGraph with the Send() API offers several key advantages over traditional Map-Reduce implementations:

1. True Parallelism Without Extra Complexity

Send() lets you dispatch multiple nodes simultaneously, so map tasks run in parallel without manually managing threads or processes. This reduces boilerplate code and potential errors.

2. Clean, Maintainable Workflow

Because each task is represented as a node and the data flow is handled by edges, your workflow is visual, easy to follow, and simple to maintain. There’s no need to juggle intermediate files or complicated coordination logic.

3. Scalability Made Easy

Adding more tasks or processing larger datasets is straightforward. Just add more nodes or use Send() to scale horizontally—LangGraph handles the routing and execution automatically.

4. Built-In State Management

Intermediate results are stored in node state or runtime context, making aggregation and reduction seamless. You don’t have to build custom storage or data collection mechanisms.

5. Flexibility Across Workflows

Map-Reduce isn’t the only pattern supported. By combining nodes, edges, state, and Send(), you can implement complex, parallel workflows beyond traditional Map-Reduce, all within the same graph structure.

Tips & Best Practices

To get the most out of Map-Reduce workflows in LangGraph with Send(), keep these tips in mind:

1. Use Send() for True Parallelism

Only use Send() when tasks can run independently. Sequential tasks don’t benefit from parallel execution and may introduce unnecessary complexity.

2. Manage Large Intermediate States Carefully

If your map nodes produce a lot of intermediate data, consider splitting it across multiple reducer nodes or using streaming techniques to prevent memory overload.

3. Handle Errors Gracefully

Parallel execution means one failing node shouldn’t crash the entire workflow. Implement error handling or retries within nodes to make your pipeline robust.

4. Keep Nodes Focused

Each node should perform a single, well-defined task. This makes debugging easier and allows Send() to scale effectively.

5. Plan Your Edges

Edges determine how data moves from mappers to reducers. Keep the data flow clear and organized to avoid bottlenecks or unnecessary complexity.

6. Reuse Nodes When Possible

If multiple workflows share similar tasks, reuse nodes to reduce duplication and maintain consistency across your graphs.

Map-Reduce is a powerful pattern for processing large datasets, and LangGraph makes it simpler, cleaner, and faster. By combining nodes, edges, state, and the Send() API, you can build parallel workflows without the usual headaches of manual coordination or threading.

With nodes acting as mappers, edges guiding data flow, state holding intermediate results, and Send() enabling true parallel execution, LangGraph turns complex data processing into a manageable, scalable, and maintainable graph.

If you’ve followed along, you now know how to implement a Map-Reduce workflow—from mapping individual tasks to reducing aggregated results—while leveraging LangGraph’s parallelism capabilities.

A Beginner’s Guide to Understanding the Runtime Context in LangGraph

Damilola Oyedunmade — Mon, 08 Dec 2025 07:13:11 +0000

Building agentic workflows sounds simple until you try to keep everything straight. Data jumps from one step to another. Tools fire at different times. Logic branches. Memory shifts. Before long, you find yourself juggling state by hand, passing oversized payloads between nodes, and trying to keep the whole thing from collapsing under its own weight.

This is the core problem LangGraph set out to fix.

Before we dive in, here’s something you’ll love:

Learn LangChain in a clear, concise, and practical way.

Whether you’re just starting out or already building, LangCasts offers guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

The Runtime Context gives every part of the graph a shared, reliable place to read from and write to. Instead of pushing state through every node like a relay baton, each node taps into a common workspace. It can check what has happened so far, update what needs to change, and move on without breaking the flow.

In practice, this removes a huge amount of friction. You are no longer wiring state across dozens of transitions or guarding against missing values. The graph becomes easier to reason about. Nodes behave like pieces of one system rather than scattered functions stitched together by duct tape.

How the Runtime Context Flows Through a Graph

A LangGraph workflow runs step by step, but the Runtime Context travels with every node. Each node receives the same shared context. It is static, consistent, and read-only. Nothing inside it changes during a run. Nodes only read from it.

Alongside it sits the Graph State, which is the opposite. It is dynamic and mutable. Nodes read it, modify it, and hand the updated version forward. This is how the graph keeps track of evolving data like model outputs, tool results, and decisions.

Here is the core distinction:

Feature	Runtime Context	Graph State
Purpose	Static dependencies needed for execution	Live memory of the workflow
Mutability	Read-only	Read/write
Examples	user_id, API keys, DB connections, configs	messages, intermediate results, flags, outputs
Lifecycle	Set once at invocation	Updated continuously across nodes

This split keeps the workflow predictable. Runtime Context gives nodes stable information they can trust. Graph State holds everything that changes.

The flow is straightforward.

A node runs. It reads from the Runtime Context and the current Graph State. It performs its job. It updates only the Graph State. Then the graph routes to the next node based on that updated state. The Runtime Context stays untouched throughout.

Because of this separation, your workflow avoids the usual mess of passing dependencies manually, mixing secrets with state, or polluting memory with data that never changes. The graph stays easier to reason about, easier to test, and safer in multi-tenant environments.

Key Features of the Runtime Context

The Runtime Context is more than a bucket of variables. It gives your graph a structured environment to work in, with a few core features that make complex workflows manageable.

Shared State

Every node works from the same state. You can store user input, model outputs, intermediate decisions, or anything the workflow needs later. Because the state is shared, you avoid awkward data plumbing and inconsistent copies.

Memory Access

The context connects directly to whatever memory system you attach to the graph. Nodes can read long term facts, update short term memory, or store conversation history without extra wiring. This is what lets agents feel consistent across turns.

Environmental Data

You can store configuration details, request metadata, external settings, or execution flags. Instead of scattering these across your code, you keep them in one place where the whole graph can reach them.

IO Channels

The context gives nodes a simple way to emit messages, tool calls, or control signals. This keeps communication orderly inside the graph, avoids cross-talk, and helps nodes coordinate cleanly without hidden side effects.

Hooks and Middleware

Because everything passes through the context, you can attach hooks to inspect, modify, or log state at different moments in a run. This is valuable when you want guardrails, analytics, or debugging visibility without touching every node.

Using Runtime Context in Your Own Graph

Runtime Context gives each node access to the static data it needs without cluttering the mutable Graph State. You pass these values in at run time, and every node can read them directly.

Passing Custom Data Into the Graph

When invoking a graph, you inject static dependencies through the context argument. These values stay fixed for the entire run.

runtime_context = {
    "user_id": "abc123",
    "api_key": "sk-xyz",
    "db": make_db_connection()
}

graph.invoke(
    input={"message": "Hello"},
    context=runtime_context
)

This keeps sensitive or unchanging data out of your state, which is critical for clean execution and safe multi-tenant setups.

Accessing Runtime Context Inside a Node

Inside a node, you read static values through runtime.context. You never modify them.

def lookup_user(runtime, state):
    user_id = runtime.context["user_id"]
    db = runtime.context["db"]

    profile = db.fetch_profile(user_id)
    state["profile"] = profile
    return state

The node pulls what it needs, performs its work, updates the Graph State, and moves on.

Runtime Context stays untouched.

Visual Diagram

                     ┌───────────────────────────┐
                     │      Runtime Context       │
                     │  (user_id, api_key, db)    │
                     │  static • read-only        │
                     └───────────────┬───────────┘
                                     │
                                     ▼
                         ┌────────────────────┐
                         │       Node A       │
                         │ reads context      │
                         │ updates state      │
                         └─────────┬──────────┘
                                   │
                                   ▼
                         ┌────────────────────┐
                         │       Node B       │
                         │ reads context      │
                         │ updates state      │
                         └────────────────────┘

              Graph State (grows and changes across nodes)

Why Use This Pattern

Keeping dependencies in Runtime Context does three things:

Keeps Graph State focused on values that actually change.
Makes nodes easier to test because you can inject fake runtime dependencies.
Prevents leaks when running multiple tenants on the same graph.

Each node becomes predictable. You know exactly what can change and what cannot.

Practical Use Cases

The Runtime Context earns its keep when workflows go beyond simple linear steps. It gives your graph enough awareness to act intelligently, recover gracefully, and keep conversations coherent.

Multi Step Reasoning

Reasoning chains work best when each step can see what came before. The context holds intermediate conclusions, scratch work, and decisions so later nodes don’t start from zero. This lets you build deeper, more dependable logic without manual state passing.

Conversational Agents with Memory

A good agent needs more than the last message. It needs history, facts, preferences, and anything the user shared earlier. The context surfaces all of that directly. Nodes don’t hunt through external stores or long prompts. They read from a single place and update memory in a controlled way.

Tool Orchestration

Tool use quickly becomes messy if you juggle inputs and outputs by hand. With the context, tools feed their results straight into the shared state. Downstream nodes instantly get the updated information, which keeps chains tight and predictable.

Branching Based on State

Graphs often need to change direction. Maybe a tool failed. Maybe the user asked something new. Maybe a policy guardrail triggered. Nodes can inspect the context, set a routing flag, and let the graph decide the next step. No tangled if-else sprawl.

Error Handling and Recovery

When something breaks, the context holds enough information to recover. You can retry a node, fall back to a safer path, or log exactly what went wrong without losing the thread of the run. This makes complex graphs far more resilient.

Best Practices

A workflow is only as clean as the way it handles state. LangGraph makes this easier, but you still need discipline. These best practices keep your graphs predictable, safe, and simple to maintain.

Keep Static Dependencies in Runtime Context, Not Graph State

Static values like user_id, API keys, database handles, configuration flags, or service clients belong in Runtime Context. They do not belong in Graph State.

Why this matters:

Problem if stored in Graph State	Why it hurts
Static data becomes mutable	Harder to debug and reason about
State grows with every step	Slows down execution and inflates logs
Test runs require fake state setup	More boilerplate, less flexibility
Multi-tenant leakage risk	One user’s secrets can bleed into another run

Runtime Context solves all of this by giving each run a sealed, isolated environment for dependencies.

Update Only What Your Node Owns

Nodes should modify their own slice of state, nothing else. This avoids hidden interactions and makes each node’s behaviour easy to trace.

Good:

state["summary"] = summary

Bad:

state.clear()
state.update(random_mix_of_keys)

Keep State Focused

Graph State should hold just the values that change as the workflow progresses: results, messages, flags, and intermediate outputs. Everything else belongs elsewhere.

A light state is easier to debug and easier to replay.

Validate Before Writing

Never trust a model or tool blindly. Check the data. If it’s malformed, fix it or stop it.

if not isinstance(result, dict):
    raise ValueError("Invalid tool output")

Small guards prevent long debugging sessions later.

Document Keys as You Build

A short comment or a shared schema goes a long way. If your state has five or ten fields, define what they mean and which node owns them. Your future self will thank you.

A solid workflow depends on clear boundaries. LangGraph’s Runtime Context gives you exactly that. Static, reliable data stays in one place. Dynamic, evolving state lives in another. Once you follow this split, graphs become easier to build, easier to test, and far safer to run in real environments.

You spend less time managing state and more time shaping behavior. Nodes stay focused. Debugging gets simpler. Multi tenant setups become straightforward instead of stressful. Most importantly, the graph feels like a single system rather than scattered pieces taped together.

If you keep your dependencies in Runtime Context and let Graph State track the story of each run, everything else falls into place.

A Beginner’s Guide to Getting Started on Edges in LangGraph

Damilola Oyedunmade — Mon, 01 Dec 2025 02:35:08 +0000

If you’ve been following this LangGraph series, you already know we’ve covered a lot of ground: nodes, state, reducers, graph messages, MCP, and most recently, getting started with nodes.

Now it’s time to talk about the part that actually makes your graph move: Edges.

Before we dive in, here’s something you’ll love:
Learn LangChain in a clear, concise, and practical way.
Whether you’re just starting out or already building, Langcasts offers guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

Think of it this way: Nodes are the rooms in your workflow, each room has its own job.

But how do you move from one room to the next?

How does LangGraph know which step should come after “validate_user” or “ask_llm”?

Edges.

Edges are the connectors, the “doors,” the “next step,” the “go here after this” instructions that give your graph direction and rhythm. Without edges, your nodes just sit there… smart, but useless.

Why should you care?

Because edges turn your static setup into a dynamic, intelligent pipeline.

They define:

The execution flow
The order of operations
The branches (this way if X, that way if Y)
The logic behind your decisions

Edges are where your workflow stops being linear code and becomes a flexible graph.

The Role of Edges in LangGraph

In LangGraph, edges play two major roles:

1. Edges Control Execution Flow

When one node finishes running, LangGraph needs to know:

“Okay… where do we go now?”

Edges answer that question.

They determine:

The next node to run
The order in which nodes fire
Whether the graph moves forward, loops, or jumps to a new branch

2. Edges Allow Smart Decisions (Branching)

Edges are not just straight lines, they can be conditional.

Meaning:

You can tell LangGraph:

“If the state looks like this, go to Node A.

But if it looks like that, go to Node B.”

This is how you build multi-step assistants, error-handling flows, approval or rejection paths, “If user says X → answer Y” logic and even Complex agent behaviours that still feel simple and natural

Creating Your First Edge (The Basic Flow)

Now that you understand what edges do, let’s actually create one.

This is the moment your graph stops being a collection of lonely nodes and starts behaving like a real workflow.

Step 1: Define Two Nodes

Let’s assume we have two tiny nodes:

def greet(state):
    return {"message": "Hello from Node A!"}

def reply(state):
    return {"message": "We moved to Node B!"}

These nodes don’t mean much yet, they’re just two disconnected rooms.

Let’s connect them.

Step 2: Set an Entry Point

Every graph needs a starting point. This is where the execution begins.

builder.set_entry_point("greet")

This tells LangGraph:

“Start the workflow at the greet node.”

Step 3: Add a Normal Edge (Node A → Node B)

Here’s the magic line:

builder.add_edge("greet", "reply")

That’s it.

You’ve just created your first flow:

greet  ───▶  reply

When greet finishes running, LangGraph will automatically jump to reply.

Why This Matters

This tiny step unlocks everything else you’ll build.

With a single edge, you’ve defined a sequence, a direction, a storyline.

From here, you can:

Extend your chain
Add multiple branches
Insert conditionals
Loop backward
Build multi-step assistants.

Next up: let’s talk about the fun part — conditional edges, where things get smarter and more dynamic.

Conditional Edges

This is where LangGraph stops being a linear pipeline and starts behaving like a decision-maker — choosing different next steps depending on what's happening in the state.

LangGraph evaluates your state after a node runs and routes the flow accordingly.

It’s the same way you make decisions:

If the user said “yes,” continue the process
If they said “no,” return an error
If the data is incomplete, ask for clarification
If the model is confused, send outputs to a fallback node

Conditional edges are the branching logic of your graph.

How to Add a Conditional Edge

You use this method:

builder.add_conditional_edges(
    "node_name",
    condition_function,
    {
        "condition_value_1": "next_node_1",
        "condition_value_2": "next_node_2",
    }
)

Let’s make that real.

Example: Yes or No Routing

Step 1: Write a node that updates state

def ask_user(state):
    # maybe this came from an LLM or user input
    return {"answer": state["answer"]}

Step 2: Write a condition function

The function receives the current state and returns a label.

def check_answer(state):
    if state["answer"].lower() == "yes":
        return "go_ahead"
    return "stop"

Step 3: Add the conditional edges

builder.add_conditional_edges(
    "ask_user",
    check_answer,
    {
        "go_ahead": "proceed_node",
        "stop": "exit_node",
    }
)

Now your flow looks like this:

                ───▶ proceed_node
ask_user ───┤
                ───▶ exit_node

Why Conditional Edges Matter

They help you build:

Smart assistants
Decision trees
Error handling flows
Multi-path LLM reasoning
Tool-based routing
Real-world applications where one answer never fits all.

Next up: you’ll see how edges look visually and why graph visualization is your best friend when debugging.

Visualizing Edges

Now that you know how to connect nodes with edges — both normal and conditional — it’s time to actually see what your graph looks like.

Because here’s the truth:

Visualizing your graph is the fastest way to understand, debug, and trust your workflow.

LangGraph gives you a built-in way to do this, and it’s super beginner-friendly.

Why Visualization Matters

When you visualize your graph, you can instantly spot:

Your entry point
All node connections
Branching paths
Loops
Missing edges
Incorrect routing
Accidental “dead ends”

Instead of guessing how your graph flows, you can literally see its structure.

Perfect for beginners. Perfect for debugging.

How to Visualize Your Graph

After defining your nodes + edges, just call:

graph = builder.compile()
graph.display()

Hit graph.display(), and LangGraph will render a clean diagram showing:

greet ───▶ reply
           │
           └──▶ fallback (if conditional)

Conditional paths are especially clear — you’ll see branches labeled with the condition values your function returns.

A Quick Example Diagram

Here’s a simple mental model of what you’ll see:

          [ ask_user ]
                │
     ┌──────────┴──────────┐
     ▼                     ▼
[ proceed_node ]     [ exit_node ]

It’s readable, friendly, and instantly shows how your edges direct the flow.

This one move — calling graph.display() — saves hours of confusion.

Common Edge Patterns You’ll Use Every Day

Edges in LangGraph are the rules that shape how your agent thinks and moves. As you start building real apps, you’ll find that a few edge patterns show up over and over again:

1. Linear Edges (Straight-Line Flow)

This is the “do A, then B, then C” pattern.

Perfect for simple pipelines like: parse → validate → respond.

2. Conditional Edges (Decision-Making Flow)

Edges choose the next node based on some condition.

Example:

If the user asks a weather question → go to WeatherNode.

Otherwise → go to DefaultNode.

3. Looping Edges (Iterative Flow)

These edges send the graph back to the same node.

Useful for:

retrying a failed step
gathering more user input
iterative refinement (e.g., rewriting until satisfied)

4. Termination Edges (End the Flow)

Some edges simply stop the execution.

Great for:

finishing a response
returning a final value
clean agent shutdown

5. Tool-Driven Edges (Flow Depends on Tool Output)

Sometimes a tool's result determines the next step.

Example:

If the API returns “not found” → go to ErrorNode.

Otherwise → continue to ProcessNode.

These patterns form the backbone of almost every LangGraph app, and once you spot them, you’ll begin to design graphs more intentionally.

How to Add Edges in LangGraph (Plus a Full Working Example)

Edges are how you tell LangGraph what should happen next. Adding them is simple, you connect one node to another, and LangGraph takes care of the flow.

Here’s the basic pattern:

graph.add_edge("node_a", "node_b")

This means:

After node_a runs → go to node_b.

Need decisions instead of straight lines? Use conditional edges:

graph.add_conditional_edges(
    "router_node",
    {
        "weather": "WeatherNode",
        "news": "NewsNode",
        "fallback": "FallbackNode"
    }
)

Want the graph to stop? Point to END:

from langgraph.constants import END
graph.add_edge("final_node", END)

Now let’s put this into a full, runnable example so you can see edges in action:

from langgraph.graph import StateGraph, END

def user_input(state):
    return {"text": "Hello from the user!"}

def process(state):
    text = state["text"]
    return {"processed": text.upper()}

def finish(state):
    print("Final Output:", state["processed"])
    return {}

graph = StateGraph()

graph.add_node("UserInput", user_input)
graph.add_node("Process", process)
graph.add_node("Finish", finish)

# Connect everything
graph.add_edge("UserInput", "Process")
graph.add_edge("Process", "Finish")
graph.add_edge("Finish", END)

app = graph.compile()
app.invoke({})

This tiny graph flows cleanly:

UserInput → Process → Finish → END

Nothing fancy, just nodes doing their jobs, and edges telling LangGraph how to move from one step to the next.

This is the heart of edges: simple rules that shape your entire agent flow.

Nodes may be the “brains” of your LangGraph app, but edges are the glue, the direction, and the heartbeat of your agent’s flow. They tell your system what happens next, shaping raw logic into a smooth, functional pipeline.

With just a few lines of code, edges let you:

build linear flows
branch into decisions
create loops and retries
terminate cleanly
design complex agent behavior with simplicity

And the best part?

Once you understand edges, your graphs stop being random blocks of code and start becoming clear stories your agent can follow.

You’ve already explored nodes, reducers, state, and messages in previous parts of your LangGraph series, and now with edges in your toolkit, you’re equipped to build real, flexible, intelligent agent flows.

Go on and experiment. Connect a few nodes. Visualize your graph.

Soon, you’ll be designing flows that feel effortless.

Onward to the next part of the series. You’re getting really good at this.

A Beginner’s Guide to Getting Started with Nodes in LangGraph

Damilola Oyedunmade — Mon, 24 Nov 2025 15:39:02 +0000

If you’ve been following our LangGraph series so far, where we’ve toured the basics of LangGraph, peeked into agent state, reducers, add_reducers, graph messages, and even discussed MCP in LangGraph—you’re probably starting to see a pattern:

Everything in LangGraph feels modular… almost like LEGO blocks.

Well, today we finally meet the LEGO block itself: the Node.

Before we dive in, here’s something you’ll love:

Learn LangChain in a clear, concise, and practical way.
Whether you’re just starting out or already building, Langcasts gives you guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

Think of nodes as the tiny brains of your graph. Each node is a single step, a decision point, a task, a “do-this-next” moment in your workflow. They just do one job really cleanly, and then pass the baton.

Whether you’re building a simple two-step agent, a multi-branching “choose-your-own-adventure” assistant, or a full-blown workflow that feels like it should have a boarding pass…

Nodes are the building blocks that make your agent predictable, traceable, and honestly… sane.

But here’s the best part: Once you understand what nodes are and how they behave, the rest of your LangGraph journey becomes way clearer.

By the end of this guide, you’ll be able to:

spot a node in the wild,
create your own nodes (yes, you),
chain them together like a pro,
and build simple flows that actually make sense.

What Exactly Is a Node in LangGraph?

A node is just a function or an LLM call that transforms your state and moves your graph forward.

Let’s break that down.

Nodes vs Edges vs State

Node → *Where something happens*

A function runs. An LLM thinks. A check is made.

This is the action.
Edge → *How you move to the next thing*

It’s the arrow that says:

“After this… go there.”
State → *The backpack your agent carries around*

Everything your workflow needs to remember — user messages, results, flags, decisions, whatever.

Each node can update this backpack or use what’s already inside.

If you've read the earlier guide on agent state then you already know how state behaves. Nodes are simply the actors that read the state, use it, update it, and pass it along.

So What Makes LangGraph Nodes Special?

Well… they’re predictable.

Every node knows:

What comes in (state).
What it’s supposed to do (your logic).
What comes out (updated state).
Where to go next (edges).

This makes your workflow easier to debug, visualize, maintain, and way easier to extend as your agents get smarter.

Types of Nodes You’ll Encounter

Now that you know what a node is, let’s talk about the different types you’ll meet in LangGraph.

1. Callable Nodes (a.k.a. Your Normal Functions)

These are the simplest, most predictable nodes.

A callable node is basically:

“Hey LangGraph, when the workflow gets here, run this function.”

It could be formatting a message, fetching data, doing a calculation, or updating state in a very specific way.

Use these when:

You want clear, deterministic logic.

2. Agent Nodes (LLM Nodes)

These are the “thinkers” in your workflow — the nodes where the LLM gets to reason, respond, or decide what happens next.

Think of an LLM node as:

“You handle the thinking; I’ll handle the routing.”

An agent node usually:

reads the current state (like messages),
calls the LLM,
returns the next message/state update.

If you’ve read my earlier article on graph messages, this is where that knowledge becomes super useful. LLM nodes depend heavily on message formatting and understanding how messages flow through the graph.

Use these when:

You want natural language reasoning or model-based decisions.

3. Conditional Nodes (Branching Logic)

These nodes decide which next node to jump to based on the state.

Imagine you're building a customer support bot. The conditional node might ask:

“Is the user asking about billing?” → go to billing flow
“Is the user asking about refunds?” → go to refund flow
“Is the user confused?” → send a human-friendly clarification node

These nodes make your workflow smart — not everything has to be linear.

Use these when:

Your agent needs to choose between multiple paths.

4. Parallel Nodes (Fan-Out / Fan-In)

These are the “multitaskers”. They allow you to split your workflow into multiple branches that run side by side before merging the results.

For example, they can help you

Analyze text
Fetch related documents
Generate summaries
…and then combine everything

Think of parallel nodes as LangGraph saying:

“Why do this one by one when we can do them all at once?”

Use these when:

You want speed, efficiency, or multiple data sources combined.

A Quick Recap (Like a Cheat Sheet)

Node Type	What It Does	When to Use
Callable	Runs a normal Python function	Pure logic, utilities, transforms
Agent / LLM	Lets the model think or respond	Reasoning, writing, decisions
Conditional	Branches workflow based on state	Routing, decision trees
Parallel	Runs multiple branches at once	Multi-source workflows, speed

Once you understand the role of each, designing robust workflows becomes a breeze.

The Anatomy of a Node

Before we start creating nodes and connecting them, let’s zoom in and look at what actually makes up a node.

A node in LangGraph is made of three core ingredients:

Input (State Coming In)
Logic (What the node does)
Output (State Going Out)

…and then a little “map” that tells LangGraph where to go next.

Let’s break that down.

1. Input: What the Node Receives

Every time your workflow enters a node, LangGraph passes in the current state. It holds:

user messages,
previous results,
flags,
memory,
whatever your agent needs to make decisions.

A node doesn’t need to use everything; it just pulls out the item(s) it cares about.

Think of it like opening your fridge — you're not using all the food, you’re just grabbing what you need for this step.

2. Logic: The Heart of the Node

The logic is the function, LLM call, or branching rule that defines what the node actually does. This could be, calling OpenAI or Anthropic, looking something up, updating messages, deciding which route to take, or merging results.

This logic is the “why” of the node — its purpose.

If you read my earlier pieces on reducers and state updates, you’ll notice that node logic often results in new data being produced, which your reducers then merge into the global state.

3. Output: What the Node Produces

After the logic runs, the node spits out something new — usually part of the state. LangGraph takes this result, merges it into the state (thanks to reducers), and carries the updated backpack forward to the next node.

4. Edges: The Next Step

This is the part beginners often overlook.

A node doesn’t live alone in the void — it needs edges to tell LangGraph:

Where to go next?
Which node should follow this one?
Is this a normal transition or a conditional one?
Are we branching or looping?

Think of edges as the arrows in a flowchart.

Without edges, even the smartest node has nowhere to send its results.

Nodes do the work, Edges define the journey.

Simple Diagram Showing How a Node Works in LangGraph

           ┌─────────────────────────┐
           │        STATE IN          │
           │   (Your agent's memory)  │
           └─────────────┬───────────┘
                         │
                         ▼
               ┌───────────────────┐
               │      NODE         │
               │  (One Step/Task)  │
               │                   │
               │ • Reads State     │
               │ • Runs Logic      │
               │ • Produces Output │
               └───────────┬───────┘
                           │
                           ▼
           ┌─────────────────────────┐
           │       STATE OUT         │
           │ (Updated by Reducers)   │
           └─────────────┬───────────┘
                         │
                         ▼
                ┌─────────────────┐
                │     NEXT NODE   │
                └─────────────────┘

And once you understand this anatomy, designing workflows becomes almost addictive.

Creating and Connecting Your First Nodes

Now that you understand what nodes are, it’s time to actually build them — and then connect them to create a real workflow.

Let’s walk through it step by step.

Step 1: Start With a Simple Function

Every node begins life as a small Python function.

def greet(state):
    name = state["name"]
    return {"message": f"Hello, {name}! Welcome to LangGraph."}

This function:

reads something from state
returns something new

Step 2: Turn That Function Into a Node

Next, we register it inside a graph:

from langgraph.graph import Graph

graph = Graph()
graph.add_node("greet_node", greet)

You now have your first node

LangGraph knows: “When the workflow hits greet_node, run the greet function.”

Step 3: Add Another Node (Optional)

Let’s add a second node that transforms the output:

def shout(state):
    message = state["message"]
    return {"shouted": message.upper()}

graph.add_node("shout_node", shout)

Step 4: Connect the Nodes Together

Nodes aren’t useful in isolation, they’re meant to flow.

Connecting them is just:

graph.add_edge("greet_node", "shout_node")

Now your workflow looks like:

[greet_node] → [shout_node]

LangGraph now understands:

“After greeting, jump to shouting.”

This is called a linear workflow, and it’s the foundation of everything else you’ll build.

Step 5: Run Your Mini-Workflow

Let’s try it out:

input_state = {"name": "Dami"}

result = graph.run(input_state)
print(result)

Sample output:

{
  "name": "Dami",
  "message": "Hello, Dami! Welcome to LangGraph.",
  "shouted": "HELLO, DAMI! WELCOME TO LANGGRAPH."
}

Congratulations — you just built a functioning LangGraph pipeline.

Connecting Nodes in Interesting Ways

Linear flows are great, but LangGraph becomes powerful when you start using different connection patterns. Let’s explore the essentials.

1. Linear Chains (The Classic Flow)

A → B → C → D

graph.add_edge("start", "format_node")
graph.add_edge("format_node", "llm_node")
graph.add_edge("llm_node", "save_node")
graph.add_edge("save_node", "end")

Perfect for simple pipelines.

2. Conditional Routing (Decision-Based Workflow)

Let’s say your agent detects user intent:

                   billing_flow
                 ↗
[intent_node] —──┤
                 ↘
                   refund_flow

In code:

graph.add_conditional_edges(
    "intent_node",
    {
        "billing": "billing_flow",
        "refund": "refund_flow",
        "other": "fallback_node",
    }
)

One node → multiple possible next steps.

3. Loops (Repeating a Step Until Ready)

Yes, you can loop:

graph.add_edge("refine_node", "refine_node")

Loops are super useful for:

LLM refinement
multi-turn reasoning
repeated checking

4. Parallel Branching (Fan-Out + Merge)

Split work into multiple paths:

             ┌──→ branch_A
start_node ──┤
             └──→ branch_B

And merge later:

branch_A
        ↘
         merge_node
        ↗
branch_B

Code:

graph.add_edge("start_node", "branch_A")
graph.add_edge("start_node", "branch_B")

graph.add_edge("branch_A", "merge_node")
graph.add_edge("branch_B", "merge_node")

Perfect for tasks that can run simultaneously.

Why This Matters

Once you know how to create and connect nodes, you unlock the ability to design:

chatbots with reasoning flows
structured workflows
agentic pipelines
tool-calling systems
data processing chains
multi-agent multi-step applications
anything that benefits from clarity and controlled execution

LangGraph doesn’t force you into one pattern, it hands you LEGO blocks and says: Build whatever you want — cleanly.

Running and Visualizing Your Node Chain

You’ve built your nodes. You’ve connected them. Now it’s time for the part everyone loves: running the graph and actually seeing how everything flows.

1. Running the Graph (The “Just Hit Play” Moment)

Once your graph is compiled, running it is as easy as:

runnable = graph.compile()

result = runnable.invoke({"name": "Dami"})
print(result)

Under the hood, LangGraph walks your flow step-by-step, updates the state after each node, and hands you the final result.

If you’ve chained multiple nodes, you’ll see all the accumulated state:

{
  "validated": True,
  "message": "Hello Dami! Welcome to LangGraph 🎉"
}

2. Visualizing Your Graph (Your Workflow, but as a Map)

LangGraph comes with built-in visualization, which is perfect when your graph starts growing beyond a few nodes.

Just call:

graph.display()

You’ll get a neat diagram showing:

Each node in your flow
How they connect
The direction of execution

It’s like going from “I hope this works” to “Ah, now I see how everything fits.”

3. Why Visualization Matters (Especially for Beginners)

When you’re new to LangGraph, diagrams help you:

Spot mistakes early (hello, missing edges 👀)
Understand your flow at a glance
Explain your graph to teammates—or future you
Keep your mental model tight as the workflow grows

LangGraph’s visualization is especially helpful once you start mixing:

Conditionals
Tool nodes
LLM calls
Multiple branching paths

But even with a simple 2–3 node chain, seeing it makes a world of difference.

Wrapping Up: You’ve Just Built Your First LangGraph Node Flow

And that’s a solid win.

You came in knowing nodes were “a thing in LangGraph,” and you’re leaving with an understanding of what they are, how to create them, how to chain them, and how to visualize your workflow. That’s the core of almost every LangGraph project—whether you’re building a simple helper bot or a multi-agent system with branching logic and tools flying everywhere.

At this point in the LangGraph series, you should be feeling more confident about the building blocks:

State (covered earlier in the series)
Reducers (your quiet state-updating heroes)
Messages & MCP (communication superpowers)
And now—Nodes (the actions that make everything move)

Together, they form the foundation for more advanced patterns we’ll explore next.

If this clicked for you, amazing.

If it sparked new ideas, even better.

Keep experimenting, keep connecting nodes, and keep building smarter graphs.

Your next workflow is just a node away.

A Beginner’s Guide to Using MCP with LangGraph

Damilola Oyedunmade — Sun, 16 Nov 2025 23:28:22 +0000

If you’ve been following along with the LangGraph series, you already know how powerful structured, stateful workflows can be for building real AI agents. But there’s one question every developer eventually runs into:

“How do I let my agent interact with real-world tools and data?”

That’s where MCP — Model Context Protocol — steps in.

Before we dive in, here’s something you’ll love:

Learn LangChain in a clear, concise, and practical way.
Whether you’re just starting out or already building, Langcasts gives you guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

MCP is a new open standard that gives AI models a clean, safe, predictable way to access external tools, APIs, files, and more. Instead of writing custom integrations for every single tool, MCP gives you one universal format that everything can plug into.

And here’s the best part:
LangGraph supports MCP natively.
This means your graph nodes can call MCP tools as easily as they call other functions.

In this guide, we’ll walk through the basics of MCP inside LangGraph.
We’ll keep things simple.
We’ll build something small.
And by the end, you’ll understand how to use MCP to make your LangGraph agents more capable, more useful, and much more practical.
Ready? Let’s get into it.

Core Concepts You Need to Know

Before wiring LangGraph and MCP together, there are a few core ideas you need to understand.

1. Graphs

A graph in LangGraph is simply the map your agent follows.

It defines how your agent moves from one step to the next, similar to a workflow, but more intelligent.

2. Nodes

Nodes are the “stations” in your graph.

Each node does one thing:

Call an LLM
Perform logic
Trigger a tool
Transform state

If the graph is the map, nodes are the stops on the journey.

3. State

State is your agent’s memory.

It carries everything from messages to tool results to custom variables.

In LangGraph, state updates automatically flow from node to node, so every part of your agent always sees the latest context.

4. Actions

Actions are how nodes do things.

They’re the outputs that tell LangGraph what happens next, like: “Call this tool”, “Move to that node”, “Update the state”.

5. MCP Tools

MCP tools are capabilities your agent can use, defined outside your code in a separate MCP server.

These tools come with:

Structured schemas
Validated inputs
Typed responses
Secure execution rules

You expose tools, MCP handles the plumbing, and LangGraph uses them cleanly.

6. How LangGraph treats MCP tools as callable actions

When a LangGraph node wants to use an MCP tool, it doesn’t “guess” what to do.

It returns a tool invocation action, and LangGraph knows exactly how to route that call through MCP.

Your node just says:

“Please call this tool with this data.”

LangGraph and MCP handle everything else.

7. How MCP fits into the graph execution model

Here’s the smooth relationship:

LangGraph runs your workflow step-by-step.
When a node needs external capabilities, it triggers an MCP tool action.
MCP executes the tool and returns structured data.
LangGraph folds that result back into the state and continues the graph. ## Setting Up Your First MCP Environment

Before LangGraph can call MCP tools, you need an MCP environment running.

1. Install the MCP CLI

You’ll need the official MCP command-line tool to run and test your MCP servers locally.

npm install -g @modelcontextprotocol/cli

This gives you the mcp command, which you’ll use to run your tools.

2. Create a Simple MCP Server

An MCP server is just a small program that exposes tools.

You can start with the basic template:

mcp init my-mcp-server

This generates a folder with:

A sample tool
JSON schema files
Server boilerplate
A clean structure to build on

Open the folder and you’ll already see how tools are defined and validated.

3. Start Your MCP Server

Run the development server:

mcp dev

When this starts successfully, your MCP environment is live.

You’ll see logs showing:

Available tools
Their schemas
When the server receives calls

This is where LangGraph will eventually connect.

4. Add Your First Tool (Optional for Now)

Tools in MCP are just functions wrapped with:

Input schema (what data they accept)
Output schema (what they return)
Execution logic

For example, a simple “get-time” tool might look like:

{
  "name": "get_time",
  "inputSchema": {},
  "outputSchema": {
    "type": "object",
    "properties": {
      "iso": { "type": "string" }
    }
  }
}

You’ll later reference these tools by name inside LangGraph.

5. Connect LangGraph to Your MCP Server

Once your MCP server is running, LangGraph can connect by simply pointing to it in your graph configuration:

from langgraph.mcp import MCPClient

mcp = MCPClient("http://localhost:3000")

Boom, now your agent can call any tool served by MCP.

Writing Your First LangGraph Node That Calls an MCP Tool

Now that your MCP server is up and running, let’s hook it into LangGraph. This is the moment where your agent stops “talking about things” and starts doing things.

We’ll walk through a simple example: calling an MCP tool from a LangGraph node and feeding the result back into the state.

1. Import the Essentials

You only need a few LangGraph and MCP utilities:

from langgraph.graph import StateGraph
from langgraph.mcp import MCPClient, mcp_tool
from langgraph.prebuilt import MessagesState

2. Connect Your LangGraph Project to MCP

Create a client pointing to your running MCP server:

mcp = MCPClient("http://localhost:3000")

This gives your graph access to every tool the server exposes.

3. Wrap an MCP Tool for LangGraph

Let’s say your MCP server exposes a tool called "get_time".

You make it callable inside LangGraph like this:

get_time = mcp_tool(mcp, "get_time")

get_time is now a tool action you can call inside any node.

4. Write a Node That Calls the Tool

A node just needs to return a tool invocation action.

Here’s a minimal example:

def ask_for_time(state: MessagesState):
    return get_time({})

A few things are happening here:

The node receives the current state (messages, history, etc.)
It doesn’t need extra input for this tool, so we pass an empty dict
It returns an MCP tool call
LangGraph takes over from there

5. Consume the Tool Result in the Next Node

After the tool runs, MCP sends the response back to LangGraph.

So you create another node to process it:

def show_time(state: MessagesState):
    result = state["messages"][-1]["content"]
    return {"messages": [("assistant", f"The time is {result['iso']}")]}

This node reads the last message (the tool’s result) and formats it into a clean assistant reply.

6. Build the Graph

Now wire everything together:

graph = StateGraph(MessagesState)

graph.add_node("ask_for_time", ask_for_time)
graph.add_node("show_time", show_time)

graph.set_entry_point("ask_for_time")
graph.add_edge("ask_for_time", "show_time")

app = graph.compile()

7. Run It

app.invoke({"messages": [("user", "What time is it?")]})

Your LangGraph agent will:

Read the user’s message
Run the ask_for_time node
Trigger the "get_time" MCP tool
Get the structured result
Pass it into show_time
Respond with the actual time

You’ve just walked through the essentials of using MCP with LangGraph. From the core concepts, to wiring up tools, to building a real working agent. Even if the details felt new at first, you now understand the big picture: LangGraph handles the workflow, MCP handles the tools, and together they give your agent real capabilities without chaos or guesswork.

The best part?
You’ve barely scratched the surface.

Once you’re comfortable with simple tools like file readers or API calls, you can scale up to full workflows, multi-step reasoning, chained tools, or even entire application backends powered by MCP. LangGraph keeps everything structured. MCP keeps everything safe and predictable. The combination gives you a foundation you can build on confidently.

So take your time, experiment, break things, fix them, and keep going.
This is all part of the fun.

A Beginner’s Guide to Getting Started with Graph Messages in LangGraph

Damilola Oyedunmade — Fri, 07 Nov 2025 15:06:43 +0000

If you’ve been following this LangGraph series, you’ve already learned how to build agents, manage their state, and use reducers to control how data flows through your graph. We’ve laid a foundation. But there’s one piece we haven’t zoomed in on yet, the actual messages moving through your graph.

Think about it: when you build a chatbot or any conversational agent, what really travels between nodes? It’s not just text, it’s structured data, context, and intent wrapped up as messages. These messages are what keep your graph alive, what make your AI remember what was said before, and what let it respond intelligently the next time around.

This is where Graph Messages come in. They’re the glue that connects everything, the courier that carries meaning from one node to another, the thread that ties state and logic together. Without understanding Graph Messages, you’re only scratching the surface of what LangGraph can do.

Before we dive in, here’s something you’ll love:

Learn LangChain in a clear, concise, and practical way.

Whether you’re just starting out or already building, Langcasts gives you guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

In this guide, we’ll take a beginner-friendly look at how Graph Messages work inside LangGraph. You’ll see how they fit into the bigger picture you’ve already built in this series, and how mastering them will make your conversational agents smarter, more reliable, and a lot easier to reason about.

Ready to see how messages actually move through your LangGraph? Let’s break it down.

The Core Concept — What Are Graph Messages?

Before we get into the code, let’s strip the concept down to its essence.

A Graph Message in LangGraph is simply how information moves between nodes in your graph. Each node in your LangGraph setup does something, maybe it generates text, analyzes sentiment, or calls an API. But nodes don’t exist in isolation. They need a way to talk to each other. That’s what messages are for.

It might contain:

The user’s input (HumanMessage)
The model’s response (AIMessage)
The current context or memory (ToolMessage)
Or any other info that your next node needs to do its job (SystemMessage)

In LangGraph, these messages aren’t just free-floating text strings; they’re typed objects that keep your workflow organized and predictable. Each message carries both content and metadata, so your graph knows what kind of data it’s handling and where it came from.

Here’s a simple mental model:

“Nodes process. Edges are the routes. Messages move.”

Why does this matter? Because when you start building more advanced graphs, like chatbots that remember past turns, the way you handle and store these messages determines how well your system holds context over time. Mismanage messages, and your agent forgets its own history. Handle them right, and you get smooth, intelligent, multi-turn conversations. Now that we seem to have got the hang of Messages in Graph State, let's set up our LangGraph.

Setting Up Your First LangGraph Project

Now that you’ve got a handle on what Graph Messages are, let’s get your hands dirty with a simple example.

Before we start, make sure you’ve got LangGraph installed. If not, just run:

pip install langgraph

LangGraph projects usually follow a simple pattern:

Define your state — this is the shared data that moves through the graph.
Create your nodes — each node is just a Python function that does something with that state.
Connect the nodes with edges — these determine how the workflow moves from one node to the next.
Compile and run your graph — this “wires” everything together so LangGraph can handle message passing behind the scenes.

Here’s the smallest possible working example to see message flow in action:

from typing_extensions import TypedDict
from langgraph.graph import StateGraph, START, END

# 1. Define the state
class GraphState(TypedDict):
    user_input: str
    response: str

# 2. Create nodes
def collect_input(state: GraphState):
    print("Node: collect_input")
    return {"user_input": "Hello, LangGraph!"}

def generate_response(state: GraphState):
    print("Node: generate_response")
    text = state["user_input"]
    return {"response": text + " Nice to meet you."}

# 3. Build and connect the graph
builder = StateGraph(GraphState)
builder.add_node("collect_input", collect_input)
builder.add_node("generate_response", generate_response)

builder.add_edge(START, "collect_input")
builder.add_edge("collect_input", "generate_response")
builder.add_edge("generate_response", END)

# 4. Compile and run
graph = builder.compile()
output = graph.invoke({})
print(output)

What’s happening here?

The collect_input node sends out a message containing the user_input.
That message travels along the edge to the generate_response node.
The generate_response node reads the incoming message, updates the response, and sends its message forward.
Once there are no more messages to deliver, the graph stops, and you get your result.

Even in this small demo, you can see how the data (or message) moves between nodes and evolves along the way.

Behind the scenes, LangGraph handles the message-passing logic automatically. You just define what each node should do and how they connect, and LangGraph does the rest.

Next, we’ll dive into how you can create and manage messages yourself, including how to store message history and keep your chatbot’s memory intact.

Creating and Passing Graph Messages

So far, we’ve seen messages move quietly behind the scenes, nodes sending and receiving state as the graph runs.

But when you’re building a chatbot or any agent that needs memory, you’ll often need to create, store, and manage those messages yourself.

That’s where LangGraph’s message system really shines.

Messages Are the Memory Backbone

Every turn in a conversation — user input, AI response, or system message — becomes part of the graph’s evolving state.

If you don’t manage those properly, your chatbot loses context with every new message.

LangGraph solves this neatly with two built-in tools:

add_messages reducer – for appending new messages to your state without overwriting old ones.
MessagesState helper class – a shortcut for setting up message storage in your graph automatically.

Using `MessagesState` — The Quick Way

If your project is all about managing chat history, the easiest path is to use MessagesState.

It sets up your graph state with a messages key and automatically configures the add_messages reducer for you.

Here’s a minimal example:

from langgraph.graph import StateGraph, START, END, MessagesState
from langgraph.reducers import add_messages

def chat_node(state: MessagesState):
    messages = state["messages"]
    last_message = messages[-1]["content"] if messages else "Hello!"
    reply = f"You said: {last_message}"
    return {"messages": [{"role": "assistant", "content": reply}]}

builder = StateGraph(MessagesState)
builder.add_node("chat", chat_node)
builder.add_edge(START, "chat")
builder.add_edge("chat", END)
graph = builder.compile()

result = graph.invoke({"messages": [{"role": "user", "content": "Hi!"}]})
print(result["messages"])

Here’s what’s going on:

The user sends a message — LangGraph wraps it as part of the graph’s state.
The node reads that message, builds a response, and returns a new message.
The add_messages reducer kicks in automatically, appending the new message to the conversation history.

Now your chatbot remembers previous messages — no custom memory logic, no manual state juggling.

When You Need Custom State

If you want to include extra fields (like user data or conversation mode), you can define your own state and annotate it with the add_messages reducer.

from typing_extensions import TypedDict
from langgraph.reducers import add_messages

class ChatState(TypedDict):
    messages: list
    user_id: str

ChatState = add_messages(ChatState)

This lets you mix chat history with other useful data, and still keep message updates automatic and reliable.

Debugging and Inspecting Messages

When your graph starts to grow beyond a few nodes, things can get fuzzy fast.

Messages fly around, reducers run quietly, and before you know it, your chatbot starts “forgetting” things or producing strange responses.

That’s your cue to inspect what’s actually happening inside your graph.

Fortunately, LangGraph gives you a few simple ways to peek inside and trace message flow step by step.

1. Printing Message State (the Quick Way)

The easiest way to understand what’s going on is to just print the state your nodes receive and return.

Here’s an example:

def chat_node(state: MessagesState):
    print("\n--- Incoming State ---")
    print(state)

    messages = state["messages"]
    last_message = messages[-1]["content"] if messages else "Hello!"
    reply = f"You said: {last_message}"

    print("\n--- Outgoing State ---")
    print({"messages": [{"role": "assistant", "content": reply}]})

    return {"messages": [{"role": "assistant", "content": reply}]}

This might feel basic, but when you’re just starting out, it’s often the most revealing approach.

You can literally watch your graph evolve message by message.

2. Using `graph.inspect()`

LangGraph includes a handy inspection feature that lets you run your graph interactively and see the flow between nodes.

graph.inspect({"messages": [{"role": "user", "content": "Hi!"}]})

This displays how your graph processes input, which nodes get activated, and how messages change as they pass through the system.

It’s a quick sanity check when your state isn’t updating the way you expect.

3. Common Gotchas and Fixes

Here are a few message-related bugs you’ll probably run into — and how to fix them fast:

Problem	Likely Cause	Quick Fix
Your chatbot “forgets” the conversation	You overwrote `messages` instead of appending	Use the `add_messages` reducer
Graph stops after one node	Missing edge or wrong node name	Double-check your edge definitions
Messages are duplicated	Returning full state instead of partial update	Return only the fields you changed
Node never runs	No incoming message	Make sure a previous node actually returns something

4. Verify Message Flow Early

When your graph is still small, trace message flow early and often.

Print your state, run inspect(), and verify that each node gets the right data.

Catching issues at this stage saves you from debugging a tangle of nodes later.

At the end of the day, debugging in LangGraph is about visibility.

If you can see how messages move, you can reason about your graph.

Once you understand your message flow, fixing bugs and scaling up become much simpler.

If you’ve been following this LangGraph series from the start, you’ve now connected all the dots, from agents to state to reducers.

But here’s the key takeaway: Graph Messages are the lifeblood of it all.

They’re what connect your nodes, carry your state, and bring your AI workflows to life.

LangGraph’s message-passing system, powered by the add_messages reducer and the MessagesState helper, gives you a simple way to manage complexity.

If you haven’t already, watch the YouTube demo to see messages in action, then try adding them to your next LangGraph project.

Ready to start your AI journey? Don’t wait — join a class at Langcasts.com and start building smarter today.

A Beginner’s Guide to Getting Started with add_messages Reducer in LangGraph

Damilola Oyedunmade — Fri, 31 Oct 2025 08:35:32 +0000

If you’ve already spent some time exploring LangGraph and how reducers manage state, you’re probably starting to see how everything fits together.

But there’s one reducer you’ll use more than any other, add_messages.

This one is the workhorse behind your agent’s memory. Every time your AI sends or receives a message, add_messages quietly steps in to update the conversation history and keep everything in sync.

Before we dive in, here’s something you’ll love:

Learn LangChain the clear, concise, and practical way.
Whether you’re just starting out or already building, Langcasts gives you guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

In this quick guide, we’ll walk through what add_messages does, how it works, and how to use it to manage message flow in your LangGraph projects.

If you’re totally new to LangGraph or reducers, check out these two quick reads first:

Otherwise, let’s jump right into how add_messages actually keeps your agent’s conversations alive.

What `add_messages` Does

add_messages is a built-in LangGraph reducer that updates your agent’s message history by adding new messages to the existing state.

That’s it. No magic, just a clean way to keep track of every message in a conversation so your agent remembers what’s already happened.

You can think of it as your agent’s note-taker.

Every time someone speaks — whether it’s the user, the assistant, or a system message, add_messages records that message in order so the context stays consistent.

In LangGraph, a message is just a small dictionary that looks like this:

{"role": "user", "content": "Hello!"}

When you use add_messages, it takes your current list of messages and appends the new one:

Before:
messages = [{"role": "user", "content": "Hi!"}]

After add_messages("How are you?"):
[
  {"role": "user", "content": "Hi!"},
  {"role": "user", "content": "How are you?"}
]

This small reducer is what helps your LangGraph agent maintain the flow of a conversation. Without it, each new message would feel like starting from scratch.

Next, we’ll look at how add_messages actually works and what happens behind the scenes when it updates your graph’s state.

Under the Hood: How It Works

Now that you know what add_messages does, let’s see how it works behind the scenes.

When you call add_messages, two things happen:

It looks at the current state of your LangGraph agent.
It appends new messages to the existing message list.

You give it a state and a message or list of messages, and it returns a new state with those messages added in.

Nothing fancy, just clean state management that makes conversation tracking reliable.

Here’s a quick example:

from langgraph.reducers import add_messages

state = {"messages": []}

new_state = add_messages(
    state,
    {"role": "user", "content": "Hello, AI!"}
)

print(new_state)

Output:

{'messages': [{'role': 'user', 'content': 'Hello, AI!'}]}

If you add another message, it simply builds on the previous one:

next_state = add_messages(
    new_state,
    {"role": "assistant", "content": "Hi there! How can I help you?"}
)

print(next_state)

Output:

{
  'messages': [
    {'role': 'user', 'content': 'Hello, AI!'},
    {'role': 'assistant', 'content': 'Hi there! How can I help you?'}
  ]
}

add_messages always appends new entries while keeping the existing conversation intact.

This makes it perfect for agents that need to remember context across multiple turns.

Next, we’ll walk through how to use add_messages in a real LangGraph workflow and see where it fits in when building an agent.

Using `add_messages` in Your LangGraph Workflow

You’ve seen what add_messages does in isolation. Now let’s see how it fits inside a typical LangGraph setup.

In most cases, you use add_messages inside a workflow or node that handles interactions between the user and the model. Each time a message is generated or received, the reducer updates the agent’s state to include the new message.

Here’s a simple example that shows how it comes together:

from langgraph.graph import StateGraph
from langgraph.reducers import add_messages

# Step 1: Create a simple state graph
graph = StateGraph()

# Step 2: Define the initial state
state = {"messages": []}

# Step 3: Add a user message
state = add_messages(state, {"role": "user", "content": "Tell me a joke."})

# Step 4: Add the assistant's reply
state = add_messages(state, {"role": "assistant", "content": "Why did the scarecrow win an award? Because he was outstanding in his field!"})

print(state)

Output:

{
  "messages": [
    {"role": "user", "content": "Tell me a joke."},
    {"role": "assistant", "content": "Why did the scarecrow win an award? Because he was outstanding in his field!"}
  ]
}

This example shows how add_messages quietly keeps your agent’s conversation up to date. Each new message builds on the previous state, which allows LangGraph to maintain context between turns.

You can also use add_messages in custom nodes, like this:

def handle_user_input(state, message):
    # Add the user's message
    return add_messages(state, {"role": "user", "content": message})

By including add_messages inside a node or after each model response, you ensure that your agent always has a complete record of the conversation to work with.

Next, we’ll look at where add_messages shines and the kinds of problems it solves best in LangGraph workflows.

Where `add_messages` Shines

add_messages might look simple, but it’s one of the most useful reducers in LangGraph. It plays a key role in keeping your agent’s state consistent and your conversations coherent.

Here are a few places where it really shines:

1. Conversation Tracking

Every message that comes in or goes out needs to be stored somewhere. add_messages handles that automatically, keeping a running log of the entire exchange.

This allows your agent to access past messages and use them for context when generating a response.

2. Memory Management

When paired with memory systems or message filters, add_messages becomes the foundation for long-term conversation handling.

It helps your agent “remember” earlier parts of a chat without you having to manually manage lists or indexes.

3. Multi-Node Workflows

In larger LangGraph setups with several nodes (for example, separate reasoning, planning, and responding nodes), add_messages keeps all message history synchronized.

No matter which node adds a message, the full state stays aligned across the graph.

4. Debugging and Transparency

Since all messages are stored in a structured list, it’s easy to inspect your agent’s message history at any point.

That makes debugging and tracing behavior much simpler, especially in complex workflows.

Next, we’ll cover a few common mistakes and best practices so you can use add_messages effectively without running into problems.

Common Mistakes and Best Practices

Even though add_messages is simple to use, a few small mistakes can cause big headaches if you’re not careful. Here are some common pitfalls to watch for, along with a few best practices to keep your message handling clean and reliable.

❌ Mistake 1: Overwriting Messages Instead of Appending

Some beginners accidentally replace the entire message list instead of adding to it.

For example:

state["messages"] = {"role": "user", "content": "Hi!"}  # Wrong

This wipes out your message history.

Always let add_messages handle updates for you:

state = add_messages(state, {"role": "user", "content": "Hi!"})  # Correct

❌ Mistake 2: Using the Wrong Message Format

LangGraph expects messages to follow a simple structure with role and content.

If you forget one of these keys, the reducer might not behave as expected.

# Wrong
add_messages(state, {"text": "Hello!"})

# Correct
add_messages(state, {"role": "user", "content": "Hello!"})

✅ Best Practice 1: Add Multiple Messages at Once When Needed

If you’re adding several messages, pass them as a list:

add_messages(state, [
    {"role": "user", "content": "Hi"},
    {"role": "assistant", "content": "Hello there!"}
])

This keeps your updates efficient and tidy.

✅ Best Practice 2: Keep Message History Manageable

Over time, long conversations can grow large.

If your agent doesn’t need all previous messages, consider trimming or summarizing the history before adding new ones. This helps keep performance smooth.

✅ Best Practice 3: Use `add_messages` Consistently

Make add_messages your single source of truth for message updates.

That consistency prevents bugs and ensures every node or function in your workflow is working from the same conversation record.

add_messages might seem small, but it’s a core part of what makes LangGraph conversations work. It quietly keeps your agent’s message history up to date, preserving context and giving your AI the ability to respond naturally across turns.

You’ve seen how it works, how to use it in a workflow, and how to avoid common mistakes. With this reducer in your toolkit, you can manage conversation flow cleanly and focus on building smarter, more context-aware agents.

If you’d like to explore further, check out other reducers like set_messages and clear_messages, or try creating your own custom reducers for more advanced state control.

And if you’re just starting your LangGraph journey, these two guides will help fill in any gaps:

With that, you’re ready to start using add_messages in your own LangGraph projects and see your agents come to life one message at a time.

A Beginner’s Guide to Getting Started with Reducers in LangGraph

Damilola Oyedunmade — Fri, 24 Oct 2025 12:42:03 +0000

If you’ve been exploring LangGraph articles series lately, you’ve probably noticed that it’s more than just a fancy way to wire up agents and tools. It’s a framework built for control, helping you manage how data, messages, and states flow across your AI system.

But as your graphs grow, so does the complexity. You might find yourself wondering:

“How do I combine multiple outputs or keep track of what’s happening across different nodes?”

That’s where Reducers come in.

Before we dive in, here’s something you’ll love:

Learn LangChain the clear, concise, and practical way.
Whether you’re just starting out or already building, Langcasts gives you guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

Reducers are the quiet organizers in your LangGraph workflows. They help you take multiple pieces of information, from agents, nodes, or even message streams, and neatly combine them into a single, meaningful result.

In this beginner’s guide, we’ll break down what Reducers are, why they matter, and how to start using them in your LangGraph projects. No complex math, no jargon, just clear explanations and simple examples you can try out right away.

Understanding Reducers: The Core Idea

Before we jump into code, let’s first get the idea right.

A Reducer in LangGraph is a function that takes in multiple inputs, like messages, states, or results from different parts of your graph, and reduces them into a single, unified output.

If that sounds abstract, think of it like this:

“You have three agents each giving different answers to the same question. Instead of picking one randomly, you can use a Reducer to combine their responses into a single, well-rounded answer.”

In programming terms, Reducers are similar to the reduce() function you may have seen in JavaScript or Python. They take a list of things and boil them down into one. In LangGraph, this means they can:

Merge messages from multiple nodes.
Summarize outputs from different agents.
Keep your graph’s state clean and consistent.

Why does this matter? Because as your workflow grows, you’ll often have multiple branches running at once — and eventually, you’ll need a way to bring everything back together. Reducers make that process simple and predictable.

So, in short:

A Reducer helps your LangGraph workflow make sense of many outputs by turning them into one clear, useful result.

Up next, let’s see where Reducers fit inside a LangGraph workflow.

Where Reducers Fit in LangGraph

So, where exactly do Reducers come into play?

Think of your LangGraph workflow as a map, data flows from one node to another, sometimes branching into different paths. But at some point, those paths need to come back together. That’s where a Reducer steps in.

Reducers usually sit after multiple nodes to collect and merge their outputs into one result. You might use one:

After several agents respond to the same query.
To combine outputs from different tools or branches.
To keep track of the evolving state in looping workflows.

Visually, it’s like this:

Inputs → Node A / Node B / Node C → Reducer → Final Output

In short, Reducers are the “glue” that helps your graph stay organized when things start branching out.

Writing Your First Reducer

Let’s make this real with a quick example.

Let's say you have a LangGraph where two nodes (or agents) each return a short response. You want to combine both into one final message. That’s the perfect job for a Reducer.

Here’s what that might look like:

from langgraph.graph import Graph, Reducer

# Step 1: Define your reducer function
def combine_responses(responses):
    # 'responses' is a list of outputs from previous nodes
    return " | ".join(responses)

# Step 2: Add it to your graph
graph = Graph()
graph.add_node("agent1", lambda: "Hello from agent 1")
graph.add_node("agent2", lambda: "Hi from agent 2")

# Step 3: Use the reducer to merge their outputs
graph.add_reducer(Reducer(["agent1", "agent2"], combine_responses))

# Step 4: Run the graph
result = graph.run()
print(result)

What’s happening here:

Each agent (or node) produces a response.
The Reducer collects those responses as a list (["Hello from agent 1", "Hi from agent 2"]).
Then it merges them using our combine_responses function.

Output:

Hello from agent 1 | Hi from agent 2

Simple, right? You can replace that logic with anything, summarizing text, averaging numbers, or combining structured data. The key is that your Reducer takes many inputs and produces one clean output.

Tips & Best Practices

Here are a few quick pointers to keep your Reducers clean and effective:

Keep them simple.
A Reducer should do one thing — combine inputs clearly. Don’t overload it with logic.
Use clear names.
Functions like merge_answers() or summarize_history() make your graphs easier to read and maintain.
Test Reducers independently.
Run them outside the graph first to be sure they handle lists, empty inputs, or unexpected data gracefully.
Avoid hidden state.
Let your Reducer depend only on what it receives. This keeps your workflow predictable and easier to debug.
Think of the “why.”
Only add a Reducer if it genuinely helps simplify or unify your outputs not just because you can.

Reducers might seem like a small piece of the LangGraph puzzle, but they play a big role in keeping your workflows clean, organized, and efficient. They help your graphs “think clearly”, by merging scattered outputs into one cohesive result.

Once you get the hang of Reducers, you’ll find it easier to manage complexity, especially as your projects grow beyond simple, single-path flows.

So go ahead, try building one, experiment with how it combines data, and see how it transforms your LangGraph workflows.

Small concept. Big impact.

A Beginner's Guide to Getting Started in Agent State in LangGraph

Damilola Oyedunmade — Mon, 20 Oct 2025 12:58:45 +0000

If you’ve been exploring LangChain lately or following our article thread, you’ve probably come across LangGraph. It’s a new framework that lets you build agents that think in steps, follow logical paths, and keep track of what they’ve already done. Instead of chaining prompts together and hoping things work out, LangGraph gives your agent a structure — a clear map of how information moves and changes as it works.

We’ve already covered the basics of LangGraph Agents in a previous article, where we explained how agents can reason through tasks and coordinate tools. In this piece, we’re going one layer deeper to talk about something that makes those agents truly capable: state.

Before we dive in, here’s something you’ll love:

Learn LangChain the clear, concise, and practical way.

Whether you’re just starting out or already building, Langcasts gives you guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

Think of state as your agent’s short-term memory. It’s what keeps track of what has been said, what’s been done, and what comes next. Without it, your agent would forget everything the moment a step finishes. With it, your agent can carry context, recall information, and act with purpose.

In this guide, you’ll learn what state is, why it matters, and how to use it to build your first stateful agent. We’ll start simple, walk through a hands-on example, and share tips to help you avoid common mistakes. If you prefer to learn visually, you can also check out the LangGraph team’s video on this topic here.

By the end, you’ll know how to make your agent not just respond, but remember and reason through its work.

What is “State” in LangGraph?

In simple terms, state is the data your agent keeps track of as it runs. It’s everything your agent knows at a given moment — the current input, the tools it has used, what it has said, and what it still needs to do.

Imagine your agent as a person solving a problem step by step. Each time they finish a task, they make a quick note before moving on — that note is the state. It helps them remember what just happened so they can make the next move intelligently.

LangGraph uses this same idea. Every time your agent completes an action, the state gets updated. That update becomes the foundation for whatever comes next. Without it, your agent would start every step as if it had no history, no context, and no clue what it was doing before.

In LangGraph, state is a structured object. You define it yourself, usually as a simple Python class or dictionary. This makes it flexible and transparent. You decide what to store: maybe it’s the conversation history, a running summary, or a few key variables. LangGraph then passes that state between nodes in your workflow, keeping everything connected and consistent.

Key Concepts You Should Know

A few core ideas that make LangGraph work.

State Schema The state schema is the blueprint for your agent’s memory. It defines what kind of data your state holds, things like user messages, results from tools, or progress markers. You can create this schema using Python’s TypedDict, dataclass, or Pydantic models. Keeping it structured helps you stay organized and makes debugging easier.
State Reducer:The reducer is a function that dictates how a new piece of data returned by a node combines with the existing data in the state. For example, for a conversation history, the reducer ensures new messages are appended to the list, not overwritten. If you don't define one, the old data is simply replaced by the new data.
Nodes A node is a single step in your agent’s workflow. Each node takes the current state as input, performs some logic, like calling an LLM, running a tool, or making a decision, and then returns an updated dictionary of the state. You can think of nodes as the individual actions your agent takes while moving through its process.
Edges Edges connect the nodes. They define how the workflow moves from one node to another. Sometimes this path is simple—one node always leads to the next. Other times it’s conditional, where the agent decides which branch to follow based on what’s inside the state.
Graph Execution When you put nodes and edges together, you get a graph. The graph defines the logic of your workflow—what happens first, what comes next, and what conditions guide the flow. LangGraph takes care of running this graph step by step, passing the state through each node and updating it as it goes.
Persistence and Memory Sometimes, you’ll want your agent to remember information even after it finishes a run. That’s where persistence comes in. LangGraph lets you save and reload the state so your agent can pick up where it left off. This is what allows long-running agents, ongoing conversations, or workflows that span multiple sessions.
Tools and Agent State LangGraph also gives you the flexibility to connect tools—like APIs, databases, or custom functions—that can read and update the state directly. This is powerful because it lets your agent not just think but act. For example, a research agent might store search results in the state, or a support bot might log each response for later analysis.

Once you understand these building blocks, the rest of LangGraph starts to make sense. Everything revolves around how state flows through nodes and edges. In the next section, we’ll build a simple agent with state.

Step-by-Step Walkthrough: Build a Simple Agent with State

Now that you know what state is, let’s build a small example to see how it actually works.

Step 1: Install LangGraph

First, make sure you have LangGraph and LangChain installed:

pip install langgraph langchain openai

This gives you the tools you need to create and run your first graph.

Step 2: Define the State

Your state is just a Python structure that stores information as your agent runs. Let’s create a simple one that holds a list of messages.

from typing import TypedDict, List

class ChatState(TypedDict):
    messages: List[str]

Here, the state has a single key — messages — that will keep track of the conversation.

Step 3: Create the Nodes

Each node is a step in your workflow. Let’s make one node that receives user input and another that simulates the agent’s response.

def user_input_node(state: ChatState) -> ChatState:
    user_message = input("You: ")
    state["messages"].append(f"User: {user_message}")
    # Return the state dictionary with the new message
    return state 

def agent_response_node(state: ChatState) -> ChatState:
    last_message = state["messages"][-1]
    reply = f"I see, you said: '{last_message.split(': ')[1]}'"
    state["messages"].append(f"Agent: {reply}")
    # Return the state dictionary with the agent's reply
    return state

The first node records what the user says. The second reads that message and creates a response.

Step 4: Build the Graph

Now you connect the nodes so LangGraph knows the order of execution.

from langgraph.graph import StateGraph

graph = StateGraph(ChatState)
graph.add_node("input", user_input_node)
graph.add_node("respond", agent_response_node)

graph.add_edge("input", "respond")
graph.set_entry_point("input")

You’ve just built a tiny graph where “input” leads to “respond.”

Step 5: Run It

Finally, compile and run your graph.

app = graph.compile()
state = {"messages": []}

for _ in range(2):
    state = app(state)

Run this in your terminal, and you’ll see a simple back-and-forth between you and the agent. Each time, the state updates with new messages, so the agent remembers what’s been said.

Step 6: Inspect the State

After running it, print the state to see what’s stored:

print(state)

You’ll see something like:

{'messages': ['User: Hello', "Agent: I see, you said: 'Hello'", ...]}

That’s your agent’s memory — the state — keeping track of the conversation as it unfolds.

Even with this tiny example, you’ve learned the core idea: the state moves through each step, carrying the information your agent needs to work intelligently. Once you understand that, you can build far more advanced agents that plan, loop, or collaborate across tasks, all powered by the same simple principle.

Real-World Examples of Using State

Now that you’ve seen how state works in a simple example, let’s look at how it powers real agent workflows.

1. A Chatbot That Remembers

Most chatbots forget everything as soon as you hit enter. With state, your chatbot can remember past questions, user preferences, and even previous answers. This makes conversations smoother and more natural. For example, when a user says, “Remind me to buy groceries later,” the agent can store that request in the state and recall it when needed.

2. A Research Assistant

Imagine a research agent that gathers information from multiple sources. Each time it finds new data, it adds it to the state. Later steps in the graph can summarize, organize, or compare those results. The state might contain keys like raw_search_results and research_summary. The state becomes the shared workspace where all the research lives.

3. A Task Planner

A planning agent can track progress through the state. It might start with a to-do list, then update each item as it completes a step. For example, if the goal is to “plan a trip to Japan,” the agent can store flight options, hotel picks, and itineraries inside the state, keeping everything in sync across steps.

4. Multi-Agent Collaboration

LangGraph also supports multiple agents working together. They can share a single state, passing updates as they complete tasks. One agent might handle data gathering, another analysis, and another reporting, all reading and writing to the same shared memory.

5. Support and Feedback Systems

In customer support scenarios, state can track the full history of a conversation. This allows the agent to stay consistent, avoid repeating questions, and escalate problems with full context. It can even store feedback to improve responses over time.

These examples show why state is so valuable. Whether it’s chatting, planning, researching, or collaborating, the same idea applies: the state is where your agent’s understanding lives.

Frequently Asked Questions

1. Do I always need to use state?

No. If your agent only handles single, simple requests, you can skip it. But once your workflow involves multiple steps, memory, or decisions, state becomes essential.

2. Is state the same as memory?

Not exactly. Memory is a part of the state — it’s what keeps track of conversations or events. The state, on the other hand, can hold anything your workflow needs, like results, flags, or user data.

3. Can I update the state manually?

Yes. You can modify the state directly in your nodes or through tools. This gives you full control over what your agent remembers or forgets.

4. What happens if a node fails?

LangGraph allows you to inspect the state and retry. Because the state is stored between steps, you don’t lose your progress when something goes wrong.

Conclusion

State is what makes LangGraph agents feel alive. It gives them the ability to remember, reason, and stay consistent across every step of their workflow. Once you understand it, you’re no longer just connecting prompts; you’re building systems that think and adapt.

We’ve already explored what LangGraph agents are in our earlier article, and now you’ve learned what makes them truly capable. Start small, experiment with your own state designs, and watch how your agents grow from simple responders into thoughtful problem-solvers.

A Beginner's Guide to Getting Started in Agents in LangGraph

Damilola Oyedunmade — Sat, 18 Oct 2025 10:00:18 +0000

The world of AI is moving beyond simple question-and-answer chatbots. The new frontier is the AI Agent, a sophisticated system that can reason, plan, use tools, and autonomously tackle complex, multi-step tasks. Imagine an AI that doesn't just answer your question, but actively goes through a research process: searching the web, analyzing data, and summarizing the findings, all on its own.

Now, when it comes to building such intelligent, goal-driven systems, LangGraph has emerged as a practical and structured way to do it.

LangGraph is part of the LangChain ecosystem, designed specifically for building stateful, graph-based AI workflows. In simpler terms, it allows you to represent your AI logic as a graph, where each node represents a task or tool, and the edges define how your agent moves between tasks based on what’s happening in the conversation or computation.

This is powerful because real-world applications rarely follow a straight line of thinking. They branch, loop, and depend on context. LangGraph captures that complexity naturally, without forcing you to hard-code every possible path.

Before we dive in, here’s something you’ll love:

Learn LangChain the clear, concise, and practical way.

Whether you’re just starting out or already building, Langcasts gives you guides, tips, hands-on walkthroughs, and in-depth classes to help you master every piece of the AI puzzle. No fluff, just actionable learning to get you building smarter and faster. Start your AI journey today at Langcasts.com.

By the end of this guide, you’ll understand the core ideas behind agents in LangGraph, learn how to build your first one, and see how to extend it into something truly useful—like a research assistant or problem-solving bot.

Next, let’s unwrap the concept a bit deeper by understanding how agents work in LangGraph and what makes them different from traditional AI workflows.

Understanding the Core Concept of Agents in LangGraph

Before diving into code, it’s important to understand what “agents” really mean in the context of LangGraph.

At a high level, an agent in LangGraph is an intelligent component that can make decisions, take actions, and use tools to complete a goal. It doesn’t just follow a fixed script; it evaluates what to do next based on inputs, outputs, or the current state of a conversation or workflow.

The Key Building Blocks

To understand how agents operate, it helps to break LangGraph into its three main parts:

Nodes

A node represents a single operation or step in your workflow. This could be a function call, an LLM (Large Language Model) response, or even an external API call.

For example, one node might retrieve data, while another node analyzes it or decides the next step.
Edges

Edges are the links that connect nodes. They define how information flows from one node to another. In traditional programming, you might use if-else statements to control flow. In LangGraph, edges perform this function visually and logically by connecting decision points and actions.
Graph State

The graph state keeps track of everything happening as your agent runs. It holds the memory of past interactions, results, or decisions. This state allows agents to remember what has already been done, making them smarter and more context-aware.

How LangGraph Differs from Standard LangChain Agents

LangChain introduced the idea of “agents” that can use tools dynamically. LangGraph takes this concept further by letting you represent an agent’s logic as a graph structure instead of a sequence of steps.

In a standard LangChain setup, an agent might decide, “I need to use a calculator” and then call that tool. With LangGraph, you can define this decision-making flow as a series of connected nodes, giving you more visibility and control over how the agent operates.

This approach makes complex agent systems easier to design, debug, and expand. It also allows multiple agents or tools to work together seamlessly within one structured workflow.

A Simple Analogy

If you think of a LangChain agent as a single worker that figures out what to do next, then LangGraph is like giving that worker a well-labeled map. The worker can still make decisions, but the map defines all possible routes and ensures no step is missed or repeated unnecessarily.

By now, you should have a clear picture of what an agent is in LangGraph and how it differs from traditional agents. In the next section, we’ll set up your environment and get ready to build your very first agent graph.

Hands-On: Building Your First Simple Graph

Now that we understand the core components, let's translate them into code by building the simplest possible LangGraph workflow. This graph will take a message, process it through two steps, and finish.

Step 1: Installation and Environment Setup

First, let's ensure you have the necessary libraries installed.

pip install langgraph langchain-core langchain-openai

Next, for any LangChain/LangGraph application, you'll need an API key for your chosen Large Language Model (LLM). For this example, we'll use OpenAI, but the structure works with any model integrated via LangChain.

import os
# Set your API key as an environment variable
# os.environ["OPENAI_API_KEY"] = "YOUR_API_KEY" 
# NOTE: It's best practice to use a .env file or a secret manager.

Step 2: Define the Graph State

We'll start by defining the central data structure that will hold all our information. For simplicity, our state will just be a list of messages. We use TypedDict for a clear, type-hinted structure.

`from typing import TypedDict, Annotated
from langgraph.graph import StateGraph, END
from langchain_core.messages import BaseMessage, HumanMessage, AIMessage
import operator

# The State is the data structure that flows through the graph.
class AgentState(TypedDict):
    """
    A dictionary to pass along the chain.
    - messages: A list of all conversation messages (memory).
    """
    messages: Annotated[list[BaseMessage], operator.add]`

The key piece here is Annotated[list[BaseMessage], operator.add]. This tells LangGraph that when any node returns a new list of messages, it should append them to the existing list in the state, rather than overwriting the entire history. This is how the agent maintains memory.

Step 3: Define the Nodes (The Functions)

Our graph will have two simple functional nodes. Each node takes the current AgentState as input and returns an update to the state.

def initial_greeting(state: AgentState) -> AgentState:
    """The first node: processes the initial user message and sets the stage."""
    # Read the last message from the state
    user_message = state['messages'][-1].content

    # Generate a simple greeting based on the input
    response = AIMessage(content=f"Hello! I received your message: '{user_message[:25]}...'")

    # Return an update to the state (appending the AI's response)
    return {"messages": [response]}

def final_wrap_up(state: AgentState) -> AgentState:
    """The second node: adds a concluding message."""

    wrap_up_message = AIMessage(content="✅ Task complete. That was a successful two-step workflow.")

    # Return an update to the state (appending the wrap-up message)
    return {"messages": [wrap_up_message]}

Step 4: Construct the Graph

Now we use the StateGraph builder to tie the nodes together with edges.

# 1. Initialize the graph builder
workflow = StateGraph(AgentState)

# 2. Add the nodes
workflow.add_node("step_1_greeting", initial_greeting)
workflow.add_node("step_2_wrap_up", final_wrap_up)

# 3. Define the flow (Edges)
# Set the entry point (the first node to run)
workflow.set_entry_point("step_1_greeting") 

# Add a Simple Edge: after step_1, always go to step_2
workflow.add_edge("step_1_greeting", "step_2_wrap_up")

# Add a Simple Edge: after step_2, the workflow ends
workflow.add_edge("step_2_wrap_up", END)

# 4. Compile the graph into an executable Runnable
app = workflow.compile()

Step 5: Invoke the Graph and See the Result

We run the compiled graph by passing in the initial state, which must contain the user's message.

`# Initial state with the user's input
initial_input = {"messages": [HumanMessage(content="I need help getting started with graph structures.")]}

# Run the graph
final_state = app.invoke(initial_input)

# Print the full conversation history
print("--- Final Agent Conversation History ---")
for message in final_state["messages"]:
    print(f"[{message.type.upper()}]: {message.content}")`

The output will clearly show the sequential execution, with the initial user input, followed by the greeting from "step_1_greeting", and finally the wrap-up from "step_2_wrap_up". This simple example demonstrates the fundamental flow: State → Node → Edge → Node → State Update.

Conclusion: Beyond the First Graph

You have now successfully built, defined, and run your first stateful agent workflow in LangGraph. You’ve moved beyond simple linear chains and created a dynamic system capable of memory, conditional decision-making, and looping.

Here’s a quick recap of what you accomplished:

Concept	LangGraph Component	The Breakthrough
Memory	AgentState	The agent maintains a persistent record of the conversation and intermediate results across all steps.
Modularity	Nodes	The workflow is broken down into simple, reusable Python functions that are easy to test and debug.
Intelligence	Conditional Edges	The agent’s brain (the LLM) decides its own path, enabling complex behaviors like tool-use and self-correction (the ReAct pattern).

While a single-agent graph is powerful, LangGraph truly shines when you scale your system. Your next steps in mastering the framework should focus on these advanced, production-ready features:

Multi-Agent Systems: Instead of one large, general-purpose agent, you can connect multiple specialized agents in your graph. Imagine a "Researcher Agent" feeding data to a "Summarizer Agent," all coordinated by a central "Supervisor Agent." LangGraph provides the perfect framework for managing this collaboration.
Human-in-the-Loop (HITL): For critical or sensitive tasks, you can set a conditional edge to pause the workflow and wait for human input or approval before the agent continues. This is crucial for real-world reliability and safety.
Persistence and Checkpointing: LangGraph lets you save the AgentState after every step to a database. This means you can resume a long-running workflow or conversation days later, or recover gracefully from errors without losing any context.

LangGraph is the essential toolkit for building reliable, accountable, and complex AI agents. By understanding the flow of the State, the function of the Nodes, and the power of the Conditional Edges, you have taken the biggest step toward becoming a master architect of agentic AI.

Now go forth and build something amazing!