What Are the Main Components of LangGraph?

Let’s simplify this further. LangGraph is built around graphs, which is clearly reflected in its name. Graphs have three main parts here: nodes, edges, and state. Imagine you’re planning a road trip. The nodes are the steps where something happens, like grabbing coffee or refueling the car.

The edges are the roads that connect those stops, deciding which way to go next.

And the state? That’s like your travel journal, keeping track of where you’ve been, where you are now, and what you’ve picked up along the way. Graphs have three main parts here: nodes, edges, and state. Imagine you’re planning a road trip.

The nodes are the steps where something happens, like grabbing coffee or refueling the car. The edges are the roads that connect those stops, deciding which way to go next. And the state? That’s like your travel journal, keeping track of where you’ve been, where you are now, and what you’ve picked up along the way.

In LangGraph, nodes do the heavy lifting, like processing user input or running a language model. Edges decide the next step based on the state, and the state evolves as tasks are completed. It’s like having a smart GPS that adjusts in real time instead of following a fixed route, making LangGraph perfect for workflows that adapt dynamically.

What is a state in LangGraph?

Before we build anything fancy, let’s talk about state, the beating heart of our graph. If our workflow were a house, the state would be its foundation, keeping everything sturdy and organized. For the sake of simplicity, we can also think of it as the memory of our graph, keeping track of what’s happening, what’s changed, and what comes next.

Every node and edge in our graph interacts with the state, reading from it, writing to it, and updating it as the workflow progresses.

The state is the shared memory of your workflow. Nodes and edges write to and read from it, ensuring everything stays organized. To make this notebook useful, you need to decide what information you want to store in it. That’s where the schema comes in. A schema is just a structured way to say, “Here’s what kind of information I want to keep track of.”

For example:

• If you’re building a chatbot, your schema might include fields like user_input (what the user said) or bot_response (what the chatbot replies).

• If you’re creating a ticketing system, the schema might have ticket_status (e.g., “open” or “closed”) and assigned_agent.

The schema ensures your state is both predictable and consistent, similar to labeling sections in a notebook so you always know where to find information. To define the schema for our state in LangGraph, we typically use tools like TypedDict ...