Spring AI vs LangChain4j vs Embabel: how to choose on the JVM

Teams adding AI to a Java system usually compare three names: Spring AI, LangChain4j and Embabel. They are often presented as alternatives, but they work at different levels, and the right choice depends more on your stack and the shape of the problem than on feature lists. Versions and facts are as of October 2026; all three release often, so check the linked sources before you commit.

Three layers, not three equivalent options

Spring AI is the AI integration layer of the Spring ecosystem: model clients, advisors, tool calling, vector stores, MCP and Micrometer observability.
LangChain4j is an integration library independent of the host framework. It runs on Quarkus, Spring Boot, Helidon, Micronaut or plain Java.
Embabel is an agent framework built on top of Spring AI. Its README puts it this way: Spring AI sits at the level of the Servlet API, Embabel is closer to Spring MVC.

Spring AI and Embabel are therefore complementary, while LangChain4j is an alternative to Spring AI (and, with its experimental agentic module, to Embabel).

	Spring AI	LangChain4j	Embabel Agent
Latest stable release	2.0.1 (21 August 2026)	1.22.0 (8 October 2026)	1.5.3 (5 October 2026)
Java baseline	17	17	21
Host framework	Spring Boot 4.0 / 4.1	Any; starters for Boot 3 and Boot 4	Spring Boot 4.1 and Spring AI 2.0
Maturity	2.0 GA in June 2026	Stable core, many modules beta	1.0 GA in July 2026

Spring AI: ChatClient and advisors

The main API is ChatClient, a fluent client in the style of RestClient. Every request passes through an ordered chain of advisors: conversational memory, retrieval-augmented generation (QuestionAnswerAdvisor, RetrievalAugmentationAdvisor), logging and validation become reusable components that work across providers. Since 2.0 the tool-calling loop is itself an advisor.

record Triage(Category category, String rationale) {}

Triage triage = chatClient.prompt()
    .system("Classify the support ticket.")
    .user(ticket.text())
    .call()
    .entity(Triage.class);

Spring AI covers the main providers, from OpenAI and Anthropic to Amazon Bedrock and Ollama, and ships 22 vector store modules. In a Spring Boot application it is the natural choice: auto-configuration, Actuator, Spring Security and transactions are already there, and commercial support is available. It does not provide a high-level agent model with planning: the agentic patterns documented by the Spring team are built in your own code.

Two practical notes. Spring AI 2.0 requires Spring Boot 4, while the 1.1.x line, tied to Boot 3.5, ended open-source support on 30 June 2026. And the 1.x to 2.0 migration has real breaking changes: Jackson 3, provider option classes without setters, JSpecify null-safety annotations.

LangChain4j: AI Services on any Java stack

Despite the name, LangChain4j is not a Java port of LangChain. The project states that its APIs, implementation and releases are independent of the Python project; the name is historical. There is no compatibility with LangChain, LangGraph or LangSmith, which is why we always write "LangChain4j" in full.

Its central abstraction is the AI Service: you declare an annotated interface and LangChain4j generates the implementation, in a style close to Spring Data or Feign.

interface TicketTriage {
    @SystemMessage("Classify the support ticket.")
    Triage classify(@UserMessage String ticket);
}

TicketTriage triage = AiServices.create(TicketTriage.class, chatModel);

Its integration catalogue is the widest of the three (more than 20 LLM providers, more than 30 embedding stores). It integrates with Quarkus through quarkus-langchain4j, with Spring Boot 3 and 4 through separate starters, and with Helidon and Micronaut.

The caveat is maturity per module. The core is stable, but many modules still carry a -beta suffix, including langchain4j-agentic, langchain4j-mcp, langchain4j-guardrails and the Spring Boot starters, and the documentation marks the agentic module and guardrails as experimental. Releases arrive every one to two weeks, so dependency management needs discipline.

Embabel: goals, actions and planning

Embabel was created by Rod Johnson, the creator of Spring. It is written in Kotlin with an idiomatic Java API. You describe actions, goals and conditions over your domain types, and the framework, not the programmer, formulates the plan, re-evaluated after every action. The default planner is GOAP (Goal-Oriented Action Planning), which does not rely on the language model; Utility AI is an alternative.

@Agent(description = "Prepare a review note for a support case")
public class CaseReviewAgent {

    @Action
    public CaseFacts extractFacts(SupportCase input, OperationContext context) {
        return context.ai().withLlmByRole("extractor")
            .createObject("Extract the facts from: " + input.text(), CaseFacts.class);
    }

