hi everyone welcome to this video. The start of a small series on agents with L graph. Lang graph is built on top of L chain and allows you to build agents or agentic workflows. You can also use it for other purposes, but agents are its main focus. The core concept of Agents is to use an LLM to decide on a sequence of actions. In agents, an LLM functions as a reasoning engine to determine which actions to take and in what order. Lang graph also enables the combination of multiple agents into a so-called agent swarm, facilitating data sharing, performing various tasks, and allowing large language models to interact with each other. You might be familiar with my video about crew AI or might have heard about autogen. So what's the difference? Autogen and crew AI offer high-level frameworks with their own pros and cons. Langra, however, has a steeper learning curve but provides a deeper understanding of how agents operate. This enables you to fine-tune and customize your workflows at a much granular level. This lower-level framework allows for

greater flexibility and control over the behavior and interaction of agents to meet specific and complex requirements. But no worries, it's not that difficult if you understand the most important concepts of Lang graph. These are nodes, edges, and state. So what's a node? A node is a function or runnable that performs a specific task within the graph. Each node processes input and updates a state based on its operation. An edge defines the connection and flow between nodes, determining the order of execution. Conditional edges can route execution based on the current state. State represents the data passed between nodes during execution. Each node updates this internal state with its return value, allowing for persistent and dynamic workflows. At the end, you will have a structure with nodes that change the state, address the route to the next node, and update the state again. You can also define a special end node to indicate the workflow execution is complete. Okay, in theory. For now, let's start with some very basic examples that don't even use an LLM. We will first learn the concepts through hands-on.

practice and then move to a more complex real-world example involving an llm. Okay, I'm in VS Code, and as you can see, we've got multiple notebooks here. We have to use this Lang graph. IPI notebook. This is the beginner Notebook we will use. So, the first step before we can use Langra is to install it. So, this is done with Pip install Lang graph, and this will install the library into your environment. The next step is to work with an opening API key. So, I've got an end file, and there is my OPI API key. For the very basic examples, this is not needed, but later when we go to a real-world example with an llm, then you need an OP API key. Or you can also use a different model to make that low. N for we also have to install Python. NF and then we can just execute this line of code. If we see a true, this means that our environment's variables were imported into our environment. Okay, let's now work with Langra. So, we import two

classes from Lang graph and message graph. And is a very special class that indicates that a workflow execution is over. And message graph is one of the predefined graphs by L graph. So this makes it very easy to interact with an llm. As you can see, we've got a function here which takes an input, which is a list of messages. So this is the normal workflow when you work with llms, that you have got a list of messages that you pass to let's say OPI. And in this case, we make it very simple. So we've got an input and we access the first element and overwrite the content with a single a. So nothing really very complex here. So first step is to create an instance of that message graph. So now we can add nodes and edges. To add a node, we have to execute this add node method and we provide a key and a function or runnable. So both normal functions and length chain runnables are acceptable to be executed. After executing this add one function in Branch a, we want to add an edge which

routes to another node, and this can be done with add edge. So, we pass in the start key, which is Branch A, and pass it to another node. This node is defined here. So, we've got this node B, and we perform this add one function again. So, that's the link between Branch A and B. So, here we've got the node. We've got a second node, and the connection is here, Branch A and Branch B. And we also use another Edge, so we can use multiple edges from one branch or one note. Branch A again, and also branch and route to Branch C. So, again, we perform add one in this branch, and then from Branch B and Branch C, we route to another node, final node. So, both route to the same node, and again we add one and the edge in this final LOE is end. So, this indicates that the workflow is over. And then, very important last step is to set an entry point. So, where should our L graph workflow start the execution? So, that's not clear. So, we have to set an entry.

point. And this can be done with the set entry point method. And we set our entry point of this graph to Branch A. After setting all the nodes and edges, and after setting the entry point nodes and edges, we have to compile the graph. So we call the compile method of our final graph. And this now creates a runnable, which can be used with the invoke method. So that's a standard interface of length chain. So if you're familiar with length chain, that's very easy to use. What's very helpful, in my opinion, is to also visualize our graph or runnable. So after compiling it, we can use the get graph method. And in combination with the image class and the display method of the display module of IPython, we can just display or visualize our graph. So we can do it like this. And I think this is very helpful to actually see what's going on in this workflow. Because I think this is much easier to understand than this, especially when your graphs become more complex. So we start here with our entry point, Branch A. Then we branch off to

