Spring AI 2.0: Five Key Updates Explained — Stepping into the Agent Era

Spring AI 2.0: An Upgrade with Clear Positioning

Spring AI 2.0 has been out for a while now. As a key framework in the Java ecosystem for connecting to large model capabilities, each of its iterations tugs at the nerves of backend developers. From 0.1 to 1.0, and now to 2.0, Spring AI has gradually clarified its position within the AI application development stack.

It's worth first understanding the background of Spring AI. Spring AI is the application development framework officially launched by Spring amid the wave of generative AI. Its design philosophy is heavily inspired by Python ecosystem frameworks such as LangChain and LlamaIndex, aiming to provide Java/Kotlin developers with a unified, portable set of APIs for interfacing with various large models. Through a portable abstraction layer, it shields the differences between the APIs of different vendors such as OpenAI, Anthropic, Azure OpenAI, and Ollama, allowing developers to invoke models through a consistent ChatClient interface without writing adapter code for each provider. This design carries on Spring's consistent "convention over configuration" and dependency injection philosophy, enabling AI capabilities to naturally integrate into existing enterprise-grade Java application architectures.

According to analysis from a relevant tech content creator on Bilibili, the core updates in Spring AI 2.0 can essentially be summarized into five aspects. Compared with some attention-grabbing "major versions," the Spring AI 2.0 update is more like a pragmatic architectural adjustment—it doesn't pile on flashy but impractical features. Instead, it revolves around one clear goal: supporting Agent development.

This article will break down these five major updates one by one and explore Spring AI's positioning and trade-offs within the overall landscape of Java AI frameworks.

Update One: Mandatory Upgrade to Spring Boot 4 and Spring 7

The most direct—and most controversial—change in Spring AI 2.0 is that it completely abandons Spring Boot 3 and Spring 6, and must run on Spring Boot 4 and Spring 7.

This change sparked some dissatisfaction in the developer community. As the original video author put it: "I really dislike this kind of update done just to chase versions." The problem is that Spring Boot 4 and Spring 7 themselves don't bring many killer new features, yet they impose real migration costs:

You need to upgrade your development tools to IDEA 2025 or later;
There's uncertainty about the compatibility of third-party middleware your project depends on;
The mandatory upgrade of the entire tech stack increases deployment risk.

In other words, before you even start experiencing the new capabilities of 2.0, your team has to first pay the price of a full round of upgrades. For production projects, this "upgrade first, deal with it later" strategy needs careful evaluation. It's worth noting that Spring Boot 4 and Spring 7 comprehensively improve support for JDK 17+ and even new features like virtual threads and GraalVM native images, which in the long run benefits high-concurrency scenarios for AI applications. But in the short term, these benefits are hard to directly offset the pain of migration—and this is the root of the community's controversy.

Update Two: Tools Parsing Lifted Up, Breaking the Black Box

If the first point is a complaint, then the second is widely regarded as the most valuable improvement in Spring AI 2.0.

The second update, I think, is really good

Lifted from ChatModel to ChatClient

In the older version, the parsing of Tools (tool calling) happened in the underlying ChatModel. This brought an obvious problem: the upper-layer logging Advisor could not monitor what information the tools actually passed to the large model, making the entire tool-calling process a black box to developers.

To understand the significance of this improvement, you first need to understand the Function Calling capability. Function Calling (also known as Tool Calling) is a core capability of modern large models: during the process of generating an answer, the model can determine whether it needs to call an external tool (such as querying a database, calling an API, or performing a computation), and output the call parameters in structured JSON. The application layer then executes them and returns the results to the model to continue reasoning. The whole process involves multiple rounds of interaction between the model and the application. If these interaction details are encapsulated in the underlying layer and remain invisible, troubleshooting is like a blind man groping an elephant.

2.0 lifts the parsing of Tools up into the Advisor of the upper-layer ChatClient. The Advisor here is an interceptor mechanism Spring AI designed by borrowing from the aspect-oriented ideas of Spring AOP, allowing developers to insert custom logic before and after a request is sent to the model. This seemingly simple architectural adjustment brings two concrete benefits:

Improved observability: Through the logging Advisor, developers can intuitively view the specific information passed by Tools, so debugging and monitoring are no longer done blindly;
Paving the way for Agents: This change is a key prerequisite for Spring AI's move toward an Agent architecture.

For any developer who has debugged tool calls, the ability to see "what the tool actually passed" is a value that everyone can appreciate.

Update Three: Built-in Agentic Mechanism, Moving Toward Self-Iteration

Based on a built-in Function Calling recursive Advisor, Spring AI 2.0 implements a complete Agentic mechanism.

It's based on the built-in Function Calling recursive Advisor

The Observe–Think–Act Loop

So-called Agentic refers to the ability of an agent to perform an Observe–Think–Act loop based on a task, continuously iterating and self-correcting until the task is completed. This is precisely the core paradigm of current AI Agent development (ReAct).

ReAct (Reasoning + Acting) is a classic Agent paradigm formed on the basis of Function Calling, proposed by Princeton and Google researchers in 2022. It alternates between a "chain of reasoning" and "action," enabling the model to operate on the external environment while thinking, thereby completing complex multi-step tasks. Spring AI 2.0 makes this loop built-in through a "recursive Advisor"—when the model returns a tool call request, the framework automatically executes the tool, backfills the result, and calls the model again, repeating this until the model provides a final answer. Developers no longer need to hand-write this loop control logic.