    @AchievesGoal(description = "A review note is ready for a human reviewer")
    @Action
    public ReviewNote draftNote(CaseFacts facts, OperationContext context) { /* ... */ }
}

Parameters and return types define what each action needs and produces, so preconditions follow from your types. Model roles let each step use the model that fits its cost or privacy constraints, including local models. Agents are ordinary Spring beans.

The constraints: Java 21+, Spring Boot, a smaller community and a young API. Provider and MCP server starters are stable, while the A2A, test and evaluation modules are incubating or experimental. We govern Embabel as a strategic dependency, with version pinning and contract tests.

Tool calling and MCP

All three support tool calling with annotated Java methods. The differences show up around the Model Context Protocol:

Spring AI 2.0 ships the MCP Java SDK 2.0.0, follows the 2025-11-25 specification and supports clients and servers, with annotations such as @McpTool and @McpResource. Streamable HTTP is the default transport and SSE is deprecated. The mcp-security project adds OAuth 2.0 and API keys.
LangChain4j has a full MCP client (stdio, Streamable HTTP, stdio in Docker), supports protocol versions 2025-11-25 and 2026-07-28, and filters or renames tools through McpToolProvider. Serving MCP is not the focus of the core library.
Embabel consumes MCP tools through Spring AI and exposes agents as MCP servers with embabel-agent-starter-mcpserver. @SecureAgentTool checks a Spring Security expression on the current user before a remote tool runs; ToolCallContext passes tokens or tenant IDs to tools without showing them to the model.

Whatever the framework, we separate read-only tools from tools that change data, and authorize on the real user rather than an all-powerful service account.

Structured output

All three map model output to Java types; they differ in how they handle a bad answer. Spring AI's StructuredOutputValidationAdvisor asks the model to correct itself when the JSON does not match the schema. LangChain4j offers an experimental JsonExtractorOutputGuardrail. Embabel validates the objects returned by createObject with Bean Validation, retries once explaining the error, then throws InvalidLlmReturnTypeException, which can trigger replanning.

In every case we treat the result as a typed proposal: the model proposes, existing domain services validate and decide.

Observability and sensitive data

Spring AI and LangChain4j emit Micrometer metrics following the OpenTelemetry GenAI conventions (gen_ai.client.token.usage), so token usage and latency land in the dashboards you already have. Spring AI does not log prompt, completion or tool content by default; you opt in with properties such as spring.ai.chat.client.observations.log-prompt.

Embabel's embabel-agent-starter-observability traces agents, actions, model calls, tools and planning to any OpenTelemetry backend. Note the default: it captures message content, tool arguments, RAG queries and world state. With personal, banking or health data, turn it off or filter it:

embabel:
  agent:
    platform:
      observability:
        capture-message-content: false

Combining frameworks

Embabel on Spring AI is the native combination: Spring AI for models, vector stores, MCP and observability, Embabel for orchestration.
Spring AI as an MCP server can expose Spring domain services as tools to agents built elsewhere, for example with LangChain4j on Quarkus.
LangChain4j inside Spring Boot makes sense only for a specific capability you cannot get otherwise. Isolate it in a module and do not mix two model abstractions in the same service.

Decision table

Situation	Our default	Why
Spring Boot application, bounded use case (classification, extraction, RAG on internal documents)	Spring AI	No extra dependency; security and observability already in place
Quarkus, Jakarta EE, Helidon, Micronaut or plain Java	LangChain4j	Framework-independent, first-class Quarkus extension
Multi-step process over a rich domain model, next step depends on the data	Embabel on Spring AI	Planning over typed objects, testable without calling a model
Known, deterministic flow	Spring AI or LangChain4j with explicit workflow code	A planner adds complexity without benefit
Exposing Spring services to AI assistants	Spring AI MCP server	Server annotations, Streamable HTTP, OAuth via `mcp-security`
System still on Spring Boot 3.5	Plan the Boot 4 upgrade	Spring AI 2.0 and Embabel 1.5 require Boot 4

For the last row, see our article on Spring Boot upgrade strategy.

What matters more than the framework

The framework choice is reversible; weak engineering around it is not. Before production we want an evaluation dataset run in CI whenever a prompt, model or framework version changes, versioned prompts, pinned model identifiers, cost metrics per use case and controls against the risks in the OWASP Top 10 for LLM Applications.

Official sources: Spring AI reference, Spring AI 2.0 announcement, LangChain4j documentation, LangChain4j MCP, Embabel Agent on GitHub.

If you are evaluating AI for a Java system, our AI engineering practice and the Enterprise AI Feasibility & Prototype package start from your use case and your data. Contact us to discuss it.