Support sequential state propagation for batch tool calls

[yorkew-east8]

Checked other resources

• This is a feature request, not a bug report or usage question.
• I added a clear and descriptive title that summarizes the feature request.
• I used the GitHub search to find a similar feature request and didn't find it.
• I checked the LangChain documentation and API reference to see if this feature already exists.
• This is not related to the langchain-community package.

Feature Description

Feature Request: Support sequential state propagation for batch tool calls

Current behavior: When an LLM returns multiple tool calls at once, all tools execute based on the same initial state snapshot.

Use Case

When tools have dependencies on each other, subsequent tools need access to the state updates made by previous tools.

When developing a multi-tool Agent, I found that if an LLM returns multiple ToolCalls at once, subsequent tools do not get the updated state of a previous tool, leading to unexpected computations. I do not want to force the LLM to call tools one by one, as this seems to slow down the response. I think synchronizing the state between multiple ToolCalls would be more intuitive, at least there should be a toggle switch provided in the interface.

Proposed Solution

Add a configuration option (e.g., sequential_tool_execution=True) that ensures the first tool's Command state updates take effect before the second tool executes.

Alternatives Considered

No response

Additional Context

No response

[AyushDas4890]

Some context on why this happens and what works today:

The behavior comes from LangGraph's ToolNode, not the langchain package — batch tool calls are executed concurrently (executor.map(self._run_one, tool_calls, ...) in the sync path, asyncio.gather(*coros) in the async path, in langgraph/prebuilt/tool_node.py), so every call in the batch sees the same state snapshot by design.

Options that exist right now:

1. Model-level: pass parallel_tool_calls=False (supported by OpenAI and several other providers via bind_tools) so the model emits one tool call per turn. This is the "one by one" behavior you wanted to avoid — it does cost extra model turns, but it's the only path where each tool reliably sees the previous tool's Command state updates.
2. Composite tool: if two tools have a hard data dependency, wrapping them as one tool makes the dependency explicit and removes the ordering problem entirely — often the cleanest fix.
3. A sequential_tool_execution toggle would have to land in LangGraph's ToolNode (where the execution loop and the Send-based fan-out live), so this might get more traction cross-filed in langchain-ai/langgraph — the semantics need care there since interrupts and Command routing interact with the parallel fan-out.

[donggyun112]

I have a related but slightly different use case. I do not need every tool call to run sequentially. For a batch like read_a, read_b, write_a, write_b, read_c, I would want (read_a || read_b) -> write_a -> write_b -> read_c: consecutive read-only calls can overlap, while mutating or exclusive calls act as ordered barriers and cannot be overtaken.

Today ToolNode starts every call in the batch together. parallel_tool_calls=False adds model turns, while max_concurrency=1 also serializes the safe reads, so neither expresses this policy.

Would an opt-in per-tool shared/exclusive execution mode, or a classifier callback, be in scope for ToolNode? The default could remain unchanged. This request is about ordering external side effects; propagating Command state between calls can remain a separate concern.