langgraph
:
.langgraph.reducer()
method on the schema field.
In the earlier example, our node updated the "messages"
key in the state by appending a message to it. Below, we add a reducer to this key, such that updates are automatically appended:
MessagesZodState
that handles these considerations:
MessagesZodState
for convenience, so that we can have:
StateGraph
operates with a single schema, and all nodes are expected to communicate using that schema. However, it’s also possible to define distinct input and output schemas for a graph.
When distinct schemas are specified, an internal schema will still be used for communication between nodes. The input schema ensures that the provided input matches the expected structure, while the output schema filters the internal data to return only the relevant information according to the defined output schema.
Below, we’ll see how to define distinct input and output schema.
Extended example: specifying LLM at runtime
Extended example: specifying model and system message at runtime
retryPolicy
parameter to the addNode. The retryPolicy
parameter takes in a RetryPolicy
object. Below we instantiate a RetryPolicy
object with the default parameters and associate it with a node:
TypeError
SyntaxError
ReferenceError
Extended example: customizing retry policies
.addNode
and .addEdge
methods of our graph:
Why split application steps into a sequence with LangGraph?
.addNode
:.addEdge
takes the names of nodes, which for functions defaults to node.name
.Node A
to B and C
and then fan in to D
. With our state, we specify the reducer add operation. This will combine or accumulate values for the specific key in the State, rather than simply overwriting the existing value. For lists, this means concatenating the new list with the existing list. See the above section on state reducers for more detail on updating state with reducers.
"b"
and "c"
are executed concurrently in the same superstep. Because they are in the same step, node "d"
executes after both "b"
and "c"
are finished.Importantly, updates from a parallel superstep may not be ordered consistently. If you need a consistent, predetermined ordering of updates from a parallel superstep, you should write the outputs to a separate field in the state together with a value with which to order them.Exception handling?
a
generates a state update that determines the following node.
"recursionLimit"
in the config. This will raise a GraphRecursionError
, which you can catch and handle:
"a"
is a tool-calling model, and node "b"
represents the tools.
In our route
conditional edge, we specify that we should end after the "aggregate"
list in the state passes a threshold length.
Invoking the graph, we see that we alternate between nodes "a"
and "b"
before terminating once we reach the termination condition.
GraphRecursionError
after a given number of supersteps. We can then catch and handle this exception:
Command
StateGraph
with the above nodes. Notice that the graph doesn’t have conditional edges for routing! This is because control flow is defined with Command
inside nodeA
.
ends
to specify which nodes nodeA
can navigate to. This is necessary for the graph rendering and tells LangGraph that nodeA
can navigate to nodeB
and nodeC
.graph=Command.PARENT
in Command
:
nodeA
in the above example into a single-node graph that we’ll add as a subgraph to our parent graph.
Command.PARENT
When you send updates from a subgraph node to a parent graph node for a key that’s shared by both parent and subgraph state schemas, you must define a reducer for the key you’re updating in the parent graph state. See the example below.Command(update={"my_custom_key": "foo", "messages": [...]})
from the tool:
messages
(or any state key used for the message history) in Command.update
when returning Command
from a tool and the list of messages in messages
MUST contain a ToolMessage
. This is necessary for the resulting message history to be valid (LLM providers require AI messages with tool calls to be followed by the tool result messages).Command
, we recommend using prebuilt ToolNode
which automatically handles tools returning Command
objects and propagates them to the graph state. If you’re writing a custom node that calls tools, you would need to manually propagate Command
objects returned by the tools as the update from the node.
.png
. This uses the Mermaid.ink API to generate the diagram.