Make ToolCallAdvisor the default tool call management option

[tzolov]

Currently, the tool-call lifecycle is managed internally by each concrete ChatModel implementation.

The ToolCallAdvisor allows you to manage this lifecycle as a part of the Advisor chains. The latter provides clear visibility for the tool request and response messages, allowing manipulation and storing of those messages in Memory. This is a requirement for many AI and Agentic use cases.

When the ToolCallAdvisor is added to the chain (e.g. ChatClient.advisors(ToolCallAdsvior.builder()...), it disables the low-level ChatMemory tool handling implementations. The proposal is to auto-register the ToolCallAdvisor by default when there are registered ChatClient Tools or tool callbacks.

Also a the toolcall advisor should disable its internal conversation memory support if there are ChatMemory advisors registered after it in the chain.

[aks151]

Hi @tzolov can i pick it up?

[bkoragan]

@tzolov @sdeleuze
I was triaging #5792, which reports that when streamToolCallResponses(true) is enabled on ToolCallAdvisor, the AssistantMessage with tool call requests is emitted in the Flux, but the corresponding ToolResponseMessage (the tool's actual result) is consumed internally and never surfaced to the consumer.

This issue aligns with my observations. Both stem from the same root: the tool-call lifecycle is not fully transparent to consumers. #5792 is the symptom (incomplete streaming output), and this is more of the architectural fix (making ToolCallAdvisor first-class so the full lifecycle is visible through the advisor chain).

I'd like to propose the following solution:

1. Auto-register ToolCallAdvisor when tools are present:
   when tools or tool callbacks are registered on ChatClient, auto-register ToolCallAdvisor into the advisor chain that making the advisor chain the single path for tool-call handling & removing the hidden model level loop.. If a user explicitly provides their own ToolCallAdvisor (e.g. with custom streamToolCallResponses or ToolCallingManager settings), skip the auto-registration to respect their configuration.

2. Disable internal conversation memory when a ChatMemory advisor follows:
   Auto-detect if a ChatMemory advisor is registered after ToolCallAdvisor in the chain, and if so, disable conversationHistoryEnabled to avoid duplication or conflicts in conversation history management.

3. Emit ToolResponseMessage in the stream (addresses this The toolCalls of ChatResponse are always empty, with no tool call information whatsoever #5792):
   when streamToolCallResponses = true, emit a synthetic ChatClientResponse containing the ToolResponseMessage into the Flux right after tool execution. so consumers see the complete round-trip: tool call request > tool response > model's final result/answer. This is gated behind the existing flag, so default behavior stays unchanged.

If this direction looks good, I'd be happy to open a PR for it.