Spring AI 2.0 in Practice: A Complete Guide to Building Intelligent Agents with Java

Spring AI 2.0 Core Updates: Native Agent Ecosystem Support

As large model capabilities become widely accessible, Java developers are increasingly looking to build AI-powered applications. The release of Spring AI 2.0 responds directly to this trend — and its most significant update is the native support for building an Agent ecosystem.

An Agent (or intelligent agent) is an AI system capable of autonomous perception, decision-making, and execution. It doesn't just understand user intent — it can independently plan execution steps, invoke tools, handle exceptions, and complete complex tasks end-to-end. Unlike simple chatbots, agents operate in a closed loop of memory, reasoning, and action. Building an agent framework typically requires infrastructure for task decomposition, tool invocation, state management, and multi-turn conversation control — which is exactly the core capability layer Spring AI 2.0 now provides.

In earlier versions of Spring AI, agent development wasn't exactly developer-friendly. You often needed to layer in the Alibaba Agent framework on top of Spring AI to get anything production-ready. Spring AI Alibaba is an enhanced framework built by Alibaba on top of Spring AI, offering Graph (directed acyclic graph) orchestration, multi-agent collaboration, ReAct (Reasoning+Acting) inference, conditional branching, and parallel execution. Before Spring AI 2.0, Java developers building complex agent workflows were almost entirely dependent on these extensions. With 2.0, the foundational agent infrastructure is now built in, letting developers stand up agent capabilities more natively within the Spring ecosystem.

For Java developers who have been in the trenches with the JVM stack, this lowers the barrier to AI application development even further. You no longer need the Python ecosystem to build intelligent applications — Spring AI gives Java the full toolkit.

From Traditional Systems to AI Interaction: Airline Smart Assistant in Practice

The showcase project for this walkthrough is a "Turing Airline Assistant" — a great example of how AI conversation can transform a traditional system.

Traditional event-driven systems follow a GUI (graphical user interface) paradigm. Users navigate through precise clicks, form inputs, and page flows to get things done. Want to cancel a booking? You need to find the right button, locate the right page, and work through a series of steps — high learning curve, easy to get lost in nested menus. Introducing AI-driven conversation (also called NUI, Natural User Interface) simplifies this dramatically: instead of navigating a UI, users describe their intent in plain language. A single message — "Hey, help me cancel my ticket" — and the AI will indirectly invoke the appropriate business method behind the scenes. The fundamental shift is from "user adapts to the system" to "system adapts to the user."

For example, the system has a cancelBooking method that requires a booking number and a name. When the AI needs to call this method, it proactively asks the user for that information, then uses it to complete the cancellation and update the order status from "Booked" to "Cancelled."

The value here is universal: whether you're in healthcare, education, or government services, you can embed an intelligent assistant into any existing system. A user who might spend half an hour hunting for a feature can just ask — the AI tells them exactly where it is, or handles it for them directly.

Tools and MCP: Two Channels for External Capability

To enable large models to call external capabilities, you need to understand how two key technologies divide the work:

Tools: Connecting to Your Internal Systems

Tools are how you connect a large model to your own system. Base models can't call external APIs on their own — they can only answer questions based on what they were trained on. Tools (also known as Function Calling) give the model the ability to "reach outside itself." The mechanism works like this: developers register business method names, descriptions, and parameter schemas with the model. When a user request requires calling one of those methods, the model generates a structured call request (with method name and argument values), the application framework executes the actual call, and returns the result to the model. The cancelBooking example above is exactly this — Tools letting the model indirectly invoke an internal business API.

MCP: Connecting to External Third-Party Services

MCP is designed specifically for large models to interact with external services. MCP (Model Context Protocol) is an open standard proposed by Anthropic to give large models a unified interface for accessing external services. It uses a Client-Server architecture: the MCP Server encapsulates the capabilities and invocation logic of a specific service, while the MCP Client lives inside the AI application and handles service discovery and call coordination. By standardizing the protocol, services from different vendors can be discovered and called by the model in a consistent way — no more writing custom integration code every time you add a new service.

The distinction is clean: Tools face inward toward your own business methods; MCP faces outward toward external, third-party services.

For example, if a user asks the AI to plan a "self-driving route from Chongqing to Qingdao," the system can use a configured Baidu Maps MCP Server to handle the route planning. Developers just configure the Baidu Maps MCP service (which includes capabilities like route planning), and the model can invoke it to deliver a complete itinerary.

