At some point last year I had to sit in a design review where the question on the table was whether to add a vector database to a system already running PostgreSQL, Kafka, Redis, and three microservices. The honest answer was: it depends on what “AI-native” means for this specific system, and most of the definitions I had read were too abstract to apply to an actual decision. This post is my attempt to write the guide I wanted in that room. Not “what is AI-native design” in the abstract, but: what specifically changes about your database strategy, API contracts, service boundaries, and error model when the workload shifts from deterministic CRUD to probabilistic reasoning. Everything here is grounded in choices I have either made in production or evaluated seriously — including the wrong turns. Tested on Spring Boot 3.4, Spring AI 1.0 GA, Java 21, PostgreSQL 16 with PGVector 0.7.

I have had this conversation more than once in the last year: a team ships a chat feature, users start asking it to “just handle” a workflow instead of navigating the UI, and suddenly the question isn’t “how do we improve the chatbot” but “why does our backend have no concept of intent?” The REST API has fifty endpoints, each doing one thing precisely. The agent needs to orchestrate twelve of them, in order, with conditional branching, to do what a human described in one sentence. That gap — between an API designed for deterministic human clients and one that needs to serve a reasoning agent — is what this post is actually about. Not whether agents will replace CRUD, but what specifically needs to change in your Java backend when the caller is an LLM instead of a browser. All examples here run on Spring Boot 3.4, LangChain4j 0.33.0, Java 21.

The first time I tried to ship an AI feature in a Spring Boot service, I reached for LangChain4j because I knew Python’s LangChain and wanted the Java equivalent. It worked — but the setup was verbose. Six months later I tried the same with Spring AI and had streaming chat running in forty minutes. The problem was that Spring AI’s agent and tool-calling support was too limited for what I needed. The answer, annoyingly, was to use both. This guide is the result of running both frameworks in a production order-management assistant — Spring AI 1.0.0-M6 with LangChain4j 0.33.0 on Spring Boot 3.4.1, Java 21.0.3, backed by PostgreSQL 16 with PGVector 0.7.0. Spring AI handles the ChatClient, RAG pipeline, and Micrometer observability. LangChain4j handles the agent loop and tool registry where its control over iteration and retries is genuinely superior. The division is deliberate, not accidental.