Remove customised memory state when using stategraph

[SalmonSung]

I designed a memory state as following:

class SectionState(TypedDict, total=False):
    orig_file_path: str
    columns_info: str
    code_approval_items: Annotated[list, operator.add]

I'm trying to manipulate(delete) the values in code_approval_items key. However, it always merge two list together...I must use operator.add beacuse this column is collected from a bunch of Send API...

def format_response(state: SectionState, config: RunnableConfig):
    code_approval_items_dict = []
    for item in state["code_approval_items"]:
        code_approval_items_dict.append(pydantic2dict(item))
    if "code_approval_items" in state:
        del state["code_approval_items"]
    state["code_approval_items"] = code_approval_items_dict
    return state

Any clue on how to solve this problem?

[dosubot[bot]]

Hello @SalmonSung! I'm Dosu, your friendly bot here to help you out with bugs, questions, and contributions while we wait for a human maintainer. Let's tackle this together!

To address the issue of merging lists when using operator.add with the Annotated type hint, you can modify the way you handle the code_approval_items in your format_response function. Since operator.add is used to concatenate lists, you need to ensure that you're manipulating the list correctly before reassigning it.

Here's a potential solution:

1. Clear the List: Instead of deleting the key and reassigning it, you can clear the list and then append the transformed items.

2. Transform and Reassign: Transform the items using pydantic2dict and then reassign them to the list.

Here's how you can modify your function:

def format_response(state: SectionState, config: RunnableConfig):
    # Transform items using pydantic2dict
    code_approval_items_dict = [pydantic2dict(item) for item in state.get("code_approval_items", [])]
    
    # Clear the existing list and extend it with the transformed items
    state["code_approval_items"].clear()
    state["code_approval_items"].extend(code_approval_items_dict)
    
    return state

This approach ensures that you are not merging lists unintentionally. Instead, you clear the existing list and then extend it with the new transformed items. This should help you manage the code_approval_items without unwanted merging.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[SalmonSung]

@dosu How can interrupt function in one of the node in the graph to be used, interact with a command line interface tool? I currently write another method which will stream the graph and return the final output. Please suggest me other way with example

[dosubot[bot]]

No, llm.bind_tools(tools) only makes multiple tools available for the LLM to choose from, but in a typical agent setup, the LLM will call just one tool per turn—not multiple at the same time. To actually execute multiple tools concurrently, you need to use a multi-action agent setup, such as AgentExecutor with a RunnableMultiActionAgent. This setup allows the agent to output several tool actions in a single step, and the executor will run them in parallel using asyncio.gather under the hood (source).

If you want to force multiple tools to run at the same time, you can also manually call their async methods with asyncio.gather, but for agent-based workflows, make sure your agent is designed to output multiple tool actions per step.

For most use cases, just binding tools does not enable parallel tool calls—you need a multi-action agent and the right executor. If you want a code example or more details on setting this up, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[SalmonSung]

@dosu I have this llm with multiple tools, and it would return a tool_use to me. I want to see multiple tool use rather than only one of them each time. How can I do that?

[dosubot[bot]]

To get multiple tool uses in the same turn, you need to use a multi-action agent setup. In LangChain, this is handled by using an agent like RunnableMultiActionAgent together with AgentExecutor. When the agent outputs a list of tool actions, AgentExecutor will execute them concurrently (using asyncio.gather under the hood), and you'll see multiple tool uses in a single step rather than just one per turn.

Just binding tools with llm.bind_tools(tools) only makes them available; it does not enable multi-tool calls per turn. You need to ensure your agent is designed to output multiple tool actions at once and use an executor that supports this pattern. For more details and code-level references, see the implementation in AgentExecutor and RunnableMultiActionAgent.

If you want a code example for setting this up, let me know your agent type and I can help you adapt it!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[SalmonSung]

@dosu
I want a code example for setting this up

[dosubot[bot]]

Here's a minimal example of how to set up a multi-action agent in LangChain so the agent can call multiple tools in the same turn. This uses AgentExecutor with a multi-action agent (like RunnableMultiActionAgent), which enables concurrent tool execution (reference):

from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_tool_calling_agent

# Define your tools
@tool
def tool_a(input_data: str) -> str:
    """Process input data and return a result."""
    return f"Processed by A: {input_data}"

@tool
def tool_b(input_data: str) -> str:
    """Process input data and return a result."""
    return f"Processed by B: {input_data}"

tools = [tool_a, tool_b]

# Initialize the language model
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# Create a tool-calling agent (multi-action capable)
agent = create_tool_calling_agent(llm, tools)

# Create an agent executor (handles concurrent tool execution)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

# Invoke the agent with an input that encourages multiple tool calls
result = agent_executor.invoke({
    "input": "Process 'foo' with both Tool A and Tool B at the same time."
})

print(result)

If your prompt and agent setup encourage the LLM to call both tools in a single turn, the executor will execute them concurrently using asyncio.gather under the hood. This is the standard pattern for multi-tool use in LangChain (source). If you want to see the intermediate steps or tool results, set return_intermediate_steps=True in the AgentExecutor.

Let me know if you want an async example or have a specific agent type in mind!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[SalmonSung]

@dosu how does create_react_agent call multiple tools in the same time? I think it is a langgraph style graph and under the hool it is using llm.with_tools(tools) and then send the request to tool_node. If llm.with_tools(tools) can only generate one item in tool_use, how it achieve calling multiple tools in the sametime?

[dosubot[bot]]

create_react_agent does not natively call multiple tools in the same turn. By default, it uses a ReAct-style prompt and output parser that only support a single tool call per step, even if you use llm.with_tools(tools) or llm.bind_tools(tools)—these just make multiple tools available for selection, not concurrent execution. The actual ability to call multiple tools at once comes from using a multi-action agent setup (like RunnableMultiActionAgent) and an executor (such as AgentExecutor) that can handle and run multiple tool actions in parallel (using asyncio.gather) when the agent outputs a list of tool calls in a single step.

If you want true multi-tool execution in one turn, you need to use a multi-action agent and the right output parser and executor—just using create_react_agent with the standard setup will not do this, and neither will llm.with_tools(tools) alone. The orchestration for concurrent tool execution happens outside the LLM binding, in the agent and executor logic, not in the tool_node or LLM bindings themselves. For more details, see the implementation and discussion here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}