LangGraph parallel tool results break after Command.update inserts a message

A graph may complete the first turn yet fail every subsequent model request. An open LangGraph issue shows two parallel tool calls where one tool returns Command.update with both a ToolMessage and a HumanMessage. The extra message can land between the parallel tool results, leaving a message sequence the model provider rejects.

Inspect message order at the boundary

Capture the AIMessage tool-call IDs and all resulting ToolMessages in order. Confirm that each tool result matches an outstanding call before any other role message is inserted. The reported failure is about ordering after parallel calls, not about the tool’s business logic.

Separate tool output from new user input

When the tool needs to pass an image or external content, consider returning it within the tool response or arranging a later graph step to add the new message only after all tool calls have resolved. Validate this design against the provider’s message schema and your actual LangGraph version.

Regression-test the second turn

Run the exact two-tool case through a second model invocation. A first-turn success can hide malformed persisted history. Add a test with parallel calls, a Command.update path, and checkpoint replay if your production flow uses them.

Adovo’s view

Conversation history is a protocol, not a transcript you can reorder freely. The state transition is only valid when all tool obligations are closed before another speaker enters. Build that invariant into the graph rather than repairing failed requests later.