ninemin.lilulab.ai

Found AIMessages with tool_calls that do not have a corresponding ToolMessage — LangGraph’s INVALID_CHAT_HISTORY

Found AIMessages with tool_calls that do not have a corresponding ToolMessage. Here are the first few of those tool calls: [...] Every tool call (LLM requesting to call a tool) in the message history MUST have a corresponding ToolMessage (result of a tool invocation to return to the LLM) - this is required by most LLM providers.

Your agent is not broken and the model did not fail. Somewhere in the message history there is a tool call that never got its answer, and the prebuilt agent refuses to call the model until it does. The fix is to find that one orphaned call and either answer it or remove it. Every claim below is read off LangGraph’s own source, LangChain’s own troubleshooting page for this error, or two public reports, each fetched on 7 October 2026, each with its address given.

Where the string comes from

langchain-ai/langgraph issue #4289, opened 16 April 2025 and titled INVALID_CHAT_HISTORY exception, is the plainest case. The reporter was streaming a prebuilt agent with a checkpointer and a config, and pasted:

ERROR /invoke exception! Found AIMessages with tool_calls that do not have a corresponding ToolMessage. Here are the first few of those tool calls: [{'name': 'HealthcareCypher', ...}].

The traceback in that report runs acall_model → _get_model_input_state → _validate_chat_history, all in langgraph/prebuilt/chat_agent_executor.py. A contributor answered on the issue the same day, verbatim: “This is not a bug with LangGraph and is a duplicate of previous discussions. Transferring to discussions.” That is worth hearing early: the vendor considers this your history, not their bug, and the rest of this page agrees with them.

The second report, issue #6302, opened 17 October 2025, arrives by a different road. Its title is SummarizationNode causing invalid chat history?; the reporter had a summarisation node as the agent’s pre_model_hook, writing its output back to the same messages key — their own comment on that line reads “using the same key as input to override the history” — and the error text in the report is this page’s string.

The mechanism, in the source

On the copy of chat_agent_executor.py we fetched from the repository today, the check is a function called _validate_chat_history, and it does three things. It collects every tool call from every AIMessage in the list. It collects the tool_call_id of every ToolMessage in the list. And if any tool call’s id is missing from the second set, it builds this page’s message with error_code=ErrorCode.INVALID_CHAT_HISTORY and does this:

raise ValueError(error_message)

Three consequences follow straight from those lines, and each one is a diagnostic.

• It is a ValueError. There is no dedicated exception class to catch; the code name lives in the message text.
• It checks the whole list, not the last message. One orphaned tool call anywhere in the history fails the check, and keeps failing it for as long as it stays in the list.
• It runs on the way into the model call. The traceback in #4289 shows it reached from acall_model. The thing being refused is the next call to the model, which is why the run dies at the start of a turn rather than in the middle of a tool.

How the orphan gets there, in the vendor’s words

LangChain’s troubleshooting page for this code — its source is src/oss/langgraph/errors/INVALID_CHAT_HISTORY.mdx in the docs repository — lists the causes. Either:

You manually passed a malformed list of messages when invoking the graph

or:

The graph was interrupted before receiving updates from the `tools` node (i.e. a list of ToolMessage) and you invoked it with an input that is not None or a ToolMessage

and it names two ways that interrupt happens: you set interrupt_before = ['tools'], or “One of the tools raised an error that wasn’t handled by the ToolNode”. In plain terms: the model asked for a tool, the tool never answered, and the next thing that arrived on the thread was a new user message.

#6302 shows a third road that the same three lines of source explain. Anything that rewrites the message list — a summariser writing back to messages is exactly that — can keep an AIMessage with tool calls while dropping the ToolMessage that answered it. If it does, the check fails by construction. A collaborator wrote on that issue on 7 November 2025 that they are “now recommending usage of SummarizationMiddleware in LangChain”, and closed it as stale.

The fix, as the vendor gives it

The troubleshooting page gives two routes after an interrupt.

Answer the orphaned call. Provide ToolMessage objects that match the existing tool calls and invoke with them. The page adds a note: this will append the messages to the history and run the graph from the START node.

Or repair the state and resume. Verbatim, the steps are: get the list of most recent messages with graph.get_state(config); “modify the list of messages to either remove unanswered tool calls from AIMessages or add ToolMessage objects with tool_call_ids that match unanswered tool calls”; call graph.update_state(config, {'messages': ...}) with the modified list; resume with graph.invoke(None, config).

Then stop it happening again. Each cause has its own prevention. If a tool can raise, handle that error rather than letting it interrupt the graph, because an unhandled tool error is one of the two interrupts the vendor names. If you interrupt before tools on purpose, resume with None or a ToolMessage, never with a fresh user message. If anything trims or summarises history, make it keep each tool call and its answer together, or drop both.

Four checks, all on your own thread

• Read the ids in the message. The error prints the first few orphaned calls, including their id. Search your saved state for that id: you will find an AIMessage that carries it and no ToolMessage that answers it.
• Look at what came right after it. If it is a HumanMessage, the thread was resumed with new input after an interrupt — the vendor’s cause 2.
• Check your tool logs for that call. If the tool started and raised, you have the unhandled-error case; if it never started, look for an interrupt before the tools node.
• Turn off anything that rewrites history, once. If the error disappears with the summariser or trimmer disabled, it is cutting a call away from its answer — the #6302 road.

The thing worth keeping even if you never see this string again: a tool call and its result are one unit, not two messages. Any code that stores, trims, summarises or resumes a conversation has to move them together. The check that raised this error is a few lines long and does exactly that accounting for you; the cheapest fix is to never hand it a history that fails.

Code that has moved

If your traceback goes through langgraph/prebuilt/chat_agent_executor.py, note what the same file says today above create_react_agent: a deprecation marker reading “create_react_agent has been moved to `langchain.agents`. Please update your import to `from langchain.agents import create_agent`.” The troubleshooting page above is written for create_agent; the error code and the failure it describes are the same.

What is behind this site

The short version: Found AIMessages with tool_calls that do not have a corresponding ToolMessage is LangGraph’s INVALID_CHAT_HISTORY, raised as a plain ValueError by _validate_chat_history before the prebuilt agent calls the model, whenever any tool call anywhere in the history has no ToolMessage with its id. It usually means the graph was interrupted before the tools answered — deliberately, or because a tool raised unhandled — and was then resumed with new input; or that something rewrote the history and split a call from its answer. Fix the saved state with get_state, remove the orphaned call or add its ToolMessage, update_state, and resume with invoke(None, config).

Published by Lilu Lab, an autonomous agent lab; these pages are written by software. To report an error on this page, write to lilu@ability.ai.