Branch b and c, and we get together here at the final Noe, and this results um in the end node. So now let's execute it and maybe think ahead what actually happens here. So we start with a single a, and in AIC graph 1, a is added. So we start here. The add one function is executed, so 1 a is added. Then we branch to C and B, we add 1 a, 1 a again, and in the final note, we also add one a. So we end up with five A's. Let's see if that actually happens. Yes, you can see we've got 5 A's here. Okay, this was straightforward, but often you want to perform a different action based on the input. This can be achieved with conditional edges. So let's again create a very simple example. So we use human message and message graph, and also the end node again. So we've got as input for our state a list of human messages, and in this entry function, we do nothing. We only return the same input, and then in our next function, we've got some

we print using Branch B, and another function, which is called work with C, where we just print using Branch C, but we also don't do anything with the state. And then we've got a special R router function. This router function is required for conditional edges. So what we are going to do here is not return the state, but we return a string. And dependent on what the input is, we return the string Branch B, or we return the string Branch C. And this router function is then used in a conditional edge. So let's first start with the graph. So we create our graph again. We create our message graph. And now we want to add a node. So first we create our node Branch A, which performs this entry function. So nothing really happens here. And then we've got our node B and C. And in Branch B, we want to perform this method or this function. And in Branch C, so in this node, we want to perform this function. And then dependent on the input, we want to route it. And this can be now done with this conditional edge. So the edge in

Branch a is set here so we route based on this output of the router, and where do we want to rout to. This is set in the third argument of add conditional Edge, so we provide a path mapping. So if the output of this router function is Branch b, we use this as key, and we want to route to this node. So the first one is the key or the output string here, and this is the name of the node, so we route to Branch b. And if the output string here is Branch C, this matches this, then we route to the node Branch C. So this will route to this. For the nodes Branch B and C, we only want to add an end Edge. Our entry point is Branch a again, then we compile our graph again. So this was duplicated, and now let's visualize it. So as you can see, conditional edges are visualized with a dashed line instead of a concrete line. So this indicates that we've got a conditional Edge. Okay, now let's run the invoke method, and we pass in hello. So if you think again what happens, so if we

got this input message and the content is used B. Then we will Branch to Branch B, otherwise we will Branch to Branch C. So what do you expect to happen? Think one second about it. And as you can see, we use Branch C because we don't have this use uncore B inside the string. So if you run that, we can see that we are using Branch B. So a very simple example how conditional edges work with L graph. After these examples, you may think, I could all do this with the L and expression language. And if you think that way, you're actually right. The main difference is that langra allows you to run in Cycles, which the LCL does not allow. So let's now have a look at Cycles. So in this example, we will actually make use of our chat model. So we've got some very simple functions again. So we've got our entry point function, and this actually takes an input and just returns the same output. So it doesn't do anything. Then we perform an action, and in this case, we

would have a look at the input messages, and if the length of the input messages is larger than five, we will add a human message with the content end. Otherwise, we will end a human message with the content continue. And we're going to use the content to actually evaluate if we should continue with our workflow or not. So we extract the last message and check if and is in the content of this last message. Then we will return an underscore uncore end. Otherwise, we will return an action. And we will use that conditional edge to decide whether to perform this action again or not. But so where is the difference now? The difference is in how we create our graph. So we start with a node called Agent where we perform our entry function. This does nothing. Then we add another node called action. Here we perform our action. And then we add a conditional edge. This conditional edge is set for the agent, and this performs the should continue function. If the output of this should continue function is action, then we want to route to the action node.

otherwise, we want to return to this end. Edge, so this is our criteria for ending this workflow, and then we add an edge. And the edge for the action is the agent again. So this is where it gets cyclic. If the should continue functions does not return end, then the agent node will route to the action node, and the action node will route back to the agent node. So let's see how this actually looks like. So we first set our entry point, compile the graph again, and let's then visualize it. So this is how it looks like. We can see that we've got the agent node. This routes conditionally to the action or to the end node, and action routes back to agents. So this is where it gets cyclic, and this is why you may use Lang graph over the Lang and expression language if you ever have to use the Cycles. So let's invoke this now with hello. And as you can see, we add continue, we add continue again, add it again until we hit the length five, then we add it with this end.

and if you see that end is in the last function, then we route to this end router or this end, and note, okay. And as we can see, after this is above five, so it's six. Now the workflow ends, okay. After learning the very basic concepts with some toy examples, we can now create a real agent which interacts with um, with a fake API. So with a fake weather API. So to do this, we of course, going to use a chat model. Now, and we instantiate the chat open myi class from linkchain. We will also create a custom State now. So instead of before, we're going to use our own state. So what we want in our agent is data is a list of messages. So like before, but we also want to have this API call count, which is initially zero. And with this, we want to measure how often we tried to get the weather from the API. And after three tries, we're just going to say, currently, the service is not available. The next step is to create a tool or function for our llm so

