Post cover image
AI image

October 2, 2026

LangChain4j Already Solved Java Agents. So Why Did the Creator of Spring Build Embabel?

The real competition isn’t about who has more agent features. It’s about who gets to decide what an AI agent does next.

By Umesh Kumar Yadav

8 min read

When Rod Johnson — the creator of Spring — introduced Embabel, his new framework for AI agents on the JVM, my first reaction was confusion.

Didn't Java already have an agent framework?

LangChain4j already provides a mature set of agentic primitives, tool calling, MCP support, multi-agent orchestration, and model integrations. So why build another framework?

After looking more closely at Embabel's architecture and comparing it with LangChain4j, I realized that the question itself is slightly wrong.

Embabel isn't primarily trying to replace LangChain4j.

It is trying to answer a different question:

If LangChain established the agent programming paradigm in Python, what should the corresponding programming model look like in the JVM ecosystem?

And that leads to a much more interesting comparison.

The real difference between LangChain4j and Embabel isn't simply their feature lists.

It is who gets to decide the next action of an agent:

  • The developer?
  • The LLM?
  • Or an algorithm?

LangChain4j supports the first two approaches.

Embabel bets heavily on the third.

Embabel, Spring AI, and LangChain4j Are Different Layers

Before comparing Embabel with LangChain4j, it is important to understand where Embabel sits in the Java AI ecosystem.

There are roughly three layers.

1. Spring AI — the foundation

Spring AI provides the infrastructure for communicating with AI models and integrating AI capabilities into Spring applications.

It handles things such as:

  • Model access
  • Tool calling
  • MCP
  • ChatClient
  • Advisors
  • Retrieval
  • Prompt interactions

In other words, Spring AI provides many of the building blocks required to communicate with LLMs.

2. LangChain4j — a full-stack AI framework

LangChain4j takes a broader approach.

It provides:

  • Model integrations
  • Tool calling
  • MCP
  • Agentic primitives
  • Multi-agent orchestration
  • RAG
  • Memory/state mechanisms
  • Observability

It therefore competes with Spring AI at the framework level while also providing an agent layer.

3. Embabel — an agent programming model

Embabel takes a different approach.

Rather than rebuilding the model-access layer, it sits on top of Spring AI.

Its focus is primarily:

How should developers describe AI agents and their capabilities?

This distinction is important.

Spring AI gives developers components.

Embabel attempts to provide a programming model for assembling those components into agents.

A useful analogy is:

Servlet API → Spring MVC

The Servlet API provides low-level capabilities.

Spring MVC provides a higher-level programming model for building web applications.

Similarly:

Spring AI → Embabel

Spring AI provides AI infrastructure, while Embabel focuses on how developers describe and organize agents.

The Big Question: Who Controls Agent Orchestration?

This is where the two frameworks become genuinely interesting.

Consider a multi-step AI workflow.

Suppose we have:

  1. A researcher
  2. A writer
  3. An editor
  4. A scorer

Who decides which one runs first?

There are several possible answers.

Approach #1: The Developer Decides

LangChain4j allows developers to explicitly construct an agent workflow.

For example:

interface StoryWriter {

    @UserMessage("Write a short story about {{topic}}")
    @Agent(description = "Write a story", outputKey = "story")
    String write(@V("topic") String topic);
}

Then the developer can explicitly define the pipeline:

UntypedAgent pipeline =
    AgenticServices.sequenceBuilder()
        .subAgents(writer, editor, scorer)
        .outputKey("story")
        .build();

The execution order is explicit.

The developer decides:

Writer
   ↓
Editor
   ↓
Scorer

LangChain4j provides several orchestration primitives, including:

  • Sequence
  • Loop
  • Parallel
  • Parallel Mapper
  • Conditional

It also provides a supervisor-style approach where an LLM can dynamically determine which sub-agent should run.

So LangChain4j effectively supports two styles:

Developer-controlled workflow
            +
LLM-controlled planning

Approach #2: Let the LLM Decide

A supervisor-style architecture gives the LLM responsibility for selecting the next agent.

Conceptually:

               ┌──────────────┐
               │   Supervisor │
               │     LLM      │
               └──────┬───────┘
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
    Researcher      Writer        Editor

The LLM looks at the available agents and determines what should happen next.

This is flexible.

But flexibility comes with a cost.

LLMs are probabilistic systems.

The same input can potentially result in different plans.

For some applications, that's exactly what you want.

For others, especially enterprise systems, developers may prefer something more deterministic.

And this is where Embabel enters the picture.

Approach #3: Let an Algorithm Decide

Embabel takes a very different approach.

Instead of explicitly writing:

Action A → Action B → Action C

you describe what each action requires and what it produces.

For example:

