If you have written enterprise Java in the last 20 years, you know the name Rod Johnson. He created Spring Framework back in 2003 - the thing that made Java dependency injection feel natural instead of like wrestling XML. Spring basically rewrote how enterprise Java works.
Johnson stepped away from active Spring development years ago. But in early 2026, he returned - and he did not come back to build another IoC container.
He built Embabel. An AI agent framework for the JVM. And it works nothing like Spring AI or LangChain4j.
I have been running AI agents on my own VPS for months. Hermes Agent, Claude Code, custom MCP servers - the works. So when I heard Rod Johnson was back with a Java AI framework, I paid attention. Here is what I found.
Over the last year, most Java developers entering AI have gravitated toward two frameworks:
Both are excellent at what they do. You can build chatbots, RAG pipelines, tool-calling assistants, and AI-powered APIs in a few lines of code.
But both treat the LLM as the center of the application. You send a prompt. The model responds. Maybe it calls a tool. Then it responds again.
For question-answering or chat interfaces, that is fine. But what if you want the system to:
This is where the chatbot pattern breaks down. And this is exactly what Embabel targets.
Embabel (pronounced em-BAY-bel) is a framework for building goal-oriented AI agents on the JVM. It is written in Kotlin and works naturally from Java. It sits on top of Spring AI - Johnson described the relationship as "Spring AI is to Embabel as the Servlet API is to Spring MVC" [source].
So Spring AI gives you the low-level LLM plumbing (model connections, prompt templates, output parsers). Embabel gives you the agent orchestration layer.
The key innovation is borrowed from video games.
If you have played games like F.E.A.R. or Killzone, you have encountered GOAP. It is an AI technique where each action has:
A planner figures out which sequence of actions leads to the goal. The plan is deterministic - not driven by another LLM call. This matters because it means you can explain exactly why the agent did what it did.
Here is how Embabel models this:
@Agent
, holds capabilities and state@Action
, has preconditions and effects
@AchievesGoal
After every action runs, the system re-evaluates. It checks if the goal is met. If not, it replans. This loop continues until the goal is achieved or the system gives up.
The planning itself is not an LLM call. It is a deterministic algorithm. You get auditability - something enterprises care about a lot.
Dan Vega published a first look at Embabel in April 2026. He built a blog writing agent. You start with two Java records for type-safe output:
public record BlogDraft(String title, String content) {}
public record ReviewedPost(String title, String content, String feedback) {}
Then the agent itself:
@Agent(description = "Write and review a blog post")
public class BlogWriterAgent {
@Action(description = "Write a first draft")
public BlogDraft writeDraft(UserInput input, AI ai) {
return ai.withDefaultLlm()
.creating(BlogDraft.class)
.fromPrompt("Write a blog post about " + input.getContent());
}
@Action(description = "Review and polish the draft")
@AchievesGoal(description = "A reviewed, polished blog post")
public ReviewedPost reviewDraft(BlogDraft draft, AI ai) {
return ai.withLlmByRole("reviewer")
.creating(ReviewedPost.class)
.fromPrompt("Review and improve: " + draft.title());
}
}
Two things stand out here.
First, @AchievesGoal
tells the planner that completing this action means the goal is met. Writing a first draft is progress. Reviewing and polishing it is completion. The planner figures out this ordering on its own.
Second, withLlmByRole("reviewer")
lets you assign different models to different tasks. Use a fast cheap model (gpt-4.1-mini
) for the draft. Use a more capable model (gpt-4.1
) for review. This is configured in application.yaml
, not hardcoded.
You do not define a step-by-step workflow. You define actions and a goal. The planner finds the path.
Spring AI / LangChain4j:
Embabel:
You do not pick Embabel over Spring AI. You use Embabel with Spring AI. Spring AI is the LLM plumbing. Embabel is the orchestration layer on top.
Embabel was first announced in June 2025 on InfoQ. Johnson introduced it publicly at Microsoft JDConf in April 2026. It has been releasing weekly patches since then.
The project is Apache 2.0 licensed and available on GitHub.
Current status: early access. The version at the time of Dan Vega's first look was 0.4.0-SNAPSHOT
. It does not yet support Spring AI 2.0 or Spring Boot 4 - you need Spring Boot 3.5.x and Spring AI 1.1.4. But the pace of releases has been fast - weekly patches through early 2026.
The official resources are thin but growing:
You need Spring Boot 3.5.x, Java 23, and an API key for your LLM provider (OpenAI, Anthropic, Gemini - whatever Spring AI supports). Embabel is currently published as a SNAPSHOT, so you need to add the Spring snapshot repository to your pom.xml
.
I run Spring Boot applications in production and Hermes Agent as my personal AI infrastructure. So I am exactly the target audience for this kind of framework.
Here is what I like: the determinism. The GOAP planner produces an auditable trace. In enterprise environments, that matters. When an AI agent does something wrong, you need to know why. With plain LLM chains, the answer is usually "the model decided to." With Embabel, the answer is "the planner chose action X because preconditions Y were met." That is a real difference.
Here is what gives me : the maturity. At 0.4.x-SNAPSHOT with a snapshot repository dependency, this is not something you deploy to production tomorrow. Community examples are still thin - mostly the official samples and Dan Vega's blog post.
Full disclosure - I have not built anything with Embabel yet. This is based on reading the docs and Vega's walkthrough. But the architecture reads like someone who has thought deeply about enterprise software. That should not be surprising. Rod Johnson has.
If he maintains the same energy he brought to Spring, Embabel could become the standard way Java teams build AI agents. The timing is right - every enterprise Java shop I know is trying to figure out how to use AI without throwing away their existing investments. A JVM-native agent framework that respects type safety and auditability is exactly what they are looking for.
If you are a Java developer watching the AI space from the sidelines wondering where you fit - Embabel might be the framework that makes it click. Or it might be too early. I would love to hear what you think.