Embabel, a framework for building AI agents on Java, has reached its 1.0 general-availability release, offering Java and Kotlin developers a fundamentally different way to structure AI agents compared to existing tools like LangGraph. Instead of hand-coding sequences of prompts and tool calls, Embabel lets developers define agents as typed domain objects (goals, actions, and the conditions that connect them), then uses a planning algorithm to figure out how to reach those goals at runtime.

What Makes Embabel's Planning Approach Different?

The core innovation behind Embabel is its use of Goal-Oriented Action Planning (GOAP), a technique borrowed from video game AI. Rather than following a pre-wired graph of steps, an agent is given a set of available actions, each with preconditions and effects. The planner then searches for a sequence of actions that satisfies the goal. If something changes mid-task, a tool call fails, or new information arrives, the planner can reassess and find a new path instead of falling over or requiring the workflow to have anticipated that branch in advance.

This is a significant departure from LangGraph, the graph-oriented orchestration layer built by LangChain. LangGraph represents an agent workflow as a directed graph where nodes are functions (an LLM call, a tool invocation, a database lookup) and edges are the routing logic that decides which node executes next. The developer defines that graph up front. Embabel's planner, by contrast, starts from a different point: rather than the developer wiring the graph, the framework searches for a path through the available typed actions at runtime and can combine actions into sequences the developer never explicitly wired together.

How Does Embabel Fit Into the Broader Java Ecosystem?

Embabel doesn't replace Spring AI, the Spring team's own library for calling models, managing embeddings, and invoking tools. Instead, it's built on top of it. The project's README draws a direct parallel to Spring's own history: "An analogy: Spring AI exists at the level of the Servlet API, while Embabel is more like Spring MVC." Raw servlets work, but every application ends up re-solving the same problems. Spring MVC didn't replace servlets; it sat on top of them and let developers write a typed method signature instead of parsing a HttpServletRequest by hand. Embabel is making the same bet for agents: Spring AI supplies the plumbing to talk to a model, and Embabel supplies the layer where a developer declares "these are my goals and the typed actions available to reach them," leaving the framework to work out the sequencing.

Embabel was co-created by Rod Johnson, the creator of the Spring Framework itself. Johnson announced the release with "Embabel 1.0.0 GA nearly ready...excited!" Johnson founded Spring, and with it Spring MVC, in 2003.

Johnson, the creator of the Spring Framework itself

What Model Flexibility Does Embabel Offer?

Because Embabel builds on Spring AI, it inherits support for most of the providers Spring AI does. This includes OpenAI, Anthropic, Gemini, Bedrock, Mistral, and DeepSeek, plus local and self-hosted options through Ollama, Docker, or an OpenAI-compatible LMStudio endpoint. The choice isn't made once for the whole agent: a developer can pin an individual action to a specific model, or define role aliases in configuration (a "best" model for the step that needs strong reasoning, a "cheapest" one for routine steps) and have an action reference the role instead of a hard-coded name. That makes it straightforward to run a single agent across a mix of models, routing each step to whichever one fits its cost, privacy, or capability needs.

How to Evaluate Embabel for Your Java Team

• Assess Your Current Architecture: If your team is already running Spring Boot services, Embabel stops being a project to watch and starts being one to evaluate. The project's "Overview" guide walks through defining a first goal and typed action before getting into planning behavior.
• Compare Planning vs. Graph Approaches: Embabel supports mixing GOAP planning with explicit state machines in the same agent, so a team can still drop into LangGraph-style fixed routing for the steps where that's what they want. Consider which parts of your agent workflows would benefit from dynamic planning versus static routing.
• Evaluate Multi-Framework Compatibility: Java teams can use LangGraph directly through LangGraph4j, a Java port built to work with LangChain4j and Spring AI. Embabel's planning approach offers an alternative to graph-based orchestration, not a replacement, so teams can choose the model that fits their problem best.

What Other Java Agent Frameworks Are Available?

Embabel isn't the only player in the Java agent space. Akka, the Lightbend-maintained toolkit built around the actor model, approaches the same problem from existing strength in distributed systems rather than Spring's programming-model tradition. In Akka, each unit of work (here, an agent) runs as an actor with its own isolated state and mailbox, supervised by a hierarchy that can restart it after a failure without disturbing the rest of the system. The Akka Agentic Platform applies that directly to agents: an agent's state and in-flight conversation live in an actor that survives a process crash and can be distributed across a cluster, so a long-running agent doesn't need to be rebuilt from scratch after a restart or re-architected to run across multiple machines.

JetBrains' Koog takes a third approach, built around Kotlin's own language features rather than a runtime or a declarative programming model. Each framework is making a different bet on where an agent's structure should live: the type system for Embabel, the runtime for Akka, the language itself for Koog.

For teams already running Spring Boot services, Embabel's 1.0 release marks the point where the framework transitions from an interesting project to a practical option worth evaluating for production use.