A GA Release for Java Agent Development

Embabel, a framework for building AI agents on Java, has reached its 1.0 general availability release. The milestone moves the project from something to watch into something Java and Kotlin teams can start evaluating for production-oriented agent work.

Instead of asking developers to manually chain prompts, tools, and branching logic, Embabel lets them describe agents through typed domain objects: goals, actions, and the conditions that connect them. The central idea is that an agent should plan a route to a goal at runtime, rather than simply execute a hard-coded script.

For mainstream software teams, this matters because many agent experiments quickly become difficult to maintain when key behavior is hidden inside natural-language prompts. Embabel tries to bring agent design closer to familiar software engineering practices, especially for teams already using Spring Boot.

Planning Inspired by Game AI

Embabel’s planning layer draws on Goal-Oriented Action Planning, or GOAP, a technique associated with video game AI. In simple terms, GOAP gives a system a set of possible actions, each with preconditions and effects, and a planner searches for a sequence of actions that can satisfy a goal.

That differs from a conventional workflow or fixed graph. If a tool call fails or new information arrives while the agent is running, a static workflow often needs a pre-designed branch. Embabel’s planner can re-evaluate the current state and look for another path. This makes the agent model more adaptive than a purely scripted pipeline.

Key elements include:

• typed declarations for goals, actions, and connection conditions;
• preconditions and effects attached to each action;
• runtime search for a valid action sequence;
• replanning when execution conditions change;
• support for mixing GOAP planning with explicit state machines.

Typed modeling is important because it makes inputs, outputs, and transitions more visible to the framework and the compiler, rather than leaving all structure inside prompt text.

Built Above Spring AI, Not Against It

Embabel is not positioned as a replacement for Spring AI. Spring AI provides the lower-level library for calling models, managing embeddings, and invoking tools. Embabel sits above that layer and focuses on the structure of agent behavior.

Rod Johnson, the creator of the Spring Framework and a co-creator of Embabel, announced that Embabel 1.0.0 GA was essentially ready. The project README compares the relationship to Spring MVC and the Servlet API: servlets are usable directly, but applications would otherwise repeat work such as parsing requests, dispatching handlers, and mapping objects to HTTP. Spring MVC did not replace servlets; it raised the abstraction level. Embabel aims to do something similar for agents on top of Spring AI.

That layering also affects model choice. Because Embabel builds on Spring AI, it inherits support for providers including OpenAI, Anthropic, Gemini, Bedrock, Mistral, and DeepSeek. It can also use local or self-hosted options through Ollama, Docker, or OpenAI-compatible LMStudio endpoints. Developers do not need to bind an entire agent to one model. They can assign models per action, or define role aliases so that reasoning-heavy steps use a best model while routine steps use a cheaper one.

How It Differs from LangGraph, Akka, and Koog

The main difference between Embabel and LangGraph is where orchestration is defined. LangGraph, and LangGraph4j for Java teams, represents an agent workflow as a directed graph. Nodes are functions such as an LLM call, tool call, or database lookup; edges define static or conditional routing; shared state moves through the graph. Developers define the graph in advance.

Embabel instead searches across typed actions at runtime, allowing it to compose sequences the developer may not have explicitly wired together. At the same time, it does not reject fixed routing: teams can combine GOAP planning with explicit state machines when that is the better fit.

Akka Agentic Platform, maintained by Lightbend’s Akka ecosystem, approaches the problem from distributed systems. Akka uses the actor model, where each unit of work has its own state and mailbox, and actors can be supervised and restarted after failures. Applied to agents, that emphasizes durable state, long-running conversations, fault tolerance, and cluster distribution. Embabel is more about the programming model; Akka is more about the runtime infrastructure. JetBrains’ Koog represents a third path, leaning into Kotlin language features.

What This Means for the Java Ecosystem

Embabel 1.0 is notable because it adds a higher-level agent abstraction to the Java and Spring world. As enterprises move from experiments to real workflows, prompt chains and ad hoc scripts are unlikely to be enough for maintainability, testing, and multi-model governance.

In the near term, Embabel is most relevant to Spring-oriented teams that want type safety and explicit domain modeling around agent behavior. Over time, the agent framework market may continue to split into planning-centered programming models, distributed runtimes, and language-native toolkits. Embabel’s long-term role will depend on documentation, real-world adoption, and how closely it evolves with Spring AI.