@Agent(description = "Find news based on a person's zodiac sign")
public class StarNewsFinder {

    @Action
    public StarPerson extractStarPerson(
        UserInput input,
        OperationContext ctx) {
        ...
    }

    @AchievesGoal(description = "Write an interesting summary")
    @Action
    public Writeup writeup(
        StarPerson person,
        RelevantNewsStories news,
        Horoscope horoscope,
        OperationContext ctx) {
        ...
    }
}

Notice something important.

There is no explicit workflow here.

There is no:

step1()
step2()
step3()

Instead, the method signatures describe dependencies.

The first action produces:

StarPerson

The next action requires:

StarPerson
RelevantNewsStories
Horoscope

and produces:

Writeup

Embabel can therefore reason about the relationships between these types.

Conceptually:

UserInput
    │
    ▼
StarPerson
    │
    ├───────────────┐
    ▼               ▼
RelevantNews     Horoscope
    │               │
    └───────┬───────┘
            ▼
         Writeup

The framework uses a planning approach based on Goal-Oriented Action Planning (GOAP).

The key idea is that action inputs behave like preconditions and action outputs behave like postconditions.

The planner can search the dependency graph to determine a path from the current state toward the desired goal.

The Surprising Part: The Planner Isn't the LLM

This is probably the most interesting architectural difference.

You might expect an AI-agent framework to use an LLM to decide:

"What should I do next?"

Embabel can instead use an algorithmic planner for this part.

The LLM remains useful inside individual actions.

For example:

             Goal
              │
              ▼
       ┌─────────────┐
       │ GOAP / A*   │
       │   Planner   │
       └──────┬──────┘
              │
       selects Action
              │
              ▼
        ┌───────────┐
        │   LLM     │
        │ executes  │
        │   task    │
        └───────────┘

So the responsibilities are separated.

Algorithm:

What should happen next?

LLM:

How should this particular task be performed?

That's a fundamentally different philosophy from giving the LLM complete control over orchestration.

Three Models of Agent Orchestration

We can therefore place the approaches on a spectrum:

None

This distinction is more meaningful than simply comparing feature checklists.

It is a difference in programming philosophy.

Interestingly, LangChain4j Already Has the Same Idea

There is an interesting detail here.

LangChain4j's documentation includes examples of custom goal-oriented planning.

The basic concept is similar:

  1. Inspect the inputs and outputs of agents.
  2. Build a dependency graph.
  3. Search for a path toward the desired goal.
  4. Execute the resulting plan.

So the underlying concept isn't completely foreign to LangChain4j.

The difference is primarily how central the idea is to the framework.

In LangChain4j, this can be something developers build or customize.

In Embabel, algorithmic planning is much closer to the center of the programming model.

That's an important distinction.

LangChain4j vs Embabel: Capability Comparison

Beyond orchestration, both frameworks provide many overlapping capabilities.

None

The interesting differences appear when we look beneath the feature names.

Strong Typing Is a Major Part of Embabel's Philosophy

One of Embabel's most interesting ideas is to make the agent's state strongly typed.

Consider:

public Writeup writeup(
    StarPerson person,
    RelevantNewsStories news,
    Horoscope horoscope,
    OperationContext ctx) {
    ...
}

The types themselves describe the data flow.

Instead of having everything revolve around generic strings or loosely structured maps, domain objects become part of the agent's architecture.

That gives you a model closer to traditional Java programming.

For developers who have spent years building enterprise systems, this is significant.

You can reason about:

Input Type
    ↓
Action
    ↓
Output Type

rather than thinking only in terms of:

Prompt
    ↓
LLM
    ↓
String

This is also consistent with the broader philosophy behind "taming" AI agents.

The goal isn't necessarily to eliminate AI autonomy.

It's to place AI autonomy inside a structure that traditional software engineering can reason about.

LangChain4j Has an Important Advantage: Compensation

The comparison isn't one-sided.

LangChain4j has a particularly interesting mechanism around failure compensation.

Imagine an agent workflow:

CreateOrder
    ↓
ChargePayment
    ↓
ReserveInventory
    ↓
ShipOrder

What happens if inventory reservation succeeds but shipping fails?

In a conventional distributed system, we might need compensation:

ShipOrder → FAILED

        ↓
ReleaseInventory
        ↓
RefundPayment

LangChain4j's agentic capabilities include compensation semantics that resemble Saga-style rollback behavior.

That's an important capability for multi-step agents interacting with external systems.

Embabel's approach, according to the compared versions, focuses more on action-level retries and exception classification rather than providing the same direct cross-agent compensation model.

This illustrates an important point:

A deterministic planner doesn't automatically solve distributed transaction problems.

Planning and transactional consistency are separate concerns.

State Management: Two Different Philosophies

