Spring AI Tool Call with Spring Boot Wizard

1. Execution-Based Architecture Using Spring AI SDK for Healthcare Applications

Integrating LLM into backend systems is no longer about building chat interfaces — it’s about embedding intelligent decision making into production services.

However, the LLM introduces fundamental limitations:

They can consider actions, but they can’t execute backend logic safely.

This creates a critical gap:

• LLM cannot access the database directly
• They may hallucinate in response
• They cannot enforce business rules
• They do not have deterministic execution

This challenge becomes even more important healthcare applications, where accuracy, data integrity and security are non-negotiable.

To overcome this, a system is needed where:

• The LLM decides what should happen
• The backend system does what needs to happen

This is what the Spring AI Tool Call makes possible.

It introduces a structured architecture where:

Spring AI SDK acts as an execution bridge between LLM reasoning and backend systems

2. Execution Flow Diagram

3. Spring AI SDK Setup (Foundation Layer)

Spring AI provides runtime infrastructure for tool calls inside Spring Boot.

Without it, you need to handle manually:

• tool schematic
• JSON parsing
• execution routing
• context injection

Maven Dependencies

<dependency>
  <groupId>org.springframework.ai</groupId>
  <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
  <version>1.0.0</version>
</dependency>

application.yml

spring:
ai:
  openai:
    api-key: ${OPENAI_API_KEY}
    chat:
      options:
        model: gpt-4.1-mini
        temperature: 0.2

Chat Client Configuration

@Configuration
public class AIConfig {

  @Bean
  public ChatClient chatClient(ChatClient.Builder builder) {
      return builder
              .defaultSystem("You are a backend AI assistant with tool access.")
              .build();
  }
}

Why Chat Clients Matter

ChatClient is not just an API wrapper.

He:

That execution gate That:

• send instructions to LLM
• register tool
• managing tool execution loops
• inject the tool results back

4. Problem: Why Backend + LLM Fails Without Tool Call

No Tool Calls

• LLM produces answers without real data
• Backend logic leaks into commands
• There is no guarantee of execution
• There is no validation layer

Example

User: “What medication am I taking?”

LLM: guess → wrong → unsafe

With Call of Spring AI Tools

• LLM selecting tools
• Backend execution tools
• Responses are based on real data

5. Core Concept: Tool Call (Spring AI Model)

Spring AI introduces a controlled execution loop:

Step 1: LLM Reasoning

LLM analyzes input: “Users need treatment data”

Step 2: Tool Selection

LLM returns:

{
"tool": "GetMedicationsTool",
"arguments": {
  "userUuid": "123"
}
}

Step 3: Execution (Spring AI)

• complete the tool nut
• inject parameters
• execute method

Step 4: Response Injection

The tool output is returned to the LLM context.

Step 5: Final Response

LLM produces a grounded response.

Key Principles

LLM = decision engine
Backend = execution engine

6. Why This Is Important in the Health Care System

In healthcare applications, backend systems handle sensitive and regulated data such as patient records, medications, and clinical observations.

In an environment like this:

• Incorrect responses can impact patient safety
• Data must come from trusted and auditable sources (EHR systems, databases)
• Strict access controls (for example, userUuid) are required
• All actions must be deterministic and traceable

This makes the use of traditional LLMs (which may hallucinate or ignore backend rules) unsuitable for production healthcare systems.

Spring AI Tool Call ensures that:

LLM never accesses critical data directly — it only decides which verified backend tools to run.

This guarantees:

• Data is always taken from real backend systems
• Business rules are still enforced
• The response is safe and reliable

What We Will Build Next

Next, we’ll implement a healthcare chatbot using Spring AI, showing how tool invocations connect backend services, invoke domain-specific tools, and generate secure, context-aware responses.