Remember the core distinction: one provides internal capabilities, the other provides external capabilities.

Skills: Reusable, Maintainable Prompt Management

Beyond Tools and MCP, the project also demonstrates the use of Skills. For instance, the system includes a built-in "Personal Travel Concierge" that helps users plan itineraries and explore destinations.

Skills are essentially "abilities" that can be cultivated and accumulated. Their value shows up in two main ways:

• Reusing existing skills: When your system needs a mature capability that someone else has already packaged, you can plug it straight in. This is similar to libraries or packages in software development — the community has already wrapped high-quality prompt logic into standardized Skills that other developers can use without starting from scratch.
• Structured prompt management: Skills provide a more disciplined way to maintain prompts (which are essentially Markdown-formatted descriptions), making prompt engineering less scattered and chaotic. In real projects, prompts tend to be scattered throughout the codebase — hard to version-control or iteratively improve. Skills turn them into standalone, version-controlled modules.

With Skills, developers can abstract complex prompt logic into manageable capability modules, making AI applications easier to maintain and extend.

How Java Developers Can Break into AI Development

For the many Java developers wondering how to make the transition into AI, there are two clear paths.

Path 1: Vibe Coding

The first path is using AI to supercharge your existing development work. Vibe Coding is a programming paradigm introduced by Andrej Karpathy in early 2025. The core idea is that developers no longer write code line by line — instead, they describe requirements and constraints in natural language and let an AI coding assistant generate the implementation. The developer's role shifts from "code writer" to "requirements describer and code reviewer."

Tools like Codex and Claude Code enable this kind of development — programming oriented toward Markdown-style descriptions rather than implementation details: describe what you need clearly, then let the AI generate the code from that description. This paradigm works especially well for prototyping and routine business logic, though performance-critical and security-critical code still needs human oversight.

Path 2: Becoming an AI Application Engineer

The second path is becoming an AI application engineer. There's an industry consensus worth highlighting here.

Today's mainstream large models — Gemini, Claude, Qwen, MiniMax, Kimi — score fairly similarly on benchmarks. Competition at the model layer has largely plateaued. So what actually determines whether an AI application is good or smart isn't the underlying model itself — it's the "AI engineering" capabilities wrapped around it.

That layer includes:

• Prompt Engineering: Carefully designed instructions, examples, and constraints that guide the model toward the desired output behavior.
• Context Engineering: A concept introduced in 2025 by Andrej Karpathy and others that goes beyond prompt engineering. It focuses on getting the right information to the model in the right format at the right time — including compressing and summarizing conversation history, dynamically retrieving and injecting external knowledge, formatting tool call results, and managing layered system instructions. The quality of your context engineering directly determines how intelligent your AI application feels, because output quality is highly dependent on the quality of what goes into the context.
• Tools, MCP, RAG, Skills, and other extension technologies: RAG (Retrieval-Augmented Generation) is an architecture that combines external knowledge bases with the model's generation capabilities. The core flow is: take the user's query, retrieve relevant document chunks from a knowledge base via vector search, inject those chunks into the model's prompt as context, and let the model generate answers grounded in up-to-date, relevant facts. This effectively addresses the model's knowledge cutoff limitations and reduces hallucinations.
• Self-improvement capability (does the AI get smarter over time?): Mechanisms like user feedback collection, conversation log analysis, and automatic prompt optimization let the AI application continuously improve its performance in production.

Mastering these skills is what it takes to build AI applications. With Spring AI you can build lightweight agents and chatbots; add Spring AI Alibaba and its Graph capabilities and you can tackle more complex scenarios like multi-agent systems, ReAct autonomous planning, and workflow orchestration.

Closing: Java's AI Era Has Arrived

The Java ecosystem is no longer a blank spot on the AI map. With Spring AI and its surrounding ecosystem, Java developers are fully capable of building AI applications ranging from chatbots to complex agents — entirely on their own.

Adding some Python skills on top of that (TensorFlow, Transformer internals, fine-tuning algorithms) would sharpen your edge further. That said, fine-tuning has a relatively limited scope in practice right now — most enterprise application needs can be met with RAG and prompt engineering alone. Fine-tuning only becomes necessary when a model needs deep expertise or specialized behavior in a specific vertical domain. Mastering AI engineering as a core competency is the most practical path for Java developers looking to break into AI.