State sharing also reveals a philosophical difference.

LangChain4j's AgenticScope historically revolves around keys and shared state, with stronger typed mechanisms available through TypedKey.

Embabel's Blackboard is strongly typed around domain objects.

Conceptually:

Key-oriented state

"story" → String
"score" → Integer
"author" → Person

Type-oriented state

Person
Story
Score
ResearchResult

The second model feels more natural to developers accustomed to statically typed Java systems.

It also gives the planner more structural information about the state of the system.

Where Does Spring AI Alibaba Fit?

This comparison becomes confusing if we put Spring AI Alibaba into the same category.

It isn't really solving exactly the same problem.

Spring AI Alibaba is more focused on the engineering platform around agents.

That includes things such as:

  • Graph-based orchestration
  • Service registration
  • Nacos integration
  • Multi-tenancy
  • Administrative capabilities

A useful analogy is:

Spring Boot
    ↓
Spring Cloud

Spring AI
    ↓
Spring AI Alibaba

while Embabel is closer to:

Spring AI
    ↓
Embabel

The two can therefore occupy different architectural positions.

If your primary requirement is an agent programming model, Embabel is relevant.

If your requirement is an agent platform with infrastructure and management capabilities, Spring AI Alibaba addresses a different layer.

What This Means for Java Developers

The emergence of Embabel is significant because it shows that the JVM agent ecosystem is moving beyond simple LLM wrappers.

The conversation is shifting from:

"How do I call an LLM from Java?"

to:

"How should an autonomous system be programmed?"

That's a much harder question.

Traditional software gives developers explicit control:

if
for
while
method()
service()
workflow()

AI agents introduce uncertainty:

Goal
  ↓
Possible actions
  ↓
LLM reasoning
  ↓
Tool calls
  ↓
New state
  ↓
Next action

Framework designers now have to decide how much of this uncertainty should be exposed to developers.

LangChain4j provides several answers.

Embabel provides another.

Why Rod Johnson's Background Makes This Interesting

Rod Johnson's significance here isn't simply that he created another Java framework.

His career has repeatedly centered on programming models.

Spring became successful partly because it offered a simpler programming model compared with heavyweight enterprise Java approaches of its era.

Now AI agents are creating a similar problem.

Developers are increasingly writing:

prompts
tools
agents
workflows
memory
state
supervisors
graphs

The industry is still searching for the right abstraction.

Embabel's thesis appears to be:

Don't force developers to manually orchestrate every agent step. Describe capabilities and goals, then let a planner determine how to reach the goal.

That's a very different way of thinking about agent development.

But There Is an Important Risk

A framework built around a new programming model inevitably carries ecosystem risk.

Spring AI itself is evolving quickly.

If Spring AI eventually introduces first-class agent primitives, some capabilities currently provided by Embabel could potentially overlap with the official Spring ecosystem.

That creates an architectural question for teams evaluating Embabel:

Should agent orchestration remain a separate framework, or eventually become part of the core Spring AI programming model?

There is no definitive answer yet.

And this is one reason framework maturity matters as much as technical elegance.

So, Why Did Rod Johnson Create Embabel?

The answer becomes much clearer once we stop asking:

"Why create Embabel when LangChain4j already exists?"

The better question is:

"What should the programming model for AI agents on the JVM look like?"

LangChain4j says:

Give developers powerful primitives and let them compose agents.

Its supervisor model additionally says:

Let an LLM dynamically coordinate agents when appropriate.

Embabel says:

Describe capabilities, inputs, outputs, and goals — and let an algorithm determine the execution path.

These aren't identical philosophies.

The Real Battle Is About Programming Models

The Java AI ecosystem already has strong foundations.

Spring AI and LangChain4j provide model integration, tool calling, RAG, MCP, and other infrastructure.

But the next battle is happening one layer above that.

It's about how developers express agentic behavior.

Should an agent look like:

Workflow
   ↓
Step
   ↓
Step
   ↓
Step

Or:

Supervisor LLM
      ↓
  Agent A/B/C

Or:

Goal
  ↓
Typed capabilities
  ↓
Dependency graph
  ↓
Planner
  ↓
Execution

Embabel is betting on the third model.

And that's why its existence is interesting — even for developers who already use LangChain4j.

The important question isn't simply which framework has more features.

The more fundamental question is:

Who should control the agent's next move — your code, the LLM, or a planner?

That is the programming-model question the Java AI ecosystem is only beginning to answer.

Thank you for reading!

If you found this article useful, feel free to give it a clap 👏, share it with your friends, and follow for more deep dives into distributed systems, Spring Boot architecture, Kafka, Redis, and high-scale backend engineering.

😊 Your support is the biggest motivation to continue sharing technical insights