Managing confirmation dialogs in Spring AI tool execution with RAG-based selection

Other Questions ai employee
1

I’m working on a project with Spring Boot 3.4.5 and Spring AI 1.0.0 connected to Llama3.2 through Ollama. My setup uses function calling with RAG to dynamically choose which tools to send to the language model.

The issue I’m facing is with confirmation workflows. Here’s what happens:

User: Create account - Username: Alice, Email: [email protected]  
Bot: Account preview ready: {...}. Should I create this account?  
User: Yes → Need to complete the account creation

My RAG pipeline works great for the initial request by doing semantic matching on tool descriptions. But when users respond with simple confirmations like “yes”, “okay”, or “continue”, the system can’t figure out which tool to use anymore since these responses don’t have enough semantic meaning.

I have ChatMemory configured to track the conversation, but the confirmation phase breaks my tool selection because the user input is too generic. The RAG can’t match “yes” to the right function.

The real challenge comes with function calling specifically. While basic conversational RAG with ChatMemory handles follow-ups fine, tool selection gets tricky when users ask follow-up questions like “update the username” or “what email was that?” after the initial tool call. Each tool needs to handle these varied follow-up scenarios, making state tracking complicated.

How can I handle confirmation responses in Spring AI function calling while preserving the original context and avoiding re-running tool filtering?

2

I hit this exact issue building a document processing system with Spring AI. Here’s what worked for me: create a conversation state manager between your RAG pipeline and function calling logic. The trick is keeping a pending action context alongside your ChatMemory. When RAG picks a tool but needs confirmation, save the tool reference and parameters in a temp state object tied to that conversation session. Then route confirmation responses straight to execute that pending action - skip RAG entirely. For follow-ups like “update the username”, I extended each tool function with a context parameter that includes conversation state. This way individual tools can handle their own follow-up scenarios while accessing previous parameters and user intents. For implementation, use Spring’s session scope or Redis to store pending action state. Check for pending actions before invoking RAG - if there’s one and the user input looks like confirmation, execute directly. If not, clear pending state and run normal RAG tool selection. This kept my confirmation workflows smooth without breaking semantic matching for new requests.

3

Same issue here with my chatbot. Fixed it by adding a state flag to the conversation context - something like “awaitingConfirmation” plus the tool name. When the user says yes/ok, just check the flag and run the stored tool directly. Way easier than dealing with complex state managers.