Spring AI 2.0.0 Goes GA
Spring AI 2.0.0 reached general availability on June 12, 2026, marking a significant milestone for Java teams building AI-powered applications. The release ships with a Spring Boot 4.0/4.1 and Spring Framework 7.0 baseline, meaning it requires Java 17 at minimum and brings in Jackson 3 along with full JSpecify null-safety annotations throughout the codebase — welcome improvements for teams relying on static analysis and IDE null checks.
The most impactful architectural change is how tool execution is handled. In Spring AI 1.x, the tool-call loop was embedded inside each individual ChatModel implementation, leading to inconsistent behaviour across providers. Spring AI 2.0 lifts this out into a first-class advisor component — ToolCallingAdvisor — that sits in the standard advisor chain and handles the iterate-call-append-resubmit cycle regardless of which model backend is in use. OpenAI, Anthropic, Google GenAI, Amazon Bedrock, Mistral, DeepSeek, and Ollama are all supported under this unified abstraction, and the number of provider-specific implementation variants has been trimmed: OpenAI drops from three implementations to one, and Anthropic from two to one.
MCP integration is a first-class citizen in 2.0. The release ships with MCP Java SDK 2.0.0, compliant with the latest specification, and introduces three new annotations — @McpTool, @McpResource, and @McpPrompt — for annotation-driven server authoring. Streamable HTTP is now the default transport, replacing the previous STDIO default, which aligns with how production MCP deployments are typically deployed behind reverse proxies. OAuth 2.0 and API-key security are baked in alongside OpenTelemetry metrics so teams get observability from day one.
Developers upgrading from 1.x should budget time for the breaking changes. The .options segment in application property keys has been removed, toolNames() and SpringBeanToolCallbackResolver are gone (tools must now be registered as ToolCallback beans and passed explicitly via .tools()), and the ad-hoc tool loops that lived in each chat model no longer exist. The payoff is a coherent, predictable API surface: ChatClient is the user-facing entry point for conversational and agentic flows, while ChatModel drops to a lower-level building block for custom integrations.
Composable Tool Calling in Spring AI 2.0: How It Actually Works
Alongside the GA announcement, the Spring team published a detailed walkthrough of the new tool-calling architecture that is worth reading separately even if you already reviewed the release notes.
The core of the design is ToolCallingAdvisor, a recursive advisor that iterates until the model returns a response with no pending tool calls. On each pass it extracts tool definitions from @Tool annotations, java.util.Function implementations, or ToolCallback beans; sends the accumulated conversation history to the LLM; executes any tools the model requests via ToolCallingManager; appends the results; and re-enters the loop. Both blocking (.call()) and streaming (.stream()) modes are fully supported, and the advisor exposes four extension points — doInitializeLoop, doBeforeCall, doAfterCall, and doFinalizeLoop — for teams that need approval gates or conditional routing between iterations.
For applications with large tool libraries, the team introduced ToolSearchToolCallingAdvisor, which implements progressive tool disclosure. Rather than sending all tool definitions upfront — a pattern that can consume 10–21K tokens per request with large MCP setups — this advisor exposes a built-in toolSearchTool that the model can call with a natural-language query to retrieve only the relevant definitions on demand. In benchmark runs across OpenAI, Anthropic, and Gemini, this cut token consumption by 34–64% without measurable accuracy degradation. It can be enabled entirely through configuration:
spring.ai.chat.client.tool-search-advisor.enabled=true
spring.ai.chat.client.tool-search-advisor.tool-index-type=vector
A notable addition is AugmentedToolCallbackProvider, which wraps a tool object and intercepts the model's tool arguments before execution. When combined with an AgentThinking argument type, each tool call carries an innerThought field that the model populates with its reasoning — effectively structured chain-of-thought that your application can log, display, or route on without post-hoc parsing.
The memory placement story is also clarified: whether MessageChatMemoryAdvisor goes before or after ToolCallingAdvisor in the chain determines whether full tool transcripts (both requests and responses) are persisted. Teams that want compact conversation histories can place memory before tool-calling; teams building audit trails should place it after.
