Spring AI 2.0's Five Major Updates: How Java Backends Can Break Into Agent Development

Spring AI 2.0's release has generated considerable discussion in the Java backend community, but there are really only five updates worth paying attention to. A Bilibili creator broke down these changes one by one in a hands-on course share, and laid out a learning path from multi-model integration to MCP development. This article combines their perspective to sort out the core changes in Spring AI 2.0 and the realistic choices for Java developers breaking into Agent development.

Version Baseline Raised: The Cost of Spring Boot 4 + Spring 7

The first update is the hard raise of the version baseline: Spring AI 2.0 drops Spring Boot 3 and Spring 6, and must be based on Spring Boot 4 and Spring 7. According to this creator's observation, Spring Boot 4 and Spring 7 themselves don't bring many enticing new features, and this "updating for the sake of chasing versions" approach left them rather averse.

The more realistic trouble lies in the toolchain. Spring Boot 4 requires IDEA 2025 or above, meaning developers have to complete a full environment upgrade before writing the first line of AI code. Compatibility of third-party middleware is also unknown—whether the various components your project depends on can migrate smoothly needs to be verified one by one.

For enterprise projects, this upgrade cost cannot be ignored. If existing systems run stably on Spring Boot 3, rushing to follow 2.0 may bring unnecessary migration risk. A more pragmatic approach is to first validate in small-scale projects or learning environments, then evaluate the upgrade timing for production environments.

Tools Parsing Moved Up: From Black Box to Observable

The second update was rated "very good" by this creator. To better support React Agent, Spring AI 2.0 refactored the Tools design: previously Tools parsing happened in the underlying Chat Model, and now it has been moved up to the upper-layer Chat Client's Advisor.

This change brings two direct benefits. One is observability—the information passed by Tools can be monitored through the logging Advisor. In the old version, Tools parsing was hidden in the underlying Chat Model, and the upper-layer logging Advisor couldn't see at all what information Tools actually passed to the LLM—it was a complete black box. Now it can be viewed intuitively through logs, making troubleshooting much easier.

The second is laying the foundation for the Agent mechanism. Based on the built-in Function Calling recursive Advisor, a "observe—think—act" loop can be implemented: continuously iterating and self-correcting according to the task until it is completed. This is a very critical step for Spring AI toward Agents.

Function Calling and the ReAct Loop

Function Calling is the fundamental mechanism for LLMs to interact with external tools: developers describe available tools with JSON Schema, the model judges during reasoning whether to call, which one to call, and generates structured parameters, which the host program executes and then passes the results back to the model. Early OpenAI's function calling is basically synonymous with later tool calling.

ReAct (Reasoning + Acting) is the classic paradigm that strings this mechanism into a loop: the model first outputs a Thought, then decides on an Action (i.e., calling a tool), and after getting the Observation result continues reasoning until giving the final answer. The "observe—think—act" loop implemented in Spring AI 2.0 based on the built-in Function Calling recursive Advisor is essentially ReAct. Understanding this makes clear why moving Tools parsing up is a key prerequisite—only when the tool calling process is visible and interceptable in the upper-layer Advisor chain can recursion and logging logic be layered around it.

AgentUtils: An Agent Development Library Comparable to Claude Code

The third update is that Spring AI designed an AgentUtils Agent development library. According to this creator, this is a "reverse-engineered Claude Code" Agent tool library that helps developers build Agents better, and it must be used with Spring AI 2.0.

The positioning of this library is worth pondering. It encapsulates common patterns in Agent development into tools, lowering the barrier to building an Agent loop from scratch. But note that it strongly depends on Spring AI 2.0, meaning adopting it requires accepting the aforementioned version baseline raise.

Why Claude Code's Agent Design Is Being Borrowed

Claude Code is Anthropic's in-terminal coding Agent, whose architectural approach has had great influence in the Agent engineering community: the core is a minimalist "model + tools" loop, with the toolset mainly consisting of basic capabilities like file read/write, Shell execution, and search; a large amount of behavioral constraints are not written in code but in the system prompt and project-level config files (such as CLAUDE.md); mechanisms like sub-Agent dispatch, context compression, and permission confirmation control the context and security boundaries of long tasks.

The so-called "reverse-engineered Claude Code" Agent libraries usually abstract this pattern into reusable components: loop scheduler, tool registration and execution, context management, interruption and human confirmation, etc. For Java developers, this means not having to design the Agent main loop from scratch, but focusing on tool implementation and business orchestration; however, note that such libraries often carry assumptions about specific models, and after switching models the prompts and tool descriptions may need re-tuning.

MCP Transport Protocol Replacement: Streamable HTTP Replaces SSE

The fourth update is the change in MCP transport: Streamable HTTP replaces the deprecated SSE and becomes the default transport protocol. SSE's limitations in long-connection scenarios have long been discussed, and the switch to Streamable HTTP follows the evolution direction of the MCP ecosystem.

For Java teams currently developing MCP servers or clients, this means checking whether existing implementations depend on SSE and adjusting in time. New projects can start directly on the default protocol, reducing later migration costs.

The Relationship Between MCP, SSE, and Streamable HTTP

