Spring AI

Before a single line of Spring AI code, you need to know what actually happens when text goes into a model and text comes back out. Everything downstream — memory limits, RAG, embeddings, even why LLM output is non-deterministic — traces back to the ideas on this page.

If you're already a Spring developer, you're most of the way to Spring AI already — it's auto-configuration and dependency injection applied to LLM calls, not a new framework paradigm.

A one-line chatClient.prompt(question).call().content() got you a response in Module 02. This module is everything that one line is quietly doing, and how to control it.

Same prompt, wildly different behavior depending on a handful of numeric knobs. This module is those knobs, plus the three shapes a response can come back in.

An LLM generates text. Your service layer wants a Java object. This module is the bridge — and where it can quietly go wrong.

Memory, RAG, logging, guardrails — in Spring AI, all four are the same mechanism wearing different clothes. This module is that mechanism.

Module 01 established that LLMs are stateless. This module builds the illusion of memory on top — correctly, per-user, and without silently blowing your context window.

Module 01 introduced embeddings conceptually. This module makes them operational: how similarity is actually computed, how to store millions of vectors, and how to pick from the eleven store integrations Spring AI supports.

The single most consequential pattern in production LLM applications. This module builds it from first principles, then hardens it with pre- and post-retrieval techniques real systems actually need.

Two users ask "what's your refund policy?" and "how do refunds work?" — semantically identical, lexically different. A normal cache misses both. This module doesn't.

Module 09 assumed documents were already in the vector store. This module is how they get there — from a raw PDF or JSON file to searchable, chunked, metadata-enriched vectors.

RAG lets a model read your data. Tool calling lets it act — query a database, check the time, send an email. This module is how a model that can only emit text ends up triggering real Java code.

Module 12's tools lived inside your own application. What if you want to expose tools as a standalone service other AI applications (not just yours) can use — or consume someone else's tools without writing a custom integration for every one? That's what MCP is for.

Tools are the headline feature of MCP. This module covers the four capabilities most tutorials skip — and they're where MCP stops being "remote function calling" and starts being a genuinely two-way protocol between client and server.

"Agent" gets used to mean almost anything. This module gives you five concrete, composable workflow patterns — and the vocabulary to say precisely which one you're building.

Module 01 established LLMs are non-deterministic and can hallucinate confidently. This module is the engineering discipline that catches it — before your users do.

Token usage, evaluator pass rates, tool-call latency — none of it is visible unless you deliberately make it so. This module wires Spring AI into the same Micrometer/Actuator stack you'd use for any Spring Boot service.

Module 02 showed provider-swapping in principle. This module is running several providers side-by-side in one production application, choosing between them at runtime, and keeping every credential out of source control.

Everything so far assumed text in, text out. Spring AI's provider-agnostic pattern extends to audio and images with the same shape of API.

Every module built or hardened one piece. Here's how they compose into a real agent — plus three production case studies that show these same pieces solving actual business problems.