*A highly subjective overview:
If there is one thing I feel more strongly the more I use, or keep trying to use, Devika, Crew AI, and phidata, it is that what matters now is not prompts or RAG, but how agentic an LLM application can be made, and how locally it can be composed. Of course, the subject of that composition is not the operator, but the end user. We often say things like this.
Even having ten bodies would not be enough...
This is exactly the kind of application I mean for moments like that.
*Of course, this does not mean prompts or RAG are unimportant. It simply means that in a situation changing this rapidly, and at a scale shaped by economies of scale, when I ask what I, or our organization, should focus on in order to survive in this market, the answer shifts in priority because we do not have the kind of big-brother position or abundant cash reserves that they do.
So, in order to strengthen the fundamentals a bit more... I am starting again from LangGraph, little by little, strand by strand, step by step!
LangGraph - 1. Overview
? intro
Agent Executor
Chat Executor
Agent Supervisor
Hierarchical Agent Teams
Multi-agent Collaboration
LangGraph
It was created with the intention of making it easier to build custom agents using 'LangChain' and to build things beyond simple chains.
LangGraph takes a simple graph-based approach rooted in the idea that if a product can diagram something, engineering should be able to build it precisely as well.
Starting with the components, LangGraph is made up of nodes, state, edges, and graphs.
Node
Each node holds a different kind of task to be performed
- Function (e.g., an external tool)
- LCEL Runnable executable (e.g., a RAG chain)
Edge
It connects nodes to other nodes and carries out communication through the information each node holds
- paths to take, the route to move along (the proper path)
- where to pass our state object next
- the agent scratch Pad : what that is really tracking is the state
State
A function that remembers the tasks carried out by each node (a record of state)
For example, how many emails were sent, which emails were checked, which drafts were read, and which emails were written.
Graph
A collection of nodes and edges
LangGraph is a module built on top of LangChain so that it can better create 'cyclical graphs workflows containing cycles' that are often needed in agent runtimes. So, as mentioned above, its main use is to add 'cycles' for calling agents inside LLM applications and thereby determine the next action to take. In other words, it decides which 'chain' or which 'tool' to move to in a given state, how to return from there, and when a graph or sequence should be completed or ended. In short, LangGraph performs work while shepherding state.
Even if it is not a specific language or program, all programming itself has 'work' and 'process.' The 'direction' of a process is determined on the basis of information about the state of work within that process, whether it has been executed and what state it is in. This whole flow can basically be expressed in the form of a graph, a workflow, a diagram, like Scratch coding. Not only Scratch, but AWS workflows and GraphQL are also structured around the concepts of nodes and edges, and LangChain's LangGraph seems to have been made from that same idea.
From an extremely humanities-oriented, personal, and subjective angle,
LangGraph is
a set of points(state) expressed in many colors(node),
meeting lines that carry direction(sign),(edge) to form
a composed diagram(graph).
@normalstory
It feels, quite literally, like 'a workflow' in which a process(flow) is formed on top of color(state) and direction(sign) information inside a single diagram(graph) represented by points(node) and lines(edge).
So then, let us look a little more concretely at the elements that make up LangGraph through a code-based lens.
StateGraph
It is responsible for ensuring that state is maintained in one way or another throughout the entire lifecycle of an agent. StateGraph is the class that represents a graph. Before that, the StateGraph class goes through this initialization process in order to receive the state definition. StateGraph is a central state object, and as work proceeds it is updated by the graph's 'nodes,' which return the attributes of that state in the form of key-value pairs.
Updates to those attributes can happen in two ways:
- when you want a node to return a new value for an attribute, the attribute can be 'fully overridden,' and
- when you want to add to the value of an attribute, literally 'update' it. This can be used when the attribute is a list of actions performed (or something similar), so that a node can return a newly performed action and have it automatically added to that attribute.
To describe the process once more, LangGraph is, literally, a graph, but more specifically a StatefulGraph. That means this 'graph' is parameterized by a 'state object' passed to each node. Then, as explained above, each node returns values in key-value form as operations that update that state. At that point, those operations can either 1) set specific attributes of the state again (for example, overwriting an existing value), or 2) add to an existing attribute. Whether it should set or add is indicated by annotations on the state object used to construct the graph.
Nodes
The nodes added while building a graph can be created after constructing the StateGraph by using the syntax graph.add_node(name, value). The 'name' parameter should be a string used to refer to the node when edges are added, and the 'value' parameter should be a callable function or an executable LCEL.
That function (or LCEL) must accept as input a dictionary in the same format as the state object and be able to output a dictionary containing the keys of the state object to be updated. Nodes can be defined in many forms, or roles. They can be thought of as a single chain, and because they are executable in practice, they can serve as a single tool or the role of a chain.
For example,
- when defined as an agent node, it performs (or decides on) the work that needs to be done, and
- when defined as a function node that calls tools, after the 'agent node' decides whether an action should be carried out and requests that work from the 'tool function node,' that 'tool function node' performs the requested action.
Edges
Edges basically serve to wire every node to every other node. Their forms can be composed in roughly two ways:
- a Normal Edge, which always returns to the agent after a tool has been called so that it can decide what to do next, and
- a Conditional Edge, in which one of several paths can be selected. Note that because the LLM determines 'path selection,' it cannot be known before that node is actually run. In order to create a conditional edge, three components are needed:
- the upstream node, which examines the node's output and decides what to do next,
- a function that returns a string used to determine which node should be called next, and
- an element that maps the key-values output by that function to other nodes. Here, the keys should be the possible values the function can return, and the values should be the names of the nodes to move to when each value is returned.
Compiling the Graph
Before compiling the graph, you designate the node that will serve as the 'entry point' and set the 'end point,' and then you can run the graph the way you would run a LangChain runnable, either by calling invoke or by streaming it.
Agent Executor
Because LangGraph is built on top of LangChain, just like LangChain it can configure an Agent Executor with elements such as input, chat_history, intermediate_steps (and agent_outcome, which represents the most recent agent result).
Next, I plan to look at this a little more concretely through practice code for the basic Agent Executor, Chat Executor, Agent Supervisor, Hierarchical Agent Teams, and Multi-agent Collaboration.