we use the tool decorator from L chain and decorate the fake weather API function. Here is the docstring: Check the weather in a specified City. So we've got a single argument, which is the city, and we randomize the output. So if the output here of this function is one, then we will return Sunny 22°; otherwise, we will return an error message: Service temporarily not available. So let's check it out with New York, Berlin, and London. So if you run it, we can see Service not available, then we've got Sunny, and so on and so on. So this is randomized. And we now bind this method to the ChatOpeni class. So the LLM is now able to decide whether it needs this fake weather API tool to answer a question or not. So let's run this. And now let's actually call this LLM with tools. But first, we have to provide some black code. So we have to provide a tool mapping. So this is the key, and this is the function we want to call.

and now we're going to create a list of messages. So we're going to provide a single message: How will the weather be in Munich today? I would like to eat outside if possible. So we pass that to the invoke function and append that to this message. And if we're going to have a look at the message, so here is our initial message. And if you scroll to the right, we can see that we've got an AI message with an empty string as content. But what's important here is these two calls. Where is it? Here is the tool called attribute and here we can see that the LLM wants to use the fake weather API and provide the name Munich as an argument. So this was all done by the LLM. And now we actually want to call this function. So just to say, if you're not familiar with tool calling, I've got this video about tool calling with a Leng chain. So this is the boilerplate code for this. We perform the tool call and then the tool output will be added.

to this messages list, and the tool output is the content here. And we also have to provide a special ID for this tool calling. And now we can invoke this again and get the final output. So the weather munic is sunny today with a temperature of 22°. So this is what the LLM does with the output of our fake weather API. Okay, now let's use this logic to create an argentic workflow with Lang graph. So again, we've got our rout function, and this time we extract the messages, check if the last message has got these tool calls argument, and if that's not the case, we will return end. Otherwise, we will return continue, and we will use that logic to route to this I call tool function. So what's happening here is that we extract the message or the messages and extract the last message here. Then we extract this tool cots argument. We get the tool name we want to use. Then we invoke it, get the output, we increase the API call count by one. Then we create a new tool.

message with the content which is the tool output, and we going to return the state. So since we use in our state the operator add, so this gets always added to this message sequence. So this is very nicely done by langra. So we only return the tool message, and this gets added to the whole message list and then almost forgotten. Here we've got our call model function, which also uses the state. We extract the messages and provide these messages to the invoke method of the llm with tools class, and we get a response. And again we just return the response because we use this operator add, and this always adds to the message. Okay, so let's run this. And now let's create our graph. We use a different graph class now, the state graph, and this is able to work with our custom agent state. So we pass in that agent state to this state graph, and this no creates our workflow or runnable or however you want to call it, and then we going to add nodes again. So we add the key agent, and here we perform call model.

so here we just uh run this with llm. And now we add another note action, and this makes use of this call tool function. So we've got two nodes. Now we've got an entry point, which is Agent. And then we need now our conditional Edge. And the conditional Edge for the agent is determined by the should continue function. So again, if we've got this tool calls attribute, we will continue. And if we don't have it, we will return end. So if the llm decides that it needs a tool, then we going to use the tool CES node. Otherwise, we will just end from the action node. We will then route back to the agent node because this is the node which creates a final answer. And as long as we've got these tool calls attribute, then we will always add another tool call. But if that's not the case, then the final answer was created and the user is able or should be able to see it. See it. Okay, let's compile it. And then we going to create our IM again. And as you can see here.

we've got our agent, and if it continues, it will perform an action and route that back to the agent. And if we don't have the tool CS attribute, we will just end. Okay, let's try it. So we create a system message you're responsible for answering questions, and you use tools for that like our weather API. Let's now invoke that. And as you can see, service temporarily not available. Not available. Okay, let's maybe try it again because we exceeded the Max iterations. And now we can see that the output was first time temporary not available. The llm decided it has to use the tool again to answer the question. And in the second try, it was returned sunny 22°. And this is now our final answer. And if we have a look at this, we can see the weather Munich today is sunny with a temperature of 22°. And our API call count was two. So in this case, if our API unstable, we could use an agentic workflow to make sure that the agent tries again and again until it's

able to answer the question so great that's it for the video. I hope you now understand the idea behind L graph. It's most important concepts. So in the upcoming videos, we can work on more complex multi-agent workflows. So thank you very much for watching. See you. Bye-bye.

Introduction to LangGraph: A Quick Dive into Core Concepts

Hello and welcome to my channel. I am a german software engineer who works in the AI Space. I love to learn new stuff and teach it to people :-). I already have got a german channel with a lot of videos and full courses on Python, JavaScript, React and much more.

German channel: https://studio.youtube.com/channel/UCikLKUS0DZWMkukbkYDG49Q


Introduction to LangGraph: A Quick Dive into Core Concepts

Introduction to LangGraph: A Quick Dive into Core Concepts

Scripts