Going further, Spring AI also introduced an Agent development library called Agent Utils. According to reports, this toolkit "reverse-engineered" the Agent design ideas of Claude Code, aiming to help developers build agents more efficiently. Claude Code is Anthropic's command-line programming assistant, renowned for its elegant task decomposition, context management, and tool-call orchestration capabilities, and is regarded as one of the benchmarks for Agent engineering practice. Note that Agent Utils must be based on Spring AI 2.0 to be used—which may be the main incentive prompting some developers to upgrade.

It can be said that these two updates (lifting Tools up + the Agentic mechanism) together constitute the core narrative of Spring AI's evolution from a "conversation framework" to an "agent foundation."

Update Four: MCP Transport Protocol Switches to Streamable HTTP

The fourth update focuses on the transport layer of MCP (Model Context Protocol).

Replacing the already deprecated SSE

In 2.0, the Streamable HTTP transport method replaces the already deprecated SSE (Server-Sent Events) as the default transport protocol.

MCP (Model Context Protocol) is a standard protocol open-sourced by Anthropic in late 2024, aiming to unify the way large models connect to external tools and data sources. It's dubbed the "USB-C interface of AI applications" by the industry. It defines how servers expose tools, resources, and prompt templates to models, and is being adopted by more and more frameworks and vendors as a de facto standard.

This adjustment stays in sync with the evolution of the MCP protocol itself. Early MCP used SSE as its remote transport method, but SSE is essentially a one-way server push that requires an additional HTTP channel to handle client requests, making it clumsy in terms of session management, bidirectional communication, and reconnection after disconnection. Streamable HTTP, on the other hand, supports both regular request-response and streaming push on a single HTTP endpoint, providing more flexible and stable transport capabilities. For building an MCP-based tool integration system, this is a necessary step of keeping pace with the times.

Update Five: The On-Demand Tool Search Advisor

The fifth update introduces a quite practical component—the Tool Search Tool Calling Advisor, i.e., an on-demand loading tool Advisor.

Replacing Full Injection with Retrieval

The traditional approach is to send the definitions of all available tools to the large model at once, which brings two problems: large Token consumption, and "noise" interference in reasoning caused by too many irrelevant tools.

In enterprise-grade Agent scenarios, the number of tools may reach dozens or even hundreds. Injecting all tool definitions into the context of every request brings serious Token consumption and reasoning interference—a large model's context window is limited and billed by usage. Redundant information not only drives up costs but may also cause the model to face "choice paralysis" among numerous options, reducing call accuracy.

The idea of the Tool Search Advisor is: before requesting the large model, first retrieve the tools most relevant to the current conversation based on the current task's prompt, and only send this subset of tools to the large model. This mechanism borrows the core idea of RAG (Retrieval-Augmented Generation): first vectorize the tool descriptions and store them in a retrieval library, then at runtime perform semantic retrieval based on user intent, recalling only the few most relevant tools. Doing so both saves Tokens and effectively reduces noise, improving reasoning quality.

In enterprise-grade scenarios with a large number of tools, this "tool RAG"-style on-demand loading mechanism is a practical means to improve Agent efficiency and accuracy.

Spring AI's Positioning: Build a Solid Foundation, Let the Upper Layers Shine

Overall, apart from Agent Utils, Spring AI 2.0 doesn't have many disruptive new features. This, in turn, reflects Spring AI's clear-headed awareness of its own positioning.

There's also Agent Scope and Java

Division of Labor with Other Java Agent Frameworks

Today, Agent frameworks in the Java ecosystem are already quite rich. Besides Spring AI, there are multiple choices such as Spring AI Alibaba, Agent Framework, and Agent Scope, each doing well in its own right. Among them, Spring AI Alibaba is maintained by the Alibaba team, deeply integrating domestic models like Tongyi Qianwen with the Alibaba Cloud ecosystem, and investing heavily in multi-agent orchestration; while frameworks like Agent Scope focus more on complex agent collaboration and process orchestration. This flourishing landscape precisely shows that Java is rapidly closing the gap with the Python ecosystem in the field of AI application development.

Against this backdrop, Spring AI chose a clear path:

I only handle the basic integration of various large models, along with the basic implementation of Tool, MCP, and RAG. Application-layer Agent extensions and Context Engineering—you can just treat me as a foundation to extend upon.

The Context Engineering mentioned here is a concept that has attracted much attention recently. It goes beyond mere prompt engineering, emphasizing how to systematically organize, retrieve, compress, and dynamically inject the context information the model needs—including conversation history, retrieval results, tool outputs, and so on—to maximize the model's performance within a limited context window. By leaving this part of the complexity to the upper-layer frameworks, Spring AI reflects its layered, decoupled design orientation.

This "I build a solid base, you build the upper layers" division-of-labor philosophy is actually quite healthy. Rather than pursuing all-encompassing breadth in every direction, it's better to focus on the area you're best at—a stable, standardized large-model access layer. Upper-layer frameworks can then build on this foundation to implement more complex multi-turn conversations, complex orchestration, and agent logic.

Conclusion: A Pragmatic Step, Not a Revolution

Spring AI 2.0 is a pragmatic architectural upgrade: its mandatory version upgrade is uncomfortable, but lifting Tools up, the built-in Agentic mechanism, the MCP protocol update, and on-demand tool loading are all solid steps toward the Agent era.

For Java developers, whether to upgrade depends on your core needs: if you need to develop agents and value Agent Utils, 2.0 is worth investing in; if you're only doing basic model conversations, there's no need to rush to follow before you've assessed the migration costs.

With one restrained update, Spring AI has given its answer within the AI application development stack—to be the most reliable foundation.