Repository navigation
Description
♻️ Reproduction Steps
- Set up a CopilotKit v2
<CopilotChat>with an AG-UIHttpAgentbackend that has server-side tools (e.g., MCP tools) - Send a message that triggers a tool call (e.g., "What's the weather in Seattle?")
- Agent streams:
TOOL_CALL_START→TOOL_CALL_ARGS→TOOL_CALL_END→TOOL_CALL_RESULT→TEXT_MESSAGE_*→RUN_FINISHED - First turn completes successfully — user sees the tool result and text response
- Send a second message (e.g., "What is 5 * 33?")
- Backend receives the conversation history and returns 400 Bad Request from the LLM provider
Root Cause
When CopilotKit replays the conversation history on the second turn, it sends the messages array to the AG-UI backend without the tool result message. The history looks like:
user: "What's the weather in Seattle?"
assistant: [tool_calls: [{id: "call_abc", function: {name: "get_weather", ...}}]]
assistant: "The weather in Seattle is 15°C and partly cloudy."
user: "What is 5 * 33?"
The correct history should be:
user: "What's the weather in Seattle?"
assistant: [tool_calls: [{id: "call_abc", function: {name: "get_weather", ...}}]]
tool: {tool_call_id: "call_abc", content: "Seattle: 15°C, partly cloudy"}
assistant: "The weather in Seattle is 15°C and partly cloudy."
user: "What is 5 * 33?"
The tool result message for call_abc is completely absent. This causes both OpenAI and Azure OpenAI to reject the request with a 400 error because tool_calls in the assistant message have no corresponding tool result.
✅ Expected Behavior
CopilotKit should persist TOOL_CALL_RESULT events in its internal conversation state and include the corresponding tool role messages when replaying history to the backend on subsequent turns.
❌ Actual Behavior
Tool result messages are dropped from the conversation state. On the second turn, the backend receives assistant(tool_calls) followed directly by assistant(text) with no tool(result) in between. The LLM provider (OpenAI/Azure OpenAI) rejects this with a 400 error.
Error from Azure OpenAI Responses API:
Code: agent_run_error_event
Message: An internal error has occurred while streaming events.
The underlying cause is a 400 from the LLM because the message history violates the constraint that every tool_calls entry must have a matching tool result message.
Workaround
We subclass AgentFrameworkAgent on the backend to inject synthetic tool result dicts into the raw messages before they enter the library pipeline:
class ToolGapFixAgent(AgentFrameworkAgent):
async def run(self, input_data):
messages = input_data.get("messages")
if messages:
input_data = {**input_data, "messages": fix_tool_gaps(messages)}
async for event in super().run(input_data):
yield eventWhere fix_tool_gaps scans for assistant messages with tool_calls not followed by a tool result, and injects synthetic ones.
Environment
@copilotkit/react-core: 1.55.3
@ag-ui/client: 0.0.52
agent-framework-ag-ui: 1.0.0b260311 (Python backend)
LLM provider: Azure OpenAI (Responses API)
Transport: AG-UI HttpAgent via agents__unsafe_dev_only prop
Frontend Setup
const agent = new HttpAgent({ url: "/ag-ui" });
<CopilotKit
runtimeUrl="/ag-ui"
agent="my-agent"
agents__unsafe_dev_only={{ "my-agent": agent }}
useSingleEndpoint={false}
>
<CopilotChat />
</CopilotKit>Related Issues
- 🐛 Bug: Conversation getting stuck with
tool_useids were found withouttool_resultblocks Anthropic error #2504 —tool_useids withouttool_resultblocks (different root cause but same symptom) - Agent text response lost when multiple tool calls in single turn (dedup replaces text + earlier tools) #3470 — tool calls lost in single turn dedup (UI-side, different bug)
- Sub-agent intermediate tool calls disappear from CopilotKit UI after task completion (deepagents) #3462 — sub-agent tool calls disappear from UI after completion
Activity
copilotkit-support-bot commentedon Apr 14, 2026
The issue is caused by
TOOL_CALL_RESULTevents not being persisted into the internal conversation state, leading to missingtoolrole messages on subsequent turns and a 400 from the LLM provider. The fix is to handleonToolCallResultEventin theStateManagerand add atoolmessage to the agent's history, or apply a frontend workaround that injects the missing messages.Details
To address the missing
TOOL_CALL_RESULTmessages in the conversation history when using AG-UI with CopilotKit v2, it appears theStateManagerin@copilotkit/coreis missing a handler for theTOOL_CALL_RESULTevent. While other message types trigger anonNewMessagenotification (which persists them to the internal conversation state),TOOL_CALL_RESULTevents are currently processed by the UI for rendering but are not being persisted back into the agent's message history.Root Cause Analysis
In
packages/core/src/core/state-manager.ts, thesubscribeToAgentmethod sets up listeners for various agent events. It currently handlesonNewMessage,onStateSnapshotEvent,onMessagesSnapshotEvent, etc., but does not include a handler foronToolCallResultEvent.Because
TOOL_CALL_RESULTis a protocol-level event that represents a message with thetoolrole, it must be added to the agent's message list to ensure that subsequent turns include the necessary tool output for LLM validation (avoiding the 400 Bad Request error).Recommended Solution
You can resolve this by adding an
onToolCallResultEventhandler to theStateManagersubscription. This handler should callagent.addMessagewith a message of roletool.In
packages/core/src/core/state-manager.ts:Alternative Workaround (Frontend)
If you cannot modify the core library, you can apply a similar fix by subscribing to the agent directly in your React application and manually injecting the missing messages:
Sources & Documentation
Confidence Assessment: High. The absence of the
onToolCallResultEventlistener inStateManagerdirectly explains why these specific messages aren't being tracked in the conversation history between turns.Was this helpful?
If this solution worked for you, please click on the appropriate option below to help us improve:
✅ This was helpful | ❌ Need more help
copilotkit-support-bot commentedon Apr 14, 2026
👋 Thanks for your feedback!
I've escalated this issue to our development team. Someone from our team will review your request and provide additional assistance shortly.
If this is blocking production, please book a meeting with us at https://cal.com/nathan-tarbert-copilotkit/15min
fix(core): subscribe to ToolCallResultEvent in StateManager
khchan commentedon May 1, 2026
Thank you @nebrass! I'm experiencing exactly the same issue with Microsoft Agent Framework and CopilotKit 🙏
Can you share how
fix_tool_gapslooked like for your workaround?djw-bsn commentedon May 11, 2026
We also have the same issue with Agent Framework and Copilotkit. At the moment we are having to patch the messages in our backend
fix(core): subscribe to ToolCallResultEvent in StateManager
linear commentedon Jul 21, 2026
OSS-529
fix(core): preserve tool results in subsequent-turn history (CopilotK…
fix(core): preserve tool results in subsequent-turn history (CopilotK…
fix(core): preserve tool-result run ownership after rework (CopilotKi…
fix(core): keep exactly one tool result per tool call across message …
BenTaylorDev commentedon Sep 30, 2026
Closing this: the root cause was in Microsoft Agent Framework's AG-UI adapter, not CopilotKit. Its final snapshot reused the text message's id for the tool-call message, so the history came back out of order and the adapter's tool-history sanitizer then dropped the tool result, which is what produced the 400. It's fixed in
agent-framework-ag-ui>= 1.2.0 (microsoft/agent-framework#7223), and @nebrass confirmed on #3885 that the two-turn flow now works. If you still hit it on 1.2.0+, reopen with your versions.