langgraph/how-tos/multi-agent-multi-turn-convo/

[giscus[bot]]

langgraph/how-tos/multi-agent-multi-turn-convo/

Build language agents as graphs

https://langchain-ai.github.io/langgraph/how-tos/multi-agent-multi-turn-convo/

[jordynass]

I'm having trouble understanding why this isn't implemented as a human_node with a blocking request for user input such as input() or, in production, an RPC sent to a frontend. Intuitively I would have expected a human node to be treated like any other potentially slow blocking operation, if for no other reason, because it is easier to follow the logic if the flow stays within the graph rather than leaving and picking back up in a totally different part of the codebase.

Why is it important to use interrupt() instead?

[eyurtsev]

because it is easier to follow the logic if the flow stays within the graph rather than leaving and picking back up in a totally different part of the codebase.

From the developer point of view, the flow resumes from the same node where an interrupt() was used (w/ same logic applied to sub-graphs).

As a developer, this is close enough to how input() works that it shouldn't be a problem implementing HIL that works in production.

an RPC sent to a frontend.

I'm interpreting this as meaning two way communication between the client and the server (e.g., using web-sockets). If so, then yes, this could be a pattern in the future, but it's not supported right now.

However, keep in mind that one advantage of the current implementation is that the graph state is saved and is available even a week later. This can be very useful for situations where HIL is used as part of an internal process (e.g., data extraction pipeline or some other use case).

[jordynass]

I know that resume picks up at the node that interrupted, but I find that in order to keep up a conversation, I have to put a graph.stream() call in a loop that handles the logic for taking input. Basically I'm comparing

def human_node(state):
  action = input('What do you want to do next?')
  ...

graph.stream(initial_state, config)
  # Send output

with

def human_node(state):
  action = interrupt('user input needed for update')
  ...

command = Command(update=initial_state)
while command:
  while event in graph.stream(command, config):
    # Send output
  next = graph.get_state(config).next
  if not next:
    command = None
  else:
    command = Command(resume=input('What do you want to do next?'))

Given that the flow is actually straightforward (i.e. the graph just needs human input like any other slow operation, except that it might be much slower), the second solution is pretty convoluted. It's possible that an agent without memory is considered pathological so it's not even worth addressing in the documentation, but I would be surprised if there isn't a clearer way to express that flow for a persistent agent. Is there a simpler way to write it?

[estherfc00]

Hello. Is this available in production? For example, when the user makes a query using streamlit or gradio, how does the "interrupt" message come into the frontend? thanks!

[sctrmn]

What is the main difference in behaivour when we have a multi-agent graph?

[rvasa779]

When I use the same code as is I am getting the below error:

ValueError: ToolMessage.tool_call_id must match the tool call id. Expected: call_kz43, got: call_tp58 for tool 'transfer_to_hotel_advisor'.During task with name 'tools' and id 'c523ab5e-64c2-0123-ebed-b2e07aa2d766'
During task with name 'travel_advisor' and id 'bf96b329-301f-7830-45e0-83be09cdeb80'

Any solution to this?

[rvasa779]

Name: langgraph
Version: 0.2.58
Summary: Building stateful, multi-actor applications with LLMs
Home-page: https://www.github.com/langchain-ai/langgraph
Author:
Author-email:
License: MIT
Location: C:\Users\Digital\Documents\Utility\code\langgraph-tutorial.venv\Lib\site-packages
Requires: langchain-core, langgraph-checkpoint, langgraph-sdk
Required-by:

[vbarda]

Did you modify the code in the how to guide?