MCP (Model Context Protocol) is an open protocol proposed by Anthropic for letting AI applications connect to external tools, data sources, and prompt templates in a unified way, roughly analogous to "the LSP of the AI world." It defines the JSON-RPC message format between Server and Client, while the transport layer is responsible for how these messages travel.

The original remote transport was based on HTTP + SSE: the client first establishes an SSE long connection to receive server pushes, then sends requests via a separate HTTP POST, requiring maintenance of two endpoints and a persistent connection, which is cumbersome in load balancing, gateway, and reconnection scenarios. Streamable HTTP merges the two into a single endpoint, where the server can return SSE events or plain JSON in the same response stream as needed, and supports session resumption, being friendlier to stateless deployment. Therefore the MCP specification set it as the default transport, and the SSE transport was marked as deprecated.

Tool Search: On-Demand Loading Saves Tokens

The fifth update adds an on-demand Tool Advisor called Tool Search Tool Calling Advisor. Before requesting the LLM, it retrieves Tools relevant to the current conversation based on the current task's prompt, and only sends the relevant tools to the LLM.

This both saves tokens and effectively reduces noise and improves reasoning quality. When the number of tools is large, injecting all Tool definitions occupies a lot of context, and on-demand retrieval is a practical optimization direction.

Context Pressure from Tool Count Expansion

A major hidden cost of tool calling is the token overhead of the tool definitions themselves. Each tool's name, description, and parameter Schema must be written into the system prompt or request body; when the number of tools reaches dozens or hundreds, definitions alone may occupy thousands or even tens of thousands of tokens, which both increases cost and dilutes the model's attention to information relevant to the current task, leading to wrong tool selection or unstable parameter generation.

Tool Search's approach is to make tool retrieval a pre-step: first use the current conversation's prompt to do relevance retrieval in the tool library (could be vector retrieval or keyword matching), and only inject the definitions of the Top-K relevant tools into the request. This is isomorphic to the idea of RAG retrieving documents, except the retrieval object changes from knowledge snippets to tool descriptions. The cost is an extra retrieval overhead, and when retrieval recall is inaccurate it may miss necessary tools; in practice, it is usually necessary to keep core tools always injected as a fallback.

Spring AI's Positioning: Do the Foundation Well, Leave the Upper Layer to Agent Frameworks

This creator's overall judgment on Spring AI 2.0 is: apart from the above five points, there aren't many highlight new features. What could really move them to use 2.0 might be developing Agents with AgentUtils, but there are quite a few Agent frameworks in the Java ecosystem—Spring AI Alibaba Agent Framework, AgentScope, and others are all doing well.

In their view, Spring AI's positioning is very clear: it only does basic integration with various LLMs and basic implementations of Tool, MCP, and RAG; the higher-layer Tool Advisor is left for Agent extensions. In their words, Spring AI treats itself as the foundation, and developers extend on top, "each fighting their own battles, doing well in the areas they're good at."

This positioning has practical guidance for Java backend developers: don't expect Spring AI to handle all the capabilities of enterprise-grade Agents; treat it as the model integration layer and tool calling layer, and choose more specialized frameworks for Agent orchestration logic according to project needs.

Learning Path for Java Backends

The route given by this creator covers the complete chain from LLM selection and fine-tuning, to AI development Agent frameworks, and then to project practice; the hands-on projects include intelligent customer service, RAG knowledge bases, workflow development for vertical Agents, and deployment. For Java backends, the reasonableness of this path lies in: first master model integration and the basic capabilities of Tool/MCP, then move into RAG and Agent orchestration, and finally land on specific business scenarios.

It should be noted that the "free sharing" materials mentioned in the course promotion are only this creator's personal act; readers should judge the quality and applicability of the materials themselves, and the core is still to return to official documentation and hands-on verification.

FAQ

Does Spring AI 2.0 require upgrading to Spring Boot 4? Yes, 2.0 mandatorily requires Spring Boot 4 and Spring 7, and cannot be used in a Spring Boot 3 environment.

After Tools parsing is moved up, does old code need changes? If you rely on the Tools parsing behavior of the underlying Chat Model, you need to check the Advisor chain configuration to ensure log monitoring and recursive calls work under the new mechanism.

Can MCP's SSE still be used? SSE has been deprecated, and the default transport protocol has changed to Streamable HTTP; it is recommended that new projects adopt the new protocol directly.

One-line Summary

Five updates worth watching in Spring AI 2.0 and the path for Java developers to break into Agents.

Paragraph Summary

The article sorts out the five updates in Spring AI 2.0 truly worth watching: the version baseline and toolchain cost brought by the mandatory upgrade to Spring Boot 4 and Spring 7; Tools parsing moved up from the underlying Chat Model to the Chat Client Advisor, solving the black-box problem and laying the foundation for a ReAct-style Agent loop; the launch of the reverse-engineered Claude Code AgentUtils development library; the MCP default transport protocol changed from SSE to Streamable HTTP; and the new Tool Search Advisor for on-demand tool loading to save tokens. The author agrees with Spring AI's positioning of "only doing the foundation," suggesting developers treat it as the model integration and tool calling layer, leave upper-layer Agent orchestration to more specialized frameworks, and provides a learning path from model integration to RAG and Agent practice.