[Bug]: CodeActAgent drops assistant tool-call metadata during handoff, leaving an orphan tool response

Finding: In an external report, a CodeActAgent handing off to a FunctionAgent inside an AgentWorkflow stored an assistant message without its tool-call block. The following tool result kept its tool_call_id, so the receiving agent saw an orphan tool response. The reported version is llama-index-core 0.14.25 at commit 6dd2f3cd; other versions are unknown (https://github.com/run-llama/llama_index/issues/23438). Reported conditions: two agents, a CodeActAgent allowed to hand off and a receiving FunctionAgent. The CodeActAgent's function-calling LLM selects the workflow's handoff tool, and the agents share workflow memory. The reporter says no code needs to be generated or executed. They also say it affects both streaming=False and streaming=True, and both ToolCallBlock and additional_kwargs tool_calls representations (issue #23438). Observed in the reporter's mock-based script: memory held an empty-text assistant message, followed by a tool message with tool_call_id handoff-1. The original tool_call block was absent. A local strict validator then raised the error 'Provider rejects orphan tool response: handoff-1'. The reporter states this error comes from their validator, not from a live provider API. Whether real providers reject this history was not demonstrated in the issue. Reporter's hypothesis, not maintainer-confirmed: CodeActAgent.take_step rebuilds the assistant message as ChatMessage(role="assistant", content=full_response_text), which drops non-text blocks and additional_kwargs. The handoff still runs because the separate tool_calls list in AgentOutput drives execution. The reporter contrasts this with FunctionAgent.take_step, which stores the LLM message directly (issue #23438). Diagnostic hint, if you see this pattern: inspect the memory after a CodeActAgent handoff and check whether the assistant message preceding the handoff tool result still contains the tool-call block or tool_calls metadata. This is the reporter's observation method, not a verified procedure. Fix status: proposed only. The reporter suggests storing chat_response.message in the scratchpad and returning it, and links a fork commit (https://github.com/dakjdakd/llama_index/commit/702a07f6882ef0bf90954ba72049797f815eda41). The commit was not reviewed here. No upstream PR, merge or release is shown, and the issue was open with no comments at the time of the data. Limitations: this is an external report; KFA did not reproduce it. The evidence uses mock LLMs and a local validator. No